You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/09/04 10:22:50 UTC
Camel, OSGi and versioning
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
Re: Camel, OSGi and versioning
Posted by Oisin Hurley <oi...@gmail.com>.
> So while importing exported packages is fine to reduce class fragmentation,
> this should only be done for substituable packages, such as specifications,
> etc... For jars that don't provide any services, such as libraries
> transformed into OSGi bundles, this should be really avoided.
Of course, that makes sense, thanks for the clarification Guillaume!
--oh
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, let's take an example: we want to publish a transaction manager
implementing javax.transaction.TransactionManager
To reduce class fragmentation, we want to import / export the
javax.transaction.xa package. This way, if another bundle provides the same
package, our bundle will be wired to that one instead of having the same
package exported twice. For the implementation (in case we want to export
it), we don't really want to import our own package, else we may be wired to
another version of the same package, which does not make sense, because our
bundle is really supposed to provide this package in the given version.
If we don't do that, this leads to very undesirable behavior: let's say our
implementation package is foo.bar
If we deploy our bundle in version 1.2, we will end up with the following
wirings for our bundle:
export javax.transaction.xa ; version = 1.1
export foo.bar ; version = 1.2
Later, if we deploy the same bundle in version 1.1, we will end up with the
following wirings
import javax.transaction.xa ; version = 1.1 (from bundle v1.2)
import foo.bar ; version = 1.2 (from bundle v1.2)
Now let's say that between foo.bar v1.2 and v1.1, one class has been
refactored as an inner class, then we could easily end up in
NoClassDefFoundError in bundle v1.1, because the package comes from v1.2 and
this class does not exists ...
So while importing exported packages is fine to reduce class fragmentation,
this should only be done for substituable packages, such as specifications,
etc... For jars that don't provide any services, such as libraries
transformed into OSGi bundles, this should be really avoided.
See
http://felix.apache.org/site/apache-felix-osgi-faq.html#ApacheFelixOSGiFAQ-Shouldabundleimportitsownexportedpackages?
also
On Tue, Sep 8, 2009 at 12:56, Oisin Hurley <oi...@gmail.com> wrote:
> > #1. bundles should not import the packages they export
>
> This is kindof contrary to what OSGi recommends - that you should
> always import what you export to prevent class fragmentation in
> consumer bundles.
>
> Full gory details here
>
> http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
>
>
> --oh
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel, OSGi and versioning
Posted by Oisin Hurley <oi...@gmail.com>.
> #1. bundles should not import the packages they export
This is kindof contrary to what OSGi recommends - that you should
always import what you export to prevent class fragmentation in
consumer bundles.
Full gory details here
http://www.osgi.org/blog/2007/04/importance-of-exporting-nd-importing.html
--oh
Re: Camel, OSGi and versioning
Posted by Charles Moulliard <cm...@gmail.com>.
I forget to mention:
camel-osgi,
camel-quickfix,
camel-activemq
I suppose that you will make modifications first with camel-core.
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
On Fri, Sep 4, 2009 at 10:42 AM, Charles Moulliard <cm...@gmail.com>wrote:
> Hi Guillaume,
>
> I have been confronted yesterday to the problem that you describe here
> (moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
> version range as they assume also a certain level of compatibility within
> release. It means also that before to commit every new change, developers
> have top take care about versioning ;-)
>
> I propose to work on the following components as I use them in my platform
> :
> camel-bindy,
> camel-jms,
> camel-ognl,
> camel-stream,
> camel-quartz,
> camel-spring
>
> Can you provide an example that I can use to adapt components mentioned.
>
> When modifications will be done, I will test them within my project
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gn...@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
>>
>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
I've attached a patch at
https://issues.apache.org/activemq/browse/CAMEL-1988 and put some
instructions on how to change a given component.
FWIW, I haven't had any time to test the whole thing in OSGi, but that may
mean we need to backport that stuff onto camel-1.x branch, at least to test
it.
On Fri, Sep 4, 2009 at 10:42, Charles Moulliard <cm...@gmail.com>wrote:
> Hi Guillaume,
>
> I have been confronted yesterday to the problem that you describe here
> (moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
> version range as they assume also a certain level of compatibility within
> release. It means also that before to commit every new change, developers
> have top take care about versioning ;-)
>
> I propose to work on the following components as I use them in my platform
> :
> camel-bindy,
> camel-jms,
> camel-ognl,
> camel-stream,
> camel-quartz,
> camel-spring
>
> Can you provide an example that I can use to adapt components mentioned.
>
> When modifications will be done, I will test them within my project
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gn...@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
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
I don't remember why we use that flag, so feel free to remove it.
But I did have trouble to set the version range (such as import package
of CXF, mina) with that falg set to be true.
Willem
Guillaume Nodet wrote:
> Will do. Still working on that.
> I'm working on camel-core and camel-spring and will commit when I have
> something that looks good.
>
> Btw, anyone know why the flag camel.osgi.exclude.dependencies is set to true
> ?
> It seems it makes the maven bundle plugin ignore versions from the
> dependencies. Without this flag, we can't have default computed version
> ranges.
>
> On Fri, Sep 4, 2009 at 10:42, Charles Moulliard <cm...@gmail.com>wrote:
>
>> Hi Guillaume,
>>
>> I have been confronted yesterday to the problem that you describe here
>> (moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
>> version range as they assume also a certain level of compatibility within
>> release. It means also that before to commit every new change, developers
>> have top take care about versioning ;-)
>>
>> I propose to work on the following components as I use them in my platform
>> :
>> camel-bindy,
>> camel-jms,
>> camel-ognl,
>> camel-stream,
>> camel-quartz,
>> camel-spring
>>
>> Can you provide an example that I can use to adapt components mentioned.
>>
>> When modifications will be done, I will test them within my project
>>
>> Regards,
>>
>> Charles Moulliard
>> Senior Enterprise Architect
>> Apache Camel Committer
>>
>> *****************************
>> blog : http://cmoulliard.blogspot.com
>>
>>
>> On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gn...@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
>>>
>
>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Will do. Still working on that.
I'm working on camel-core and camel-spring and will commit when I have
something that looks good.
Btw, anyone know why the flag camel.osgi.exclude.dependencies is set to true
?
It seems it makes the maven bundle plugin ignore versions from the
dependencies. Without this flag, we can't have default computed version
ranges.
On Fri, Sep 4, 2009 at 10:42, Charles Moulliard <cm...@gmail.com>wrote:
> Hi Guillaume,
>
> I have been confronted yesterday to the problem that you describe here
> (moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
> version range as they assume also a certain level of compatibility within
> release. It means also that before to commit every new change, developers
> have top take care about versioning ;-)
>
> I propose to work on the following components as I use them in my platform
> :
> camel-bindy,
> camel-jms,
> camel-ognl,
> camel-stream,
> camel-quartz,
> camel-spring
>
> Can you provide an example that I can use to adapt components mentioned.
>
> When modifications will be done, I will test them within my project
>
> Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
>
>
> On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gn...@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
Re: Camel, OSGi and versioning
Posted by Charles Moulliard <cm...@gmail.com>.
Hi Guillaume,
I have been confronted yesterday to the problem that you describe here
(moving some components from camel 2.0 to 2.1-SNAPSHOT). I prefer to use
version range as they assume also a certain level of compatibility within
release. It means also that before to commit every new change, developers
have top take care about versioning ;-)
I propose to work on the following components as I use them in my platform :
camel-bindy,
camel-jms,
camel-ognl,
camel-stream,
camel-quartz,
camel-spring
Can you provide an example that I can use to adapt components mentioned.
When modifications will be done, I will test them within my project
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
On Fri, Sep 4, 2009 at 10:22 AM, Guillaume Nodet <gn...@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
>
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Sep 4, 2009 at 11:53 AM, Willem Jiang<wi...@gmail.com> wrote:
> Because there are some internal API dependencies between the camel-core ,
> camel-spring. I'm not sure if the OSGi version range can help us to find out
> the minor internal API change.
>
Yeah camel-core and camel-spring are really to tightly coupled that
running with different version of them is not recommended.
Eg routing with XML depends on camel-spring where as the routing model
is in camel-core etc.
So it make most sense to support upgrading various other camel
components such as for example camel-jetty, camel-http, camel-velocity
etc.
> Willem
>
> Guillaume Nodet wrote:
>>
>> On Fri, Sep 4, 2009 at 11:22, Willem Jiang <wi...@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 !
>>>>
>>>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
Because there are some internal API dependencies between the camel-core
, camel-spring. I'm not sure if the OSGi version range can help us to
find out the minor internal API change.
Willem
Guillaume Nodet wrote:
> On Fri, Sep 4, 2009 at 11:22, Willem Jiang <wi...@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 !
>>>
>>>
>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Sep 4, 2009 at 11:22, Willem Jiang <wi...@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
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
+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.
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 !
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 17, 2009 at 09:59, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> This must be an universal problem with OSGi + Spring + Your Apps and
> having multiple versions in same container.
I think it is. I'll have a closer look as the spring-dm code, but I
suspect the only way would be to version the schema correctly.
Though in theory, the schema versioning and the camel versioning might
be different. The schema version could change only when there is
actually a change.
A simplier approach would be to bump the schema version at each
release: i.e. have something like:
http://camel.apache.org/schema/spring/v2.1.0
for camel 2.1.0, and
http://camel.apache.org/schema/spring/v2.2.0
for camel 2.2.0.
The problem in doing so is that the users need to change the namesapce
when they upgrade.
> For example Mule ESB is also leveraging spring namespace handler and
> thus will have same issue. So what are they doing?
>
> Don't you have specified in the bundle that contains the camel route
> which camel version you want to use?
> And if so is it not possible for the OSGi container to wire the
> correct camel version to this bundle?
>
> Or is it a special case with Spring and using spring application
> context xml files in the META-INF/service package?
>
I will investigate, but I was fooled by the namesapce changed between
1.x and 2.x.
This means I have no real way to easily test that. I suppose I'll
have to create a 2.0.x branch and try there.
I'll first have a look at the spring-dm code and see what they do. The
most important question is wether they take into account the package
wires.
I'll also try to investigate adding a blueprint integration, which
should solve this very problem in a cleaner way.
>
> On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet <gn...@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 <gn...@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
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
This must be an universal problem with OSGi + Spring + Your Apps and
having multiple versions in same container.
For example Mule ESB is also leveraging spring namespace handler and
thus will have same issue. So what are they doing?
Don't you have specified in the bundle that contains the camel route
which camel version you want to use?
And if so is it not possible for the OSGi container to wire the
correct camel version to this bundle?
Or is it a special case with Spring and using spring application
context xml files in the META-INF/service package?
On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
+1 for adding the version number on the camel-spring namespace.
But I don't know if the "http://camel.apache.org/schema/spring/2.1" is
enough for use to pick the camel-spring 2.1.x instead of camel 2.1.0.
Willem
Gert Vanthienen 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 <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
>>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Sep 17, 2009 at 11:17, Claus Ibsen <cl...@gmail.com> wrote:
> On Thu, Sep 17, 2009 at 10:55 AM, Guillaume Nodet <gn...@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
>> <ge...@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 <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Oisin Hurley <oi...@gmail.com>.
>> Having the schema versioned with 2.1, 2.2, etc sounds good to me.
+1 for versioning the schema - from the tools p.o.v. it
makes life easier as things like XML editors can cope
better with on-the-fly validation and element/attribute
completion options.
> 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?
I would attempt to avoid this situation by ensuring that the
schema is present in the Camel OSGi bundle, basically
tying it to the declared bundle version, then the Camel build
can keep them in sync.
> 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.
With Eclipse at least, versioning in the namespace is the best
way to go, because then there's no clash when we register the
schema with the XML catalog extension (for editing), plus all
we need to do is pull that namespace and key off the version
at the end to choose EIP diagram validation strategies and
deployment capabilities...
cheers
--oh
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 17, 2009 at 10:55 AM, Guillaume Nodet <gn...@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?
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
> <ge...@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 <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
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.
On Thu, Sep 17, 2009 at 10:27, Gert Vanthienen
<ge...@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 <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Gert Vanthienen <ge...@gmail.com>.
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 <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@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 <wi...@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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Sep 17, 2009 at 9:52 AM, Willem Jiang <wi...@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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
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 <cm...@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 <gn...@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 <gn...@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
>>>
>
>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <cm...@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 <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Charles Moulliard <cm...@gmail.com>.
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 <gn...@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 <gn...@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
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Same here.
On Thu, Sep 17, 2009 at 10:49, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus,
>
> The mock-javamail-1.7 building is passed on my box.
> Here is my environment.
>
> Apache Maven 2.2.0 (r788681; 2009-06-26 21:04:01+0800)
> Java version: 1.5.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.5.8" arch: "i386" Family: "unix"
>
> Willem
>
> Claus Ibsen wrote:
>>
>> This one is failing with a mvn clean install -Dtest=false from camel trunk
>>
>> [INFO] Building Apache Camel Test Bundles: mock-javamail-1.7
>> [INFO] task-segment: [clean, install]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [clean:clean]
>> [INFO] Deleting file set:
>>
>> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target
>> (included: [**], excluded: [])
>> [INFO] [dependency:copy {execution: copy-legal}]
>> [INFO] Configured Artifact: org.apache.servicemix.legal:legal:1.0:xml
>> [INFO] Copying legal-1.0.xml to
>>
>> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/legal/legal.xml
>> [INFO] [remote-resources:process {execution: default}]
>> [INFO] [resources:resources]
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 6 resources
>> [INFO] Copying 3 resources
>> [INFO] [compiler:compile]
>> [INFO] Compiling 3 source files to
>>
>> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/classes
>> [INFO] [resources:testResources]
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] skip non existing resourceDirectory
>>
>> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/src/test/resources
>> [INFO] Copying 3 resources
>> [INFO] [compiler:testCompile]
>> [INFO] No sources to compile
>> [INFO] [surefire:test]
>> [INFO] Tests are skipped.
>> [INFO] [bundle:bundle]
>> [ERROR] Error building bundle
>>
>> org.apache.camel.tests:org.apache.camel.tests.mock-javamail_1.7:bundle:2.1-SNAPSHOT
>> : No value after '=' sign for attribute version
>> [ERROR] Error(s) found in bundle configuration
>> [INFO]
>> ------------------------------------------------------------------------
>> [ERROR] BUILD ERROR
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Error(s) found in bundle configuration
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] For more information, run Maven with the -e switch
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 7 minutes 3 seconds
>> [INFO] Finished at: Thu Sep 17 09:58:42 CEST 2009
>> [INFO] Final Memory: 121M/216M
>> [INFO]
>> ------------------------------------------------------------------------
>>
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Camel, OSGi and versioning
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus,
The mock-javamail-1.7 building is passed on my box.
Here is my environment.
Apache Maven 2.2.0 (r788681; 2009-06-26 21:04:01+0800)
Java version: 1.5.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.5.8" arch: "i386" Family: "unix"
Willem
Claus Ibsen wrote:
> This one is failing with a mvn clean install -Dtest=false from camel trunk
>
> [INFO] Building Apache Camel Test Bundles: mock-javamail-1.7
> [INFO] task-segment: [clean, install]
> [INFO] ------------------------------------------------------------------------
> [INFO] [clean:clean]
> [INFO] Deleting file set:
> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target
> (included: [**], excluded: [])
> [INFO] [dependency:copy {execution: copy-legal}]
> [INFO] Configured Artifact: org.apache.servicemix.legal:legal:1.0:xml
> [INFO] Copying legal-1.0.xml to
> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/legal/legal.xml
> [INFO] [remote-resources:process {execution: default}]
> [INFO] [resources:resources]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 6 resources
> [INFO] Copying 3 resources
> [INFO] [compiler:compile]
> [INFO] Compiling 3 source files to
> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/classes
> [INFO] [resources:testResources]
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/src/test/resources
> [INFO] Copying 3 resources
> [INFO] [compiler:testCompile]
> [INFO] No sources to compile
> [INFO] [surefire:test]
> [INFO] Tests are skipped.
> [INFO] [bundle:bundle]
> [ERROR] Error building bundle
> org.apache.camel.tests:org.apache.camel.tests.mock-javamail_1.7:bundle:2.1-SNAPSHOT
> : No value after '=' sign for attribute version
> [ERROR] Error(s) found in bundle configuration
> [INFO] ------------------------------------------------------------------------
> [ERROR] BUILD ERROR
> [INFO] ------------------------------------------------------------------------
> [INFO] Error(s) found in bundle configuration
> [INFO] ------------------------------------------------------------------------
> [INFO] For more information, run Maven with the -e switch
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7 minutes 3 seconds
> [INFO] Finished at: Thu Sep 17 09:58:42 CEST 2009
> [INFO] Final Memory: 121M/216M
> [INFO] ------------------------------------------------------------------------
>
>
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, this is because OSGi versioning is strictly defined.
So we need to translate the maven version into an OSGi version.
Usually, the work is done by the maven bundle plugin, but in our case,
it's not completely covered yet, so I had to do a bit of maven-antrun
plugin to do this transformation.
I plan to add that into the maven-bundle-plugin asap.
On Thu, Sep 17, 2009 at 10:02, Claus Ibsen <cl...@gmail.com> wrote:
> Hi
>
> Just wondering about the versions below. I assume its correct that
> OSGI is not identical to the maven version?
>
>
>
> [INFO] Executing tasks
> [echo] Maven version: 2.1-SNAPSHOT
> [echo] OSGi version: 2.1.0.SNAPSHOT
> [mkdir] Created dir: /Users/davsclaus/workspace/camel/tooling/target
>
> --
> 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
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
Just wondering about the versions below. I assume its correct that
OSGI is not identical to the maven version?
[INFO] Executing tasks
[echo] Maven version: 2.1-SNAPSHOT
[echo] OSGi version: 2.1.0.SNAPSHOT
[mkdir] Created dir: /Users/davsclaus/workspace/camel/tooling/target
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Camel, OSGi and versioning
Posted by Claus Ibsen <cl...@gmail.com>.
This one is failing with a mvn clean install -Dtest=false from camel trunk
[INFO] Building Apache Camel Test Bundles: mock-javamail-1.7
[INFO] task-segment: [clean, install]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting file set:
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target
(included: [**], excluded: [])
[INFO] [dependency:copy {execution: copy-legal}]
[INFO] Configured Artifact: org.apache.servicemix.legal:legal:1.0:xml
[INFO] Copying legal-1.0.xml to
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/legal/legal.xml
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 3 source files to
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/target/classes
[INFO] [resources:testResources]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory
/Users/davsclaus/workspace/camel/tests/test-bundles/mock-javamail_1.7/src/test/resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [bundle:bundle]
[ERROR] Error building bundle
org.apache.camel.tests:org.apache.camel.tests.mock-javamail_1.7:bundle:2.1-SNAPSHOT
: No value after '=' sign for attribute version
[ERROR] Error(s) found in bundle configuration
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error(s) found in bundle configuration
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 minutes 3 seconds
[INFO] Finished at: Thu Sep 17 09:58:42 CEST 2009
[INFO] Final Memory: 121M/216M
[INFO] ------------------------------------------------------------------------
On Thu, Sep 17, 2009 at 9:19 AM, Guillaume Nodet <gn...@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 <gn...@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
Re: Camel, OSGi and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@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