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
>
|