Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
2.1.8, 2.2.1, 2.3.6, 2.3.7, 2.4.0-beta-3
-
None
-
None
-
equinoxVersion '3.8.2.v20130124-134944' or '3.9.1.v20130814-1242'
Description
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:
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)
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.