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/
