You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Willem Jiang <wi...@gmail.com> on 2008/07/28 10:02:37 UTC
Create an extension shared library for servicemix-camel service engine
Hi,
The camel component just contains the core camel jars, but some use
cases require the use of addon components (for example camel-cxf) which
are not present in the core camel jars. If you have multiple SU's with a
dependency on an addon component then you will hit classloading
conflicts (ClassCastException typically ). You currently need to:
1) Add the camel extension components to a jbi shared library
2) Edit the servicemix-camel service engine jbi.xml and add your shared
library.
Having to edit the servicemix-camel jbi.xml is not ideal so this
enhancement is to add a placeholder shared library to the camel-core
component. The shared library can be empty but will need to exist in the
hot deploy directory.
This would eliminate the need to hack the camel component's jbi.xml, you
would just need to edite the camel shared library pom.xml and override
the old camel shared library in the deploy directory.
Any thoughts ?
Willem
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
The ClassCastException happens when there are 2 SU which use camel-cxf
component and camel-cxf component are in their SU's lib at the same
time, or when the SU is reload without restarting SMX.
I know different SU has different class loader which will help to
isolate the SU jars. If a same class loaded by different child class
loader twice, the ClassCastException will happen :(.
Willem
Guillaume Nodet wrote:
> Btw, why / when do these ClassCastException happen ? I do understand
> that each SU would have its own copy of the components, so they can't
> really share any code, but the JBI exchange is just the xml content
> along with the properties. This means some components use POJOs and
> put them in the JBI exchange properties map ? Do you have more infos
> about that ?
>
> On Mon, Jul 28, 2008 at 10:02 AM, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi,
>>
>> The camel component just contains the core camel jars, but some use cases
>> require the use of addon components (for example camel-cxf) which are not
>> present in the core camel jars. If you have multiple SU's with a dependency
>> on an addon component then you will hit classloading conflicts
>> (ClassCastException typically ). You currently need to:
>>
>> 1) Add the camel extension components to a jbi shared library
>>
>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>> library.
>>
>> Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
>> is to add a placeholder shared library to the camel-core component. The
>> shared library can be empty but will need to exist in the hot deploy
>> directory.
>>
>> This would eliminate the need to hack the camel component's jbi.xml, you
>> would just need to edite the camel shared library pom.xml and override the
>> old camel shared library in the deploy directory.
>>
>> Any thoughts ?
>>
>>
>> Willem
>>
>>
>>
>>
>
>
>
>
Re: Create an extension shared library for servicemix-camel service engine
Posted by Guillaume Nodet <gn...@gmail.com>.
Btw, why / when do these ClassCastException happen ? I do understand
that each SU would have its own copy of the components, so they can't
really share any code, but the JBI exchange is just the xml content
along with the properties. This means some components use POJOs and
put them in the JBI exchange properties map ? Do you have more infos
about that ?
On Mon, Jul 28, 2008 at 10:02 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi,
>
> The camel component just contains the core camel jars, but some use cases
> require the use of addon components (for example camel-cxf) which are not
> present in the core camel jars. If you have multiple SU's with a dependency
> on an addon component then you will hit classloading conflicts
> (ClassCastException typically ). You currently need to:
>
> 1) Add the camel extension components to a jbi shared library
>
> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
> library.
>
> Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
> is to add a placeholder shared library to the camel-core component. The
> shared library can be empty but will need to exist in the hot deploy
> directory.
>
> This would eliminate the need to hack the camel component's jbi.xml, you
> would just need to edite the camel shared library pom.xml and override the
> old camel shared library in the deploy directory.
>
> Any thoughts ?
>
>
> Willem
>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Create an extension shared library for servicemix-camel service engine
Posted by James Strachan <ja...@gmail.com>.
2008/7/29 Guillaume Nodet <gn...@gmail.com>:
> I think some of the problems comes from the fact that ActiveMQ
> includes the activemq camel component, but ActiveMQ is in the
> container classpath, whereas Camel is not. So the activemq camel
> component can not really work, unless you put camel-core in the
> container classpath, or put a copy of activemq in the SU / SL and
> specifiy that you want the self first delegation instead of the
> default parent first. Have you tried for a component other than the
> activemq one ?
This has been refactored now; so that the camel code is separate from
the activemq-core; so hopefully from the next release of ActiveMQ this
issue should go away.
> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com> wrote:
>> Hi Guillaume,
>>
>> Cool , I will head to write a camel-example to show how to create this kind
>> of SU which is using this camel extension SL :)
>>
>> Cheers,
>>
>> Willem
>>
>>
>> Guillaume Nodet wrote:
>>>
>>> I'm actually working on the OSGi bits and should commit something very
>>> soon, so we would not need such a shared library in smx4.
>>> For smx3, is the point #2 really needed ? I would have thought
>>> referencing the SL from the SU would work without problems and without
>>> the need to hack the component's jbi.xml.
>>>
>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>> <ja...@gmail.com> wrote:
>>>
>>>>
>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The camel component just contains the core camel jars, but some use
>>>>> cases
>>>>> require the use of addon components (for example camel-cxf) which are
>>>>> not
>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>> dependency
>>>>> on an addon component then you will hit classloading conflicts
>>>>> (ClassCastException typically ). You currently need to:
>>>>>
>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>
>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>>>>> library.
>>>>>
>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>> enhancement
>>>>> is to add a placeholder shared library to the camel-core component. The
>>>>> shared library can be empty but will need to exist in the hot deploy
>>>>> directory.
>>>>>
>>>>> This would eliminate the need to hack the camel component's jbi.xml, you
>>>>> would just need to edite the camel shared library pom.xml and override
>>>>> the
>>>>> old camel shared library in the deploy directory.
>>>>>
>>>>
>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>>>> then its no longer an issue
>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://open.iona.com
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume,
I don't put the camel-core into the extension SL , camel-core is still
in the servicemix-camel component.
When the servicemix-camel component start up , it will load the jars
from its lib and the extesion SL.
Then the other camel-SUs will not need to load any other
camel-components from their lib to avoid the class loader conflicts.
I already submitted a patch for it [1], please feel free to review it :)
[1]https://issues.apache.org/activemq/browse/SM-1487
Thanks,
Willem
Guillaume Nodet wrote:
> But I still have doubts that it would work. A SL can not have any
> reference to another SL, this means that it would have to include the
> camel-core jar, which would lead to multiple copies of this jar to be
> included and would lead to the same problem.
>
> On Wed, Jul 30, 2008 at 8:33 AM, Willem Jiang <wi...@gmail.com> wrote:
>
>> I just found when starting the cxf SU, the thread context class loader
>> will be set with the SU's component class loader.
>> This will explain why camel-cxf component will not be resolved by the
>> camel-core when we put the camel-cxf into the SL for the cxf SU.
>>
>> I think I had to add the extension SL for servicemix-camel component :(
>>
>>
>> Willem Jiang wrote:
>>
>>> Hi Guillaume,
>>>
>>> The way that I tried to resolved the ESB-261 is putting the camel-cxf
>>> related jars into SL for the servicemix-camel component to use. It does not
>>> include any camel-core jar.
>>> I just checked the camel component resolver code, it will use the
>>> ObjectHelper to load the component property file.
>>>
>>> public static InputStream loadResourceAsStream(String name) {
>>> InputStream in = null;
>>>
>>> ClassLoader contextClassLoader =
>>> Thread.currentThread().getContextClassLoader();
>>> if (contextClassLoader != null) {
>>> in = contextClassLoader.getResourceAsStream(name);
>>> }
>>> if (in == null) {
>>> in =
>>> ObjectHelper.class.getClassLoader().getResourceAsStream(name);
>>> }
>>>
>>> return in;
>>> }
>>>
>>> I guess when the SU start , if the thread context class loader is not set
>>> or the thread context class loader is the servicemix camel component's class
>>> loader , the camel-cxf's component (which in the cxf SL) will not be found.
>>>
>>> BTW, When I put the cxf SL into the servicemix camel component, camel-core
>>> can find the camel-cxf related jars.
>>>
>>> Willem
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> When starting to write the response, I think i found an issue. The SU
>>>> classloader should be used by camel to create the context and discover
>>>> components. This classloader SU will have several parents: one being
>>>> the servicemix-camel component classloader, and several ones for the
>>>> referenced shared libraries. However, I think one problem is that
>>>> camel-core is defined in the servicemix-camel component, but camel
>>>> components packaged in SL will need this jar too. The problem is that
>>>> SLs can not reference components classloaders, this is the other way
>>>> around. Furthermore, a shared library can not even reference another
>>>> shared library.
>>>> So I don't even see how it would work referencing a SL from the
>>>> component, as camel-core will not be available to the SL classloader,
>>>> hence the camel components in the SL should not be able to be
>>>> instanciated. For your cxf SL, is camel-core included in the SL ? If
>>>> yes, this is a bad idea, as each SL would have its own camel-core copy
>>>> and they would not work together.
>>>>
>>>> On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang <wi...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> There are two issues in the ESB-261, the first is the camel-shared
>>>>> library
>>>>> which contains camel-cxf component can not work in the Camel-SU( Please
>>>>> see
>>>>> the issue description); the other is activemq camel component related
>>>>> issue(
>>>>> I think it is resolved by taking activemq camel component out of
>>>>> activemq-core).
>>>>>
>>>>> BTW, the 01-camel-shared library just contains camel-cxf component
>>>>> relates
>>>>> jars.
>>>>> My question is how does the service-camel component interact with the
>>>>> camel
>>>>> SU, specially from the class loader perspective ?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Willem
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>
>>>>>> I think some of the problems comes from the fact that ActiveMQ
>>>>>> includes the activemq camel component, but ActiveMQ is in the
>>>>>> container classpath, whereas Camel is not. So the activemq camel
>>>>>> component can not really work, unless you put camel-core in the
>>>>>> container classpath, or put a copy of activemq in the SU / SL and
>>>>>> specifiy that you want the self first delegation instead of the
>>>>>> default parent first. Have you tried for a component other than the
>>>>>> activemq one ?
>>>>>>
>>>>>> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Guillaume,
>>>>>>>
>>>>>>> Cool , I will head to write a camel-example to show how to create this
>>>>>>> kind
>>>>>>> of SU which is using this camel extension SL :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Willem
>>>>>>>
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I'm actually working on the OSGi bits and should commit something
>>>>>>>> very
>>>>>>>> soon, so we would not need such a shared library in smx4.
>>>>>>>> For smx3, is the point #2 really needed ? I would have thought
>>>>>>>> referencing the SL from the SU would work without problems and
>>>>>>>> without
>>>>>>>> the need to hack the component's jbi.xml.
>>>>>>>>
>>>>>>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>>>>>>> <ja...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> The camel component just contains the core camel jars, but some use
>>>>>>>>>> cases
>>>>>>>>>> require the use of addon components (for example camel-cxf) which
>>>>>>>>>> are
>>>>>>>>>> not
>>>>>>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>>>>>>> dependency
>>>>>>>>>> on an addon component then you will hit classloading conflicts
>>>>>>>>>> (ClassCastException typically ). You currently need to:
>>>>>>>>>>
>>>>>>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>>>>>>
>>>>>>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your
>>>>>>>>>> shared
>>>>>>>>>> library.
>>>>>>>>>>
>>>>>>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>>>>>>> enhancement
>>>>>>>>>> is to add a placeholder shared library to the camel-core component.
>>>>>>>>>> The
>>>>>>>>>> shared library can be empty but will need to exist in the hot
>>>>>>>>>> deploy
>>>>>>>>>> directory.
>>>>>>>>>>
>>>>>>>>>> This would eliminate the need to hack the camel component's
>>>>>>>>>> jbi.xml,
>>>>>>>>>> you
>>>>>>>>>> would just need to edite the camel shared library pom.xml and
>>>>>>>>>> override
>>>>>>>>>> the
>>>>>>>>>> old camel shared library in the deploy directory.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>>>>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4
>>>>>>>>> and
>>>>>>>>> then its no longer an issue
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> James
>>>>>>>>> -------
>>>>>>>>> http://macstrac.blogspot.com/
>>>>>>>>>
>>>>>>>>> Open Source Integration
>>>>>>>>> http://open.iona.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>
>
Re: Create an extension shared library for servicemix-camel service engine
Posted by Guillaume Nodet <gn...@gmail.com>.
But I still have doubts that it would work. A SL can not have any
reference to another SL, this means that it would have to include the
camel-core jar, which would lead to multiple copies of this jar to be
included and would lead to the same problem.
On Wed, Jul 30, 2008 at 8:33 AM, Willem Jiang <wi...@gmail.com> wrote:
> I just found when starting the cxf SU, the thread context class loader
> will be set with the SU's component class loader.
> This will explain why camel-cxf component will not be resolved by the
> camel-core when we put the camel-cxf into the SL for the cxf SU.
>
> I think I had to add the extension SL for servicemix-camel component :(
>
>
> Willem Jiang wrote:
>>
>> Hi Guillaume,
>>
>> The way that I tried to resolved the ESB-261 is putting the camel-cxf
>> related jars into SL for the servicemix-camel component to use. It does not
>> include any camel-core jar.
>> I just checked the camel component resolver code, it will use the
>> ObjectHelper to load the component property file.
>>
>> public static InputStream loadResourceAsStream(String name) {
>> InputStream in = null;
>>
>> ClassLoader contextClassLoader =
>> Thread.currentThread().getContextClassLoader();
>> if (contextClassLoader != null) {
>> in = contextClassLoader.getResourceAsStream(name);
>> }
>> if (in == null) {
>> in =
>> ObjectHelper.class.getClassLoader().getResourceAsStream(name);
>> }
>>
>> return in;
>> }
>>
>> I guess when the SU start , if the thread context class loader is not set
>> or the thread context class loader is the servicemix camel component's class
>> loader , the camel-cxf's component (which in the cxf SL) will not be found.
>>
>> BTW, When I put the cxf SL into the servicemix camel component, camel-core
>> can find the camel-cxf related jars.
>>
>> Willem
>>
>>
>> Guillaume Nodet wrote:
>>>
>>> When starting to write the response, I think i found an issue. The SU
>>> classloader should be used by camel to create the context and discover
>>> components. This classloader SU will have several parents: one being
>>> the servicemix-camel component classloader, and several ones for the
>>> referenced shared libraries. However, I think one problem is that
>>> camel-core is defined in the servicemix-camel component, but camel
>>> components packaged in SL will need this jar too. The problem is that
>>> SLs can not reference components classloaders, this is the other way
>>> around. Furthermore, a shared library can not even reference another
>>> shared library.
>>> So I don't even see how it would work referencing a SL from the
>>> component, as camel-core will not be available to the SL classloader,
>>> hence the camel components in the SL should not be able to be
>>> instanciated. For your cxf SL, is camel-core included in the SL ? If
>>> yes, this is a bad idea, as each SL would have its own camel-core copy
>>> and they would not work together.
>>>
>>> On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang <wi...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Hi Guillaume,
>>>>
>>>> There are two issues in the ESB-261, the first is the camel-shared
>>>> library
>>>> which contains camel-cxf component can not work in the Camel-SU( Please
>>>> see
>>>> the issue description); the other is activemq camel component related
>>>> issue(
>>>> I think it is resolved by taking activemq camel component out of
>>>> activemq-core).
>>>>
>>>> BTW, the 01-camel-shared library just contains camel-cxf component
>>>> relates
>>>> jars.
>>>> My question is how does the service-camel component interact with the
>>>> camel
>>>> SU, specially from the class loader perspective ?
>>>>
>>>> Thanks,
>>>>
>>>> Willem
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>>
>>>>> I think some of the problems comes from the fact that ActiveMQ
>>>>> includes the activemq camel component, but ActiveMQ is in the
>>>>> container classpath, whereas Camel is not. So the activemq camel
>>>>> component can not really work, unless you put camel-core in the
>>>>> container classpath, or put a copy of activemq in the SU / SL and
>>>>> specifiy that you want the self first delegation instead of the
>>>>> default parent first. Have you tried for a component other than the
>>>>> activemq one ?
>>>>>
>>>>> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> Cool , I will head to write a camel-example to show how to create this
>>>>>> kind
>>>>>> of SU which is using this camel extension SL :)
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Willem
>>>>>>
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I'm actually working on the OSGi bits and should commit something
>>>>>>> very
>>>>>>> soon, so we would not need such a shared library in smx4.
>>>>>>> For smx3, is the point #2 really needed ? I would have thought
>>>>>>> referencing the SL from the SU would work without problems and
>>>>>>> without
>>>>>>> the need to hack the component's jbi.xml.
>>>>>>>
>>>>>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>>>>>> <ja...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The camel component just contains the core camel jars, but some use
>>>>>>>>> cases
>>>>>>>>> require the use of addon components (for example camel-cxf) which
>>>>>>>>> are
>>>>>>>>> not
>>>>>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>>>>>> dependency
>>>>>>>>> on an addon component then you will hit classloading conflicts
>>>>>>>>> (ClassCastException typically ). You currently need to:
>>>>>>>>>
>>>>>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>>>>>
>>>>>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your
>>>>>>>>> shared
>>>>>>>>> library.
>>>>>>>>>
>>>>>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>>>>>> enhancement
>>>>>>>>> is to add a placeholder shared library to the camel-core component.
>>>>>>>>> The
>>>>>>>>> shared library can be empty but will need to exist in the hot
>>>>>>>>> deploy
>>>>>>>>> directory.
>>>>>>>>>
>>>>>>>>> This would eliminate the need to hack the camel component's
>>>>>>>>> jbi.xml,
>>>>>>>>> you
>>>>>>>>> would just need to edite the camel shared library pom.xml and
>>>>>>>>> override
>>>>>>>>> the
>>>>>>>>> old camel shared library in the deploy directory.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>>>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4
>>>>>>>> and
>>>>>>>> then its no longer an issue
>>>>>>>>
>>>>>>>> --
>>>>>>>> James
>>>>>>>> -------
>>>>>>>> http://macstrac.blogspot.com/
>>>>>>>>
>>>>>>>> Open Source Integration
>>>>>>>> http://open.iona.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
I just found when starting the cxf SU, the thread context class loader
will be set with the SU's component class loader.
This will explain why camel-cxf component will not be resolved by the
camel-core when we put the camel-cxf into the SL for the cxf SU.
I think I had to add the extension SL for servicemix-camel component :(
Willem Jiang wrote:
> Hi Guillaume,
>
> The way that I tried to resolved the ESB-261 is putting the camel-cxf
> related jars into SL for the servicemix-camel component to use. It
> does not include any camel-core jar.
> I just checked the camel component resolver code, it will use the
> ObjectHelper to load the component property file.
>
> public static InputStream loadResourceAsStream(String name) {
> InputStream in = null;
>
> ClassLoader contextClassLoader =
> Thread.currentThread().getContextClassLoader();
> if (contextClassLoader != null) {
> in = contextClassLoader.getResourceAsStream(name);
> }
> if (in == null) {
> in =
> ObjectHelper.class.getClassLoader().getResourceAsStream(name);
> }
>
> return in;
> }
>
> I guess when the SU start , if the thread context class loader is not
> set or the thread context class loader is the servicemix camel
> component's class loader , the camel-cxf's component (which in the cxf
> SL) will not be found.
>
> BTW, When I put the cxf SL into the servicemix camel component,
> camel-core can find the camel-cxf related jars.
>
> Willem
>
>
> Guillaume Nodet wrote:
>> When starting to write the response, I think i found an issue. The SU
>> classloader should be used by camel to create the context and discover
>> components. This classloader SU will have several parents: one being
>> the servicemix-camel component classloader, and several ones for the
>> referenced shared libraries. However, I think one problem is that
>> camel-core is defined in the servicemix-camel component, but camel
>> components packaged in SL will need this jar too. The problem is that
>> SLs can not reference components classloaders, this is the other way
>> around. Furthermore, a shared library can not even reference another
>> shared library.
>> So I don't even see how it would work referencing a SL from the
>> component, as camel-core will not be available to the SL classloader,
>> hence the camel components in the SL should not be able to be
>> instanciated. For your cxf SL, is camel-core included in the SL ? If
>> yes, this is a bad idea, as each SL would have its own camel-core copy
>> and they would not work together.
>>
>> On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang
>> <wi...@gmail.com> wrote:
>>
>>> Hi Guillaume,
>>>
>>> There are two issues in the ESB-261, the first is the camel-shared
>>> library
>>> which contains camel-cxf component can not work in the Camel-SU(
>>> Please see
>>> the issue description); the other is activemq camel component
>>> related issue(
>>> I think it is resolved by taking activemq camel component out of
>>> activemq-core).
>>>
>>> BTW, the 01-camel-shared library just contains camel-cxf component
>>> relates
>>> jars.
>>> My question is how does the service-camel component interact with
>>> the camel
>>> SU, specially from the class loader perspective ?
>>>
>>> Thanks,
>>>
>>> Willem
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> I think some of the problems comes from the fact that ActiveMQ
>>>> includes the activemq camel component, but ActiveMQ is in the
>>>> container classpath, whereas Camel is not. So the activemq camel
>>>> component can not really work, unless you put camel-core in the
>>>> container classpath, or put a copy of activemq in the SU / SL and
>>>> specifiy that you want the self first delegation instead of the
>>>> default parent first. Have you tried for a component other than the
>>>> activemq one ?
>>>>
>>>> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> Cool , I will head to write a camel-example to show how to create
>>>>> this
>>>>> kind
>>>>> of SU which is using this camel extension SL :)
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Willem
>>>>>
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>
>>>>>
>>>>>> I'm actually working on the OSGi bits and should commit something
>>>>>> very
>>>>>> soon, so we would not need such a shared library in smx4.
>>>>>> For smx3, is the point #2 really needed ? I would have thought
>>>>>> referencing the SL from the SU would work without problems and
>>>>>> without
>>>>>> the need to hack the component's jbi.xml.
>>>>>>
>>>>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>>>>> <ja...@gmail.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> The camel component just contains the core camel jars, but some
>>>>>>>> use
>>>>>>>> cases
>>>>>>>> require the use of addon components (for example camel-cxf)
>>>>>>>> which are
>>>>>>>> not
>>>>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>>>>> dependency
>>>>>>>> on an addon component then you will hit classloading conflicts
>>>>>>>> (ClassCastException typically ). You currently need to:
>>>>>>>>
>>>>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>>>>
>>>>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your
>>>>>>>> shared
>>>>>>>> library.
>>>>>>>>
>>>>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>>>>> enhancement
>>>>>>>> is to add a placeholder shared library to the camel-core
>>>>>>>> component.
>>>>>>>> The
>>>>>>>> shared library can be empty but will need to exist in the hot
>>>>>>>> deploy
>>>>>>>> directory.
>>>>>>>>
>>>>>>>> This would eliminate the need to hack the camel component's
>>>>>>>> jbi.xml,
>>>>>>>> you
>>>>>>>> would just need to edite the camel shared library pom.xml and
>>>>>>>> override
>>>>>>>> the
>>>>>>>> old camel shared library in the deploy directory.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Yeah, sounds good to me. The other option would just be to use
>>>>>>> OSGi
>>>>>>> class loading rather than JBI 1.0 class loadering in ServiceMix
>>>>>>> 4 and
>>>>>>> then its no longer an issue
>>>>>>>
>>>>>>> --
>>>>>>> James
>>>>>>> -------
>>>>>>> http://macstrac.blogspot.com/
>>>>>>>
>>>>>>> Open Source Integration
>>>>>>> http://open.iona.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>
>
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume,
The way that I tried to resolved the ESB-261 is putting the camel-cxf
related jars into SL for the servicemix-camel component to use. It does
not include any camel-core jar.
I just checked the camel component resolver code, it will use the
ObjectHelper to load the component property file.
public static InputStream loadResourceAsStream(String name) {
InputStream in = null;
ClassLoader contextClassLoader =
Thread.currentThread().getContextClassLoader();
if (contextClassLoader != null) {
in = contextClassLoader.getResourceAsStream(name);
}
if (in == null) {
in =
ObjectHelper.class.getClassLoader().getResourceAsStream(name);
}
return in;
}
I guess when the SU start , if the thread context class loader is not
set or the thread context class loader is the servicemix camel
component's class loader , the camel-cxf's component (which in the cxf
SL) will not be found.
BTW, When I put the cxf SL into the servicemix camel component,
camel-core can find the camel-cxf related jars.
Willem
Guillaume Nodet wrote:
> When starting to write the response, I think i found an issue. The SU
> classloader should be used by camel to create the context and discover
> components. This classloader SU will have several parents: one being
> the servicemix-camel component classloader, and several ones for the
> referenced shared libraries. However, I think one problem is that
> camel-core is defined in the servicemix-camel component, but camel
> components packaged in SL will need this jar too. The problem is that
> SLs can not reference components classloaders, this is the other way
> around. Furthermore, a shared library can not even reference another
> shared library.
> So I don't even see how it would work referencing a SL from the
> component, as camel-core will not be available to the SL classloader,
> hence the camel components in the SL should not be able to be
> instanciated. For your cxf SL, is camel-core included in the SL ? If
> yes, this is a bad idea, as each SL would have its own camel-core copy
> and they would not work together.
>
> On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi Guillaume,
>>
>> There are two issues in the ESB-261, the first is the camel-shared library
>> which contains camel-cxf component can not work in the Camel-SU( Please see
>> the issue description); the other is activemq camel component related issue(
>> I think it is resolved by taking activemq camel component out of
>> activemq-core).
>>
>> BTW, the 01-camel-shared library just contains camel-cxf component relates
>> jars.
>> My question is how does the service-camel component interact with the camel
>> SU, specially from the class loader perspective ?
>>
>> Thanks,
>>
>> Willem
>>
>> Guillaume Nodet wrote:
>>
>>> I think some of the problems comes from the fact that ActiveMQ
>>> includes the activemq camel component, but ActiveMQ is in the
>>> container classpath, whereas Camel is not. So the activemq camel
>>> component can not really work, unless you put camel-core in the
>>> container classpath, or put a copy of activemq in the SU / SL and
>>> specifiy that you want the self first delegation instead of the
>>> default parent first. Have you tried for a component other than the
>>> activemq one ?
>>>
>>> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com>
>>> wrote:
>>>
>>>
>>>> Hi Guillaume,
>>>>
>>>> Cool , I will head to write a camel-example to show how to create this
>>>> kind
>>>> of SU which is using this camel extension SL :)
>>>>
>>>> Cheers,
>>>>
>>>> Willem
>>>>
>>>>
>>>> Guillaume Nodet wrote:
>>>>
>>>>
>>>>> I'm actually working on the OSGi bits and should commit something very
>>>>> soon, so we would not need such a shared library in smx4.
>>>>> For smx3, is the point #2 really needed ? I would have thought
>>>>> referencing the SL from the SU would work without problems and without
>>>>> the need to hack the component's jbi.xml.
>>>>>
>>>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>>>> <ja...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The camel component just contains the core camel jars, but some use
>>>>>>> cases
>>>>>>> require the use of addon components (for example camel-cxf) which are
>>>>>>> not
>>>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>>>> dependency
>>>>>>> on an addon component then you will hit classloading conflicts
>>>>>>> (ClassCastException typically ). You currently need to:
>>>>>>>
>>>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>>>
>>>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your
>>>>>>> shared
>>>>>>> library.
>>>>>>>
>>>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>>>> enhancement
>>>>>>> is to add a placeholder shared library to the camel-core component.
>>>>>>> The
>>>>>>> shared library can be empty but will need to exist in the hot deploy
>>>>>>> directory.
>>>>>>>
>>>>>>> This would eliminate the need to hack the camel component's jbi.xml,
>>>>>>> you
>>>>>>> would just need to edite the camel shared library pom.xml and override
>>>>>>> the
>>>>>>> old camel shared library in the deploy directory.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>>>>>> then its no longer an issue
>>>>>>
>>>>>> --
>>>>>> James
>>>>>> -------
>>>>>> http://macstrac.blogspot.com/
>>>>>>
>>>>>> Open Source Integration
>>>>>> http://open.iona.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: Create an extension shared library for servicemix-camel service engine
Posted by Guillaume Nodet <gn...@gmail.com>.
When starting to write the response, I think i found an issue. The SU
classloader should be used by camel to create the context and discover
components. This classloader SU will have several parents: one being
the servicemix-camel component classloader, and several ones for the
referenced shared libraries. However, I think one problem is that
camel-core is defined in the servicemix-camel component, but camel
components packaged in SL will need this jar too. The problem is that
SLs can not reference components classloaders, this is the other way
around. Furthermore, a shared library can not even reference another
shared library.
So I don't even see how it would work referencing a SL from the
component, as camel-core will not be available to the SL classloader,
hence the camel components in the SL should not be able to be
instanciated. For your cxf SL, is camel-core included in the SL ? If
yes, this is a bad idea, as each SL would have its own camel-core copy
and they would not work together.
On Tue, Jul 29, 2008 at 11:45 AM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Guillaume,
>
> There are two issues in the ESB-261, the first is the camel-shared library
> which contains camel-cxf component can not work in the Camel-SU( Please see
> the issue description); the other is activemq camel component related issue(
> I think it is resolved by taking activemq camel component out of
> activemq-core).
>
> BTW, the 01-camel-shared library just contains camel-cxf component relates
> jars.
> My question is how does the service-camel component interact with the camel
> SU, specially from the class loader perspective ?
>
> Thanks,
>
> Willem
>
> Guillaume Nodet wrote:
>>
>> I think some of the problems comes from the fact that ActiveMQ
>> includes the activemq camel component, but ActiveMQ is in the
>> container classpath, whereas Camel is not. So the activemq camel
>> component can not really work, unless you put camel-core in the
>> container classpath, or put a copy of activemq in the SU / SL and
>> specifiy that you want the self first delegation instead of the
>> default parent first. Have you tried for a component other than the
>> activemq one ?
>>
>> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com>
>> wrote:
>>
>>>
>>> Hi Guillaume,
>>>
>>> Cool , I will head to write a camel-example to show how to create this
>>> kind
>>> of SU which is using this camel extension SL :)
>>>
>>> Cheers,
>>>
>>> Willem
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>>
>>>> I'm actually working on the OSGi bits and should commit something very
>>>> soon, so we would not need such a shared library in smx4.
>>>> For smx3, is the point #2 really needed ? I would have thought
>>>> referencing the SL from the SU would work without problems and without
>>>> the need to hack the component's jbi.xml.
>>>>
>>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>>> <ja...@gmail.com> wrote:
>>>>
>>>>
>>>>>
>>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>>
>>>>>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The camel component just contains the core camel jars, but some use
>>>>>> cases
>>>>>> require the use of addon components (for example camel-cxf) which are
>>>>>> not
>>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>>> dependency
>>>>>> on an addon component then you will hit classloading conflicts
>>>>>> (ClassCastException typically ). You currently need to:
>>>>>>
>>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>>
>>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your
>>>>>> shared
>>>>>> library.
>>>>>>
>>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>>> enhancement
>>>>>> is to add a placeholder shared library to the camel-core component.
>>>>>> The
>>>>>> shared library can be empty but will need to exist in the hot deploy
>>>>>> directory.
>>>>>>
>>>>>> This would eliminate the need to hack the camel component's jbi.xml,
>>>>>> you
>>>>>> would just need to edite the camel shared library pom.xml and override
>>>>>> the
>>>>>> old camel shared library in the deploy directory.
>>>>>>
>>>>>>
>>>>>
>>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>>>>> then its no longer an issue
>>>>>
>>>>> --
>>>>> James
>>>>> -------
>>>>> http://macstrac.blogspot.com/
>>>>>
>>>>> Open Source Integration
>>>>> http://open.iona.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume,
There are two issues in the ESB-261, the first is the camel-shared
library which contains camel-cxf component can not work in the Camel-SU(
Please see the issue description); the other is activemq camel component
related issue( I think it is resolved by taking activemq camel component
out of activemq-core).
BTW, the 01-camel-shared library just contains camel-cxf component
relates jars.
My question is how does the service-camel component interact with the
camel SU, specially from the class loader perspective ?
Thanks,
Willem
Guillaume Nodet wrote:
> I think some of the problems comes from the fact that ActiveMQ
> includes the activemq camel component, but ActiveMQ is in the
> container classpath, whereas Camel is not. So the activemq camel
> component can not really work, unless you put camel-core in the
> container classpath, or put a copy of activemq in the SU / SL and
> specifiy that you want the self first delegation instead of the
> default parent first. Have you tried for a component other than the
> activemq one ?
>
> On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com> wrote:
>
>> Hi Guillaume,
>>
>> Cool , I will head to write a camel-example to show how to create this kind
>> of SU which is using this camel extension SL :)
>>
>> Cheers,
>>
>> Willem
>>
>>
>> Guillaume Nodet wrote:
>>
>>> I'm actually working on the OSGi bits and should commit something very
>>> soon, so we would not need such a shared library in smx4.
>>> For smx3, is the point #2 really needed ? I would have thought
>>> referencing the SL from the SU would work without problems and without
>>> the need to hack the component's jbi.xml.
>>>
>>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>>> <ja...@gmail.com> wrote:
>>>
>>>
>>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> The camel component just contains the core camel jars, but some use
>>>>> cases
>>>>> require the use of addon components (for example camel-cxf) which are
>>>>> not
>>>>> present in the core camel jars. If you have multiple SU's with a
>>>>> dependency
>>>>> on an addon component then you will hit classloading conflicts
>>>>> (ClassCastException typically ). You currently need to:
>>>>>
>>>>> 1) Add the camel extension components to a jbi shared library
>>>>>
>>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>>>>> library.
>>>>>
>>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>>> enhancement
>>>>> is to add a placeholder shared library to the camel-core component. The
>>>>> shared library can be empty but will need to exist in the hot deploy
>>>>> directory.
>>>>>
>>>>> This would eliminate the need to hack the camel component's jbi.xml, you
>>>>> would just need to edite the camel shared library pom.xml and override
>>>>> the
>>>>> old camel shared library in the deploy directory.
>>>>>
>>>>>
>>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>>>> then its no longer an issue
>>>>
>>>> --
>>>> James
>>>> -------
>>>> http://macstrac.blogspot.com/
>>>>
>>>> Open Source Integration
>>>> http://open.iona.com
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>
Re: Create an extension shared library for servicemix-camel service engine
Posted by Guillaume Nodet <gn...@gmail.com>.
I think some of the problems comes from the fact that ActiveMQ
includes the activemq camel component, but ActiveMQ is in the
container classpath, whereas Camel is not. So the activemq camel
component can not really work, unless you put camel-core in the
container classpath, or put a copy of activemq in the SU / SL and
specifiy that you want the self first delegation instead of the
default parent first. Have you tried for a component other than the
activemq one ?
On Mon, Jul 28, 2008 at 3:20 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Guillaume,
>
> Cool , I will head to write a camel-example to show how to create this kind
> of SU which is using this camel extension SL :)
>
> Cheers,
>
> Willem
>
>
> Guillaume Nodet wrote:
>>
>> I'm actually working on the OSGi bits and should commit something very
>> soon, so we would not need such a shared library in smx4.
>> For smx3, is the point #2 really needed ? I would have thought
>> referencing the SL from the SU would work without problems and without
>> the need to hack the component's jbi.xml.
>>
>> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
>> <ja...@gmail.com> wrote:
>>
>>>
>>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>>
>>>>
>>>> Hi,
>>>>
>>>> The camel component just contains the core camel jars, but some use
>>>> cases
>>>> require the use of addon components (for example camel-cxf) which are
>>>> not
>>>> present in the core camel jars. If you have multiple SU's with a
>>>> dependency
>>>> on an addon component then you will hit classloading conflicts
>>>> (ClassCastException typically ). You currently need to:
>>>>
>>>> 1) Add the camel extension components to a jbi shared library
>>>>
>>>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>>>> library.
>>>>
>>>> Having to edit the servicemix-camel jbi.xml is not ideal so this
>>>> enhancement
>>>> is to add a placeholder shared library to the camel-core component. The
>>>> shared library can be empty but will need to exist in the hot deploy
>>>> directory.
>>>>
>>>> This would eliminate the need to hack the camel component's jbi.xml, you
>>>> would just need to edite the camel shared library pom.xml and override
>>>> the
>>>> old camel shared library in the deploy directory.
>>>>
>>>
>>> Yeah, sounds good to me. The other option would just be to use OSGi
>>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>>> then its no longer an issue
>>>
>>> --
>>> James
>>> -------
>>> http://macstrac.blogspot.com/
>>>
>>> Open Source Integration
>>> http://open.iona.com
>>>
>>>
>>
>>
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Create an extension shared library for servicemix-camel service
engine
Posted by Willem Jiang <wi...@gmail.com>.
Hi Guillaume,
Cool , I will head to write a camel-example to show how to create this
kind of SU which is using this camel extension SL :)
Cheers,
Willem
Guillaume Nodet wrote:
> I'm actually working on the OSGi bits and should commit something very
> soon, so we would not need such a shared library in smx4.
> For smx3, is the point #2 really needed ? I would have thought
> referencing the SL from the SU would work without problems and without
> the need to hack the component's jbi.xml.
>
> On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
> <ja...@gmail.com> wrote:
>
>> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>>
>>> Hi,
>>>
>>> The camel component just contains the core camel jars, but some use cases
>>> require the use of addon components (for example camel-cxf) which are not
>>> present in the core camel jars. If you have multiple SU's with a dependency
>>> on an addon component then you will hit classloading conflicts
>>> (ClassCastException typically ). You currently need to:
>>>
>>> 1) Add the camel extension components to a jbi shared library
>>>
>>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>>> library.
>>>
>>> Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
>>> is to add a placeholder shared library to the camel-core component. The
>>> shared library can be empty but will need to exist in the hot deploy
>>> directory.
>>>
>>> This would eliminate the need to hack the camel component's jbi.xml, you
>>> would just need to edite the camel shared library pom.xml and override the
>>> old camel shared library in the deploy directory.
>>>
>> Yeah, sounds good to me. The other option would just be to use OSGi
>> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
>> then its no longer an issue
>>
>> --
>> James
>> -------
>> http://macstrac.blogspot.com/
>>
>> Open Source Integration
>> http://open.iona.com
>>
>>
>
>
>
>
Re: Create an extension shared library for servicemix-camel service engine
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm actually working on the OSGi bits and should commit something very
soon, so we would not need such a shared library in smx4.
For smx3, is the point #2 really needed ? I would have thought
referencing the SL from the SU would work without problems and without
the need to hack the component's jbi.xml.
On Mon, Jul 28, 2008 at 10:51 AM, James Strachan
<ja...@gmail.com> wrote:
> 2008/7/28 Willem Jiang <wi...@gmail.com>:
>> Hi,
>>
>> The camel component just contains the core camel jars, but some use cases
>> require the use of addon components (for example camel-cxf) which are not
>> present in the core camel jars. If you have multiple SU's with a dependency
>> on an addon component then you will hit classloading conflicts
>> (ClassCastException typically ). You currently need to:
>>
>> 1) Add the camel extension components to a jbi shared library
>>
>> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
>> library.
>>
>> Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
>> is to add a placeholder shared library to the camel-core component. The
>> shared library can be empty but will need to exist in the hot deploy
>> directory.
>>
>> This would eliminate the need to hack the camel component's jbi.xml, you
>> would just need to edite the camel shared library pom.xml and override the
>> old camel shared library in the deploy directory.
>
> Yeah, sounds good to me. The other option would just be to use OSGi
> class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
> then its no longer an issue
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Create an extension shared library for servicemix-camel service engine
Posted by James Strachan <ja...@gmail.com>.
2008/7/28 Willem Jiang <wi...@gmail.com>:
> Hi,
>
> The camel component just contains the core camel jars, but some use cases
> require the use of addon components (for example camel-cxf) which are not
> present in the core camel jars. If you have multiple SU's with a dependency
> on an addon component then you will hit classloading conflicts
> (ClassCastException typically ). You currently need to:
>
> 1) Add the camel extension components to a jbi shared library
>
> 2) Edit the servicemix-camel service engine jbi.xml and add your shared
> library.
>
> Having to edit the servicemix-camel jbi.xml is not ideal so this enhancement
> is to add a placeholder shared library to the camel-core component. The
> shared library can be empty but will need to exist in the hot deploy
> directory.
>
> This would eliminate the need to hack the camel component's jbi.xml, you
> would just need to edite the camel shared library pom.xml and override the
> old camel shared library in the deploy directory.
Yeah, sounds good to me. The other option would just be to use OSGi
class loading rather than JBI 1.0 class loadering in ServiceMix 4 and
then its no longer an issue
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com