L.S., How about we register the default namespace "http://camel.apache.org/schema/spring"; as well as a version-specific namespace "http://camel.apache.org/schema/spring/2.1"; with the namespace handler? If people are only using one version, they can still use the default namespace and if they want to mix and match camel versions, they'd need to add the version to disambiguate between them by adding the version.
We probably want to stick with a 2.x version and avoid any schema-breaking changes between 2.1.0 and 2.1.x e.g. though, to avoid that people would have to update their files on every minor upgrade. Regards, Gert Vanthienen ------------------------ Open Source SOA: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ 2009/9/17 Guillaume Nodet <gno...@gmail.com>: > Right, I missed that. So the point is moot. > But as Claus noted, the problem will also happen between 2.1.x and 2.2.x ... > > On Thu, Sep 17, 2009 at 09:52, Willem Jiang <willem.ji...@gmail.com> wrote: >> Hi Guillaume, >> >> Camel 1.6.x is still using the old namespace for the namespace handler >> "http://activemq.apache.org/camel/schema/spring"; >> >> Can you check if your camel context is updated to new camel namespace >> "http://camel.apache.org/schema/spring"; >> >> Willem >> >> Guillaume Nodet wrote: >>> >>> Unfortunately, I doubt it will work. The reason is that only the >>> schema namespace is used to choose the namespace handler, not it's >>> location, and both namespaces are defined by: >>> http://camel.apache.org/schema/spring >>> >>> On Thu, Sep 17, 2009 at 09:31, Charles Moulliard <cmoulli...@gmail.com> >>> wrote: >>>> >>>> Guillaume, >>>> >>>> I think that you can solve easily the problem by specifying in the xml >>>> file, >>>> the version of the camel-spring file >>>> >>>> By default, you don't mention it in the schema location and the last ont >>>> will be used (so now 2.0) >>>> >>>> xsi:schemaLocation=" >>>> http://www.springframework.org/schema/beans >>>> http://www.springframework.org/schema/beans/spring-beans.xsd >>>> http://www.springframework.org/schema/context >>>> http://www.springframework.org/schema/context/spring-context.xsd >>>> http://www.springframework.org/schema/osgi >>>> http://www.springframework.org/schema/osgi/spring-osgi.xsd >>>> http://camel.apache.org/schema/osgi >>>> http://camel.apache.org/schema/osgi/camel-osgi.xsd >>>> http://camel.apache.org/schema/spring >>>> http://camel.apache.org/schema/spring/camel-spring.xsd";> >>>> >>>> Can you try this ? >>>> >>>> xsi:schemaLocation=" >>>> http://www.springframework.org/schema/beans >>>> http://www.springframework.org/schema/beans/spring-beans.xsd >>>> http://www.springframework.org/schema/context >>>> http://www.springframework.org/schema/context/spring-context.xsd >>>> http://www.springframework.org/schema/osgi >>>> http://www.springframework.org/schema/osgi/spring-osgi.xsd >>>> http://camel.apache.org/schema/osgi >>>> http://camel.apache.org/schema/osgi/camel-osgi.xsd >>>> http://camel.apache.org/schema/spring >>>> http://camel.apache.org/schema/spring/camel-spring-2.1-SNAPSHOT.xsd >>>> "> >>>> >>>> Regards, >>>> >>>> Charles Moulliard >>>> Senior Enterprise Architect >>>> Apache Camel Committer >>>> >>>> ***************************** >>>> blog : http://cmoulliard.blogspot.com >>>> >>>> >>>> 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 >>>>> >>> >>> >>> >> >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com >
