On Thu, Sep 17, 2009 at 11:17, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Thu, Sep 17, 2009 at 10:55 AM, Guillaume Nodet <gno...@gmail.com> wrote: >> 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. > > Hmmm so in all other situations with OSGi you need to control > versioning in MANIFEST.MF files > and then suddenly you need to do this specially for Camel? What > happens when your bundle (which contains the camel xml route) > has X version of Camel in MANIFEST.MF and then schema version have > version Y? You need to keep them in sync? > > And this also doesn't leverage existing tooling for OSGi? Or am I mistaking?
Right, but in this case, this is not a problem we can fix in camel. The problem comes from the way spring-dm uses the namespace handlers. There is no support for multiple namespace handlers supporting the same schema ... We could imagine that if that was the case, but this isn't unfortunately. > I would really like there was a more "standard" way for this. > > If this is the only solution then the people working on 3rd party > tooling such as Fuse Integration Designer needs to be aware of this so > they can add tooling support > for specifying Camel versions in the XML files. > > > >> >> 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 >> > > > > -- > 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
