camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
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 <> 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:

View raw message