groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wolfgang Pedot <>
Subject Re: groovy-all OSGi bundle dependencies
Date Thu, 30 Jul 2015 15:22:06 GMT
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.


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

View raw message