On Thu, Sep 17, 2009 at 9:52 AM, 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"; >
Doesnt this only detect between Camel 1.x and 2.x? What if you have 2 versions of Camel 1.x such as: 1.6.0 and 1.6.1 running. Which version should it then pick? > 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 >>>> >> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
