| Gemini blueprint: Spring NamespaceHandler management [message #764674] |
Mon, 12 December 2011 16:38  |
 Frederic Boucher
Messages: 3
Registered: December 2011 |
Junior Member |
|
|
Hello,
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 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".
To workaround this issue, we have to create a new bundle "X" with a "META-INF/spring.handlers" file and each bundle "A" have a "META-INF/internal-spring.handlers" file. The NamespaceHandler implementation of the bundle "X" resolves the NamespaceHandler implementation to use by loading the resources ("META-INF/internal-spring.handlers") available through the ClassLoader of the bundle "B".
This is the excepted behaviour? Or can I report this as a bug?
best regards,
Frédéric
[Updated on: Mon, 12 December 2011 16:39] Report message to a moderator |
|
|
| Re: Gemini blueprint: Spring NamespaceHandler management [message #766870 is a reply to message #764674] |
Fri, 16 December 2011 15:23  |
Costin Leau
Messages: 45
Registered: February 2010 |
Member |
|
|
One advice would be try Gemini Blueprint since there was some updates to that piece of the code, if memory serves me right.
As for your problem, is not that easy to sort this one out just on the OSGi level but there are workarounds. Assuming there are two namespaces, A1 and A2 - if they both point to the same schema location (which does not contain any version) then any one of them can be used to parse the xml. This is not a bug, it's what the declaration of the namespace actually say - it's a tie so it usually boils down to the underlying data structure that holds them (map vs linked map) or the startup order.
The extender does some filtering to figure out whether the registered namespace is compatible with the Spring version (potentially) used by the client bundle however it does not check for any duplicate namespace. It's something out of scope, hard to detect (the extender would have to traverse all classloaders) and more over dangerous since it forces the bundle class loader to be initialized which is quite intrusive (as it has to look at the namespace handler, try to check compatibility but triggering class loading, etc...).
These being said, in your case you should be able to solve this by properly identifying the proper version of the XSD you want to use, and thus the associated namespace handlers (this is holds true not just for OSGi but in general). So in your schema location point to schema-1.0.xsd and schema-2.0.xsd rather then schema.xsd which is usually an alias that means - the latest version of schema.xsd which in case of multiple versions (with multiple aliases) can cause confusion.
Hope this helps.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03196 seconds
] 
Search
Help
Register
Login
Home
