I've looked at both spring-dm and blueprint, and there is no way to have a single schema namespace supported by two different handlers. I mean, you can always do that, but you have no way to control which one will be used. So I guess versionning the schema is the only solution.
Having the schema versioned with 2.1, 2.2, etc sounds good to me. On Thu, Sep 17, 2009 at 10:27, Gert Vanthienen <gert.vanthie...@gmail.com> wrote: > 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 >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
