camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: Camel, OSGi and versioning
Date Thu, 17 Sep 2009 07:52:47 GMT
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 <cmoulliard@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 <gnodet@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 <gnodet@gmail.com> wrote:
>>>> I've spotted a few problems in the way the OSGi metadata for camel jars
>>> are
>>>> computed.
>>>> This makes deploying two versions of camel in OSGi nearly impossible.
>>>> To fix, I plan to enhance the metadata in two ways:
>>>>
>>>> #1. bundles should not import the packages they export
>>>> Here's an example what happen when you do so:
>>>>    * install bundle A version vx that export foo.bar and import it
>>>>      the OSGi framework will decide that A export this package because no
>>>> other package is available
>>>>   * install the same bundle in version vy
>>>>      as some of the packages are already exported by the first version of
>>> A,
>>>> the OSGi resolver may choose
>>>>      to have this bundle import the package in version vx (provided that
>>> the
>>>> version constraints match)
>>>>      this means that this bundle will not use its own classes for all the
>>>> packages that are in common, leading
>>>>      to obvious problems
>>>> So not importing the package means that the OSGi framework will always
>>> use
>>>> the classes from inside the bundle.
>>>>
>>>> #2. always use version ranges
>>>>   * For non camel imports, I think the default should be to have a range
>>>> equal to [v,v+1) assuming backward compatibility is preserved on minor
>>>> releases.  So if one bundle has a dependency on foo.bar version 1.1, the
>>>> range will be [1.1,2) meaning the framework is allowed to choose any
>>> package
>>>> with a version >= 1.1 but < 2.0
>>>>   * for camel imports, this is a bit trickier.  I think the default range
>>>> should be restricted to minor versions, i.e. [1.1,1.2)
>>>>
>>>> The problem here is to allow someone to update a camel component or core
>>>> without updating the whole camel jars, so we need some flexibility on
>>> this
>>>> range.  But usually, I don't think we really ensure full backward
>>>> compatibility between minor versions, so having [2.0,3) might not be a
>>> good
>>>> idea.
>>>> Furthermore, this would mean that you can't really deploy two different
>>>> minor versions of camel in the same framework, which I think is
>>> desirable.
>>>> Now, the tricky part is to make sure that we always use consistent
>>> classes.
>>>> For example when camel-core discover a component, we don't really want
>>>> camel-core 1.4 discovering camel 2.0 components, as this would fail.   So
>>>> the discovery mechanism has to be enhanced to make sure we load
>>> compatible
>>>> classes.
>>>> In OSGi, this can be done by loading a class from the component bundle
>>> and
>>>> making sure it's the same as our.
>>>> For example:
>>>>     componentBundle.loadClass(org.apache.camel.Endpoint.class.getName())
>>> ==
>>>> org.apache.camel.Endpoint.class
>>>> This way, the discovery mechanism will be retricted to components that
>>> are
>>>> actually wired to this camel-core bundle.
>>>>
>>>> So at the end we should be able to:
>>>>   * deploy multiple versions of camel, provided they have different minor
>>>> releases (ex: 1.4, 2.0, 2.1)
>>>>   * upgrade components / core with micro release (ex: camel-core 2.0,
>>>> camel-spring 2.0.2, camel-atom 2.0.1)
>>>> And everything should work nicely :-)
>>>>
>>>> I'll start updating the OSGi metadata, but any help would be welcome, as
>>>> there are tons of components here !
>>>> Also, any volunteer for upgrading and testing the discovery mechanism is
>>>> welcomed !
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
> 
> 
> 


Mime
View raw message