groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Schumacher <pascalschumac...@gmx.net>
Subject Re: groovy-all OSGi bundle dependencies
Date Thu, 30 Jul 2015 16:41:31 GMT
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
>


Mime
View raw message