Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 366721

Summary: NamespaceHandler not properly resolved if the namespaceId is defined in more than one bundle
Product: [RT] Gemini.Blueprint Reporter: Frederic Boucher <frederic.boucher>
Component: CoreAssignee: Project Inbox <gemini.blueprint-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: enhancement    
Priority: P3 CC: glyn.normington, olaf
Version: unspecified   
Target Milestone: 2.1.0.M01   
Hardware: All   
OS: All   
Whiteboard:

Description Frederic Boucher CLA 2011-12-14 11:17:19 EST
Build Identifier: 

Using Spring DM 1.2.1, the NamespaceHandler are exposed through a OSGI service. Each bundle loaded using the Spring DM extender will add its own NamespaceHandler to this OSGI service. If two bundles handle a same namespaceId but with a different implementation, the OSGi service (that use the namespaceId as a key) will return the NamespaceHandler of the first bundle registered.

In our case, a bundle "A" is installed with two different versions: "1.1.0" and "2.0.0". The schema is the same but the NamespaceHandler implementation is different (ex: class/packages names are different). The bundle "B" is installed and import the bundle "A" version "1.1.0" and the bundle "C" import the bundle "A" version "2.0.0".

On runtime, the ClassLoader of the bundle "B" can only access the NamespaceHandler provided by the bundle "A" version "1.1.0" but the the spring configuration of "B" can be randomly parsed using the NamespaceHandler of the version "1.1.0" or of the version "2.0.0" depending of which bundle "A" is installed first. So, when the BeanFactory try to instantiate the bean definitions, the classes cannot be found. Indeed, the class names are those of the other version of the bundle "A".

Reproducible: Always
Comment 1 Glyn Normington CLA 2013-01-28 10:23:20 EST
I'm afraid this is a limitation of the current implementation and would require an enhancement in order to change the behaviour. Reclassifying the bug.
Comment 2 Olaf Otto CLA 2017-02-03 06:21:22 EST
Assigned to upcoming milestone
Comment 3 Olaf Otto CLA 2017-03-24 11:24:16 EDT
For now, this has been the only case that such a change was desirable. I'll close this as won't fix - to be re-opened if any active stake holder experiences the same issues.
Comment 4 Olaf Otto CLA 2017-05-09 09:41:36 EDT
Released - closing.