In the comments of https://issues.apache.org/jira/browse/GROOVY-6491 Bob
Saenger suggested to "remove the Eclipse-BuddyPolicy from the groovy-all
Manifest".
I guess it's time to remove it (I have no knowledge of OSGi)?
Cheers,
Pascal
Am 30.07.2015 um 17:22 schrieb Wolfgang Pedot:
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
