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