On Tue, Mar 3, 2009 at 2:26 PM, Willem Jiang <willem.ji...@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 <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? >>>> >>>> >>> >> >> >> > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
