camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Camel 2.0 - OSGi - loading classes
Date Tue, 03 Mar 2009 13:05:52 GMT
On Tue, Mar 3, 2009 at 2:03 PM, Willem Jiang <willem.jiang@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/

Mime
View raw message