tag:blogger.com,1999:blog-30094322.post5458429901359027799..comments2023-11-23T13:43:45.322+01:00Comments on Guillaume Nodet's blog: Spring-DM, Aries Blueprint and custom namespacesGuillaume Nodethttp://www.blogger.com/profile/16560449735432714687noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-30094322.post-63874675370616767372012-10-02T02:44:27.508+02:002012-10-02T02:44:27.508+02:00Hi Guillaume,
We are using FUSEESB which runs on K...Hi Guillaume,<br />We are using FUSEESB which runs on Karaf.<br />It is very common that the blueprint file is not able to resolve any of the spring namespaces. For most of the implementation blueprint has created its own implementation which resolves most of the senarios. but in case we want to use spring namespaces in blueprint it becomes impossible. Adding a service with blueprint Namespace handler did not help or probably I am not sure if it was done correctly.<br /><br />If there is way to resolve this then we will be able to use lot of spring features with blueprint. ranajithttps://www.blogger.com/profile/05588473418655729447noreply@blogger.comtag:blogger.com,1999:blog-30094322.post-1929143305552490252010-03-17T20:25:38.490+01:002010-03-17T20:25:38.490+01:00Spring is used heavily in non-OSGi environment and...Spring is used heavily in non-OSGi environment and such the overwhelming majority of namespace handler implementations simply are unaware of it. These need to be supported and that's why the extender pattern was chosen.<br /><br />It has worked great so far and except the ordering issue (which again we decided to not address ourselves with dm Server/Eclipse Virgo and the proposals in the OSGi Alliance).<br /><br />You mention that Spring DM is "fully backwards compatible" - which is what we (Spring DM team) wanted, but does this mean your approach is not? And if so, can you point out in what ways?<br /><br />Do you provide a different namespace handler abstraction or reuse the existing one?<br /><br />Regarding 3), we'll probably have to take this offline since don't understand why the client needs to load the classes provided by the namespace handler. The handler can just inject the classes into the container (which is what happens now) - it's simple, clean and efficient.<br /><br />For 4), I never encountered that case before. From you are telling me, the namespace/schema model was extended from a one to one mapping, to one to many. I'll see what I can do to support this in the next version but it would help to get some more information on your exact case - are there some links out there that you can share?Unknownhttps://www.blogger.com/profile/03881675961973813695noreply@blogger.comtag:blogger.com,1999:blog-30094322.post-86544684462306527752010-03-17T13:55:04.195+01:002010-03-17T13:55:04.195+01:00Costin, I think you missed some of my points.
W...Costin, I think you missed some of my points. <br /><br />What happens at the end is that as soon as you use custom namespaces you need to fully control the start order of all bundles so that bundles containing namespace handlers are started before the application bundles. And that's independent of the number of namespace handlers used. The problem is that Spring-DM decided to keep full backward compatibility so that dropping a spring namespace handler (using the META-INF folder) in osgi would work with spring-dm. Using a whiteboard pattern for the handlers would have been more appropriate I think. <br /><br />A staged parsing would then have been able to preparse the xml files, extract the namespaces in use and wait for those to be available (as it's done in the grace period).<br /><br />On point 3, I don't understand what you're saying. When you implement a custom namespace, the clients of this namespace don't need to know what implementation classes are used behind the scene. As you say, that's exactly the point of decoupling. The problem is that the current design of Spring namespaces does not allow that, thus this very problem of packages surfaces and the clients actually have to care about importing the needed packages in order for the namespace to work. <br /><br />On the last point, I agree that OSGi support that. The problem is that Spring-DM does not support multiple handlers for the same namespace as far as I know. It only supports multiple namespaces wired onto different spring extenders (you still have at most one handler for a given namespace / spring-dm extender), which is not the case I'm talking about. The use case I'm referring to is a bit more subtle than that: it's about running multiple extenders for the same namespace and choose the one according to the class-space consistency of the client. Let's say you have Apache Camel 2.0 and 2.1 running at the same time in the framework, you want to be able to deploy camel routes and have them wired to the right camel version depending on which version of camel the client uses, but that does not mean that you want to version the namespace, because this put additional burden on the clients and the migration to a higher version very painful. <br /><br />And I will for sure bring all that feedback when we'll work on the standardized blueprint namespaces in the OSGi EEG.Guillaume Nodethttps://www.blogger.com/profile/16560449735432714687noreply@blogger.comtag:blogger.com,1999:blog-30094322.post-27550088634411524902010-03-17T12:14:36.311+01:002010-03-17T12:14:36.311+01:00Great post! As soon this will be available in a fu...Great post! As soon this will be available in a future SMX Snapshot we will upgrade to blueprint :-)<br /><br />Regards<br />StefanStefan Webernoreply@blogger.comtag:blogger.com,1999:blog-30094322.post-79242173276419056822010-03-17T11:25:44.801+01:002010-03-17T11:25:44.801+01:00Hi Guillaume,
The issues you listed with namespac...Hi Guillaume,<br /><br />The issues you listed with namespaces are side-effects of a generic problem in OSGi regarding resource discovery and sharing - otherwise known as the extender pattern.<br />While types (as in java.lang.Class) are versioned and treated as first-class citizens in OSGi, resources (as in files) are not. You can share the packages in which files are defined (as long as they follow the java conventions which means META-INF/ cannot be used) but you still cannot differentiate them apart as there is no equivalent of a ClassLoader or a resource-consistent space. A common example is the META-INF/services location - without dedicated support from the OSGi framework, it's pretty much impossible to leverage this mechanism in OSGi (without modifying existing jars or duplicating the OSGi resolver).<br />However, as you probably know, there are proposals in the OSGi Alliance to address this gap (which we plan to incorporate).<br /><br />As for actual solutions to the problems mentioned:<br /><br />1. Depending on the number of namespaces used, ordering the bundles might be needed. Spring DM doesn't address this yet but dm Server (upcoming Eclipse Virgo) does.<br />Moreover, as you probably know, namespaces are currently discussed for the next Blueprint spec release.<br /><br />2. Falls under 1) category however we have plan to improve the current behaviour (regardless of 1) in the next release).<br /><br />3. The namespace handler implementation details (let alone class loading) are not the concern of the client - that's the whole point of decoupling after all. As for technicalities, the namespaces are services (as you've mentioned) that are bound to their declaring bundle, which means they do have a consistent class space (guaranteed by<br />the OSGi platform). Spring DM checks the compatibility between the namespace handler and the client and further more, for the rare cases where the handler has an intrusive approach, one can simply enforce consistency through the existing OSGi manifest directives.<br /><br />4. If you want to use different versions of a custom namespace/schema, you can either version it (which is a best practice and it makes sense) or not (in which case Spring DM treats it as having a "default" version). At runtime, the best matching "class consistent" version is picked up but then again, for the cases where this doesn't apply, the OSGi directive can solve this elegantly, out of the box.<br /><br />These being said, I'm glad to see Spring namespaces supported in Aries and interested to know more about the problems you faced and how you addressed them.<br /><br />Cheers,<br />Costin Leau<br />Spring DM/Blueprint RI LeadUnknownhttps://www.blogger.com/profile/03881675961973813695noreply@blogger.com