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
