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/
