[jira] [Commented] (GROOVY-6491) Conflicting module versions in OSGi context

["Arnaud MERGEY (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-6491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307940#comment-15307940 ] 

Arnaud MERGEY commented on GROOVY-6491:
---------------------------------------

Removing "Eclipse-BuddyPolicy: dependent" from groovy manifest is probably a good idea, as it is equinox-specific and is not working using groovy jar in other osgi implementation like felix.
Also Eclipse-BuddyPolicy: dependent can introduce performances issue (see https://wiki.eclipse.org/Context_Class_Loader_Enhancements)

my guess is 'DynamicImport-Package: *' is probably enough 

> Conflicting module versions in OSGi context
> -------------------------------------------
>
>                 Key: GROOVY-6491
>                 URL: https://issues.apache.org/jira/browse/GROOVY-6491
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-runtime
>    Affects Versions: 2.1.8, 2.2.1, 2.3.6, 2.3.7, 2.4.0-beta-3
>         Environment: equinoxVersion  '3.8.2.v20130124-134944' or '3.9.1.v20130814-1242'
>            Reporter: Bob Saenger
>
> We use equinox as runtime platform to drive our applciation. Given two bundles A and B where each of them uses a dedicated Groovy Version (e.g. A imports 2.1.1 and B imports 2.1.8) we got an unexpected Exception:
> {code}
>  groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.2.1 and you are trying to load version 2.1.1
> 	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$DefaultModuleListener.onModule(MetaClassRegistryImpl.java:509)
> 	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:78)
> 	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromMetaInf(ExtensionModuleScanner.java:72)
> 	at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanClasspathModules(ExtensionModuleScanner.java:54)
> 	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:110)
> 	at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71)
> 	at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33)
> {code}
> The problem seems to be caused by org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner introdcued with Groovy 2.1.2 as fix for GROOVY-6008, that scans all resources to find all MODULE_META_INF_FILE META-INF/services/org.codehaus.groovy.runtime.ExtensionModule that are accessible via classLoader.getResources, in our case the bundle class loader. Although the classes of the second groovy jar are not exposed to the bundle class loader it may of course see the JAR file and it's META-INF entries.
> From the bundles class laoder perspective it would make sense (is even necessary ) to skip a JAR whose classes it can't see. Maybe this issue can be fixed by  changing the org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.DefaultModuleListener#onModule(ExtensionModule module) method.
> If the loadedModule.getVersion() does not match with module.getVersion() it should be checked whether a surrogate class of the module can be loaded. If the surrogate class can't be loaded the module should be silently skipped rather throwing a runtime exception.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)