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 <willem.ji...@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? >>> >>> >> > > >
