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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>>> 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 <[EMAIL PROTECTED]>
>>>>> 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
>>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 2008/7/28 Willem Jiang <[EMAIL PROTECTED]>:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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/
