On Fri, Sep 4, 2009 at 11:22, Willem Jiang <willem.ji...@gmail.com> wrote:
> +1 for #1, > > for the #2, I think we could let the component dependent on the version > ranges of camel-core, camel-spring, camel-osgi. > But for camel-core, camel-spring and camel-osgi, they should dependent each > other with specific version. > > Why ? This would prevent from upgrading one of those bundles without upgrading the others. > Willem > > > > Guillaume Nodet 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
