On Thu, Sep 17, 2009 at 09:59, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > This must be an universal problem with OSGi + Spring + Your Apps and > having multiple versions in same container.
I think it is. I'll have a closer look as the spring-dm code, but I suspect the only way would be to version the schema correctly. Though in theory, the schema versioning and the camel versioning might be different. The schema version could change only when there is actually a change. A simplier approach would be to bump the schema version at each release: i.e. have something like: http://camel.apache.org/schema/spring/v2.1.0 for camel 2.1.0, and http://camel.apache.org/schema/spring/v2.2.0 for camel 2.2.0. The problem in doing so is that the users need to change the namesapce when they upgrade. > For example Mule ESB is also leveraging spring namespace handler and > thus will have same issue. So what are they doing? > > Don't you have specified in the bundle that contains the camel route > which camel version you want to use? > And if so is it not possible for the OSGi container to wire the > correct camel version to this bundle? > > Or is it a special case with Spring and using spring application > context xml files in the META-INF/service package? > I will investigate, but I was fooled by the namesapce changed between 1.x and 2.x. This means I have no real way to easily test that. I suppose I'll have to create a 2.0.x branch and try there. I'll first have a look at the spring-dm code and see what they do. The most important question is wether they take into account the package wires. I'll also try to investigate adding a blueprint integration, which should solve this very problem in a cleaner way. > > On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet <gno...@gmail.com> wrote: >> Ok, I'm mostly done with the OSGi metadata. >> I've committed fixes to both trunk and 1.x branch. >> >> But my original goal is only partially achieved. >> I've run some basic tests in Karaf and deployed camel 1.6-SNAPSHOT and >> 2.1-SNAPSHOT. >> Then, I deployed a simple spring-powered camel route and dropped it >> into the Karaf deploy folder. >> >> Now the question is: how can I choose which version of camel I want to >> run for my route ? >> I guess part of the problem is that the schema are the same and both >> spring namespace handlers use the same schema. >> I've forced the generated bundle to be wired to camel 2.1, but spring >> was still using the 1.6 schema handler to load the route which was >> failing because of a missing component. >> >> I think we're missing some kind of versioning in the schema ... >> Thoughts ? >> >> On Fri, Sep 4, 2009 at 10:22, Guillaume Nodet <gno...@gmail.com> wrote: >>> I've spotted a few problems in the way the OSGi metadata for camel jars are >>> computed. >>> This makes deploying two versions of camel in OSGi nearly impossible. >>> To fix, I plan to enhance the metadata in two ways: >>> >>> #1. bundles should not import the packages they export >>> Here's an example what happen when you do so: >>> * install bundle A version vx that export foo.bar and import it >>> the OSGi framework will decide that A export this package because no >>> other package is available >>> * install the same bundle in version vy >>> as some of the packages are already exported by the first version of A, >>> the OSGi resolver may choose >>> to have this bundle import the package in version vx (provided that the >>> version constraints match) >>> this means that this bundle will not use its own classes for all the >>> packages that are in common, leading >>> to obvious problems >>> So not importing the package means that the OSGi framework will always use >>> the classes from inside the bundle. >>> >>> #2. always use version ranges >>> * For non camel imports, I think the default should be to have a range >>> equal to [v,v+1) assuming backward compatibility is preserved on minor >>> releases. So if one bundle has a dependency on foo.bar version 1.1, the >>> range will be [1.1,2) meaning the framework is allowed to choose any package >>> with a version >= 1.1 but < 2.0 >>> * for camel imports, this is a bit trickier. I think the default range >>> should be restricted to minor versions, i.e. [1.1,1.2) >>> >>> The problem here is to allow someone to update a camel component or core >>> without updating the whole camel jars, so we need some flexibility on this >>> range. But usually, I don't think we really ensure full backward >>> compatibility between minor versions, so having [2.0,3) might not be a good >>> idea. >>> Furthermore, this would mean that you can't really deploy two different >>> minor versions of camel in the same framework, which I think is desirable. >>> >>> Now, the tricky part is to make sure that we always use consistent classes. >>> For example when camel-core discover a component, we don't really want >>> camel-core 1.4 discovering camel 2.0 components, as this would fail. So >>> the discovery mechanism has to be enhanced to make sure we load compatible >>> classes. >>> In OSGi, this can be done by loading a class from the component bundle and >>> making sure it's the same as our. >>> For example: >>> componentBundle.loadClass(org.apache.camel.Endpoint.class.getName()) == >>> org.apache.camel.Endpoint.class >>> This way, the discovery mechanism will be retricted to components that are >>> actually wired to this camel-core bundle. >>> >>> So at the end we should be able to: >>> * deploy multiple versions of camel, provided they have different minor >>> releases (ex: 1.4, 2.0, 2.1) >>> * upgrade components / core with micro release (ex: camel-core 2.0, >>> camel-spring 2.0.2, camel-atom 2.0.1) >>> And everything should work nicely :-) >>> >>> I'll start updating the OSGi metadata, but any help would be welcome, as >>> there are tons of components here ! >>> Also, any volunteer for upgrading and testing the discovery mechanism is >>> welcomed ! >>> >>> -- >>> Cheers, >>> Guillaume Nodet >>> ------------------------ >>> Blog: http://gnodet.blogspot.com/ >>> ------------------------ >>> Open Source SOA >>> http://fusesource.com >>> >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
