You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Claus Ibsen <cl...@gmail.com> on 2009/03/03 11:48:51 UTC
Camel 2.0 - OSGi - loading classes
Hi
In Camel we use ObjectHelper.loadClass to load classes on the fly.
Could there be some issues with this in OSGi platforms? We got a
report today with using camel-jms that tries to load a spring queue
browser class on the fly. So we can support Spring 2.0 also as this
class was introduced in Spring 2.5.x.
I was wondering if we should add API for pluggable class resolvers?
Eg. ClassResolver API in SPI and then a getter to it from
CamelContext.
Or is the ObjectHelper sufficient?
Do you need to get hold of some bundle context to load classes in OSGi
or is the regular class loading okay?
Gertv, Willem you are the ones that are most into OSGi. You thoughts?
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 3, 2009 at 2:26 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi Claus
>
> If the ThreadContextClassLoader is the user's bundle's classloader, and
> the user bundle doesn't import the org.apache.camel.jms package.
> The ObjectHelper can't load the right DefaultQueueBrowseStrategy class
> by using the bundle's classlaoder.
Ah got it. So by changing to the JMS class we know its gonna find it
in camel-jms as its the same bundle as it self :)
>
> Willem
>
> Claus Ibsen wrote:
>> On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang <wi...@gmail.com> wrote:
>>> Hi,
>>>
>>> I think we should leverage the ThreadContextClassLoader to load the
>>> right class.
>>> Since OSGI has elegant mechanism to get control of the class's version
>>> and handle the relationship of the classes. I don't want to walk around
>>> this mechanism by looking over all the bundler's context for a class.
>> But this was the problem with the JMS stuff. ObjectHelper.loadClass
>> will use the ThredContextClassLoader first.
>> So I can not see if that would work.
>>
>>> Just my 2 cents.
>>
>>> Willem.
>>>
>>> Claus Ibsen wrote:
>>>> Hi
>>>>
>>>> In Camel we use ObjectHelper.loadClass to load classes on the fly.
>>>>
>>>> Could there be some issues with this in OSGi platforms? We got a
>>>> report today with using camel-jms that tries to load a spring queue
>>>> browser class on the fly. So we can support Spring 2.0 also as this
>>>> class was introduced in Spring 2.5.x.
>>>>
>>>> I was wondering if we should add API for pluggable class resolvers?
>>>> Eg. ClassResolver API in SPI and then a getter to it from
>>>> CamelContext.
>>>> Or is the ObjectHelper sufficient?
>>>>
>>>> Do you need to get hold of some bundle context to load classes in OSGi
>>>> or is the regular class loading okay?
>>>>
>>>> Gertv, Willem you are the ones that are most into OSGi. You thoughts?
>>>>
>>>>
>>>
>>
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
Posted by Willem Jiang <wi...@gmail.com>.
Hi Claus
If the ThreadContextClassLoader is the user's bundle's classloader, and
the user bundle doesn't import the org.apache.camel.jms package.
The ObjectHelper can't load the right DefaultQueueBrowseStrategy class
by using the bundle's classlaoder.
Willem
Claus Ibsen wrote:
> On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang <wi...@gmail.com> wrote:
>> Hi,
>>
>> I think we should leverage the ThreadContextClassLoader to load the
>> right class.
>> Since OSGI has elegant mechanism to get control of the class's version
>> and handle the relationship of the classes. I don't want to walk around
>> this mechanism by looking over all the bundler's context for a class.
> But this was the problem with the JMS stuff. ObjectHelper.loadClass
> will use the ThredContextClassLoader first.
> So I can not see if that would work.
>
>> Just my 2 cents.
>
>> Willem.
>>
>> Claus Ibsen wrote:
>>> Hi
>>>
>>> In Camel we use ObjectHelper.loadClass to load classes on the fly.
>>>
>>> Could there be some issues with this in OSGi platforms? We got a
>>> report today with using camel-jms that tries to load a spring queue
>>> browser class on the fly. So we can support Spring 2.0 also as this
>>> class was introduced in Spring 2.5.x.
>>>
>>> I was wondering if we should add API for pluggable class resolvers?
>>> Eg. ClassResolver API in SPI and then a getter to it from
>>> CamelContext.
>>> Or is the ObjectHelper sufficient?
>>>
>>> Do you need to get hold of some bundle context to load classes in OSGi
>>> or is the regular class loading okay?
>>>
>>> Gertv, Willem you are the ones that are most into OSGi. You thoughts?
>>>
>>>
>>
>
>
>
Re: Camel 2.0 - OSGi - loading classes
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang <wi...@gmail.com> wrote:
> Hi,
>
> I think we should leverage the ThreadContextClassLoader to load the
> right class.
> Since OSGI has elegant mechanism to get control of the class's version
> and handle the relationship of the classes. I don't want to walk around
> this mechanism by looking over all the bundler's context for a class.
But this was the problem with the JMS stuff. ObjectHelper.loadClass
will use the ThredContextClassLoader first.
So I can not see if that would work.
>
> Just my 2 cents.
>
> Willem.
>
> Claus Ibsen wrote:
>> Hi
>>
>> In Camel we use ObjectHelper.loadClass to load classes on the fly.
>>
>> Could there be some issues with this in OSGi platforms? We got a
>> report today with using camel-jms that tries to load a spring queue
>> browser class on the fly. So we can support Spring 2.0 also as this
>> class was introduced in Spring 2.5.x.
>>
>> I was wondering if we should add API for pluggable class resolvers?
>> Eg. ClassResolver API in SPI and then a getter to it from
>> CamelContext.
>> Or is the ObjectHelper sufficient?
>>
>> Do you need to get hold of some bundle context to load classes in OSGi
>> or is the regular class loading okay?
>>
>> Gertv, Willem you are the ones that are most into OSGi. You thoughts?
>>
>>
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Re: Camel 2.0 - OSGi - loading classes
Posted by Willem Jiang <wi...@gmail.com>.
Hi,
I think we should leverage the ThreadContextClassLoader to load the
right class.
Since OSGI has elegant mechanism to get control of the class's version
and handle the relationship of the classes. I don't want to walk around
this mechanism by looking over all the bundler's context for a class.
Just my 2 cents.
Willem.
Claus Ibsen wrote:
> Hi
>
> In Camel we use ObjectHelper.loadClass to load classes on the fly.
>
> Could there be some issues with this in OSGi platforms? We got a
> report today with using camel-jms that tries to load a spring queue
> browser class on the fly. So we can support Spring 2.0 also as this
> class was introduced in Spring 2.5.x.
>
> I was wondering if we should add API for pluggable class resolvers?
> Eg. ClassResolver API in SPI and then a getter to it from
> CamelContext.
> Or is the ObjectHelper sufficient?
>
> Do you need to get hold of some bundle context to load classes in OSGi
> or is the regular class loading okay?
>
> Gertv, Willem you are the ones that are most into OSGi. You thoughts?
>
>