Some new information:
Appearantly the problem is the Buddy-Policy in the groovy-all bundle,
groovy searches for BeanInfo and Customizer-classes for all my scripts
and since there are none it also checks all its buddy-bundles (which
according to the manifest are all bundles which have a dependency on
groovy-all) and that is what triggers this. I removed the Buddy-Policy
and DynamicImport statements from the groovy-all manifest and my scripts
are still loaded and executed fine but all those jar-checks are now gone.
Wolfgang
Am 30.07.2015 16:46, schrieb Wolfgang Pedot:
> Hi again,
>
> searching for the causes of a sudden increase in script-compile time
> in an OSGi application I am now investigating classloading.
> Here is the simplified scenario:
>
> OSGi application with lots of bundles, one of which (lets call it
> bundle A) uses GroovyScriptEngines to load small scripts for
> customisations, these scripts can work with classes imported from
> other bundles.
> There are lots of other bundles to, one of which has some embedded
> jars in its bundle-classpath, lets call that one bundle B. And of
> corse there
> is also a groovy-all bundle (from embeddable-dir of binary
> distribution). As soon as there is a dependency from bundle B on
> anything from the groovy-bundle (like an import of groovy.lang)
> the script-compile times (and first execution-times) of the
> GroovyScriptEngine in bundle A skyrocket because the jars in the
> bundle-classpath of bundle B get accessed like crazy during
> compilation and first execution.
>
> I noticed that even though I use the classloader of bundle A as parent
> for the GroovyScriptEngine the groovy-bundle gains some dependencies
> on my bundles at runtime and that basically creates some sort of
> dependency-cycle between the groovy-bundle and bundles A/B which leads
> to those exessive reads of the lib-jars in bundle B. All I need in
> bundle B is a reference to Closure because there is one class that has
> gained a method which accepts a Closure as an argument....
>
> I hope I have explained the situation clearly, does anyone have an
> idea or a tip what to do here?
> Whats interesting is that this only appears to be a problem in the
> deployed application, when I run it inside Eclipse I do not see that
> many read-accesses....
>
> regards
> Wolfgang Pedot
|