Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Gemini » Gemini blueprint: Spring NamespaceHandler management
Gemini blueprint: Spring NamespaceHandler management [message #764674] Mon, 12 December 2011 16:38 Go to next message
Frederic Boucher is currently offline Frederic BoucherFriend
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 Go to previous messageGo to next message
Costin Leau is currently offline Costin LeauFriend
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.
Re: Gemini blueprint: Spring NamespaceHandler management [message #767938 is a reply to message #766870] Mon, 19 December 2011 08:33 Go to previous messageGo to next message
Frederic Boucher is currently offline Frederic BoucherFriend
Messages: 3
Registered: December 2011
Junior Member
Thanks for your answer.

We use Virgo 3.0.2 built-in with spring-dm 1.2.1. We tried to use spring-dm 2.0.0-M1, but the problem still present.

In our projects, there are one namespace (ex: "A"), but many schemas (ex: "A-1.0.0.xsd" and "A-2.0.0.xsd"). Like spring beans namespaceId is
http:/ /www .springframework.org/schema/beans
and its schemas are
http:/ /www .springframework.org/schema/beans/spring-beans-3.0.xsd
and
http:/ /www .springframework.org/schema/beans/spring-beans-2.5.xsd
etc.

Spring-dm use the namespaceId and not the schema name to resolve the NamespaceHandler. However we can use differents namespaceId but it does not seem to be a common practice ?
Re: Gemini blueprint: Spring NamespaceHandler management [message #792254 is a reply to message #767938] Mon, 06 February 2012 20:01 Go to previous message
Costin Leau is currently offline Costin LeauFriend
Messages: 45
Registered: February 2010
Member
That's because each xsd defines its namespace id - the location can change but its namespace id does not.
Previous Topic:Spring OSGi Service Registration Listener
Next Topic:Blueprint TCCL usage and OSGi
Goto Forum:
  


Current Time: Sun Dec 21 06:21:18 GMT 2014

Powered by FUDForum. Page generated in 0.05124 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software