camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: Camel, OSGi and versioning
Date Thu, 17 Sep 2009 07:19:10 GMT
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 <gnodet@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

Mime
View raw message