OSGi and context classloader use-cases

[Christopher BROWN <br...@reflexe.fr>]

Hello,

General question about context classloaders (as in
Thread.get/setContextClassLoader), with two use cases:

* I need to create a bundle that has to instantiate a class based on a
supplied class name (such as a factory object that creates objects of a
named, where tracking existing instances won't work)

* I need to integrate a bundle (OSGi-fying an existing library for
example), such as a database connection pool, that stubbornly uses
Class.forName() in such a way that I'd need to fork it to make it more
OSGi-friendly.

If the client code (in bundle X) sets the context classloader to it's own
bundle's classloader (or in the case of the database pool example, bundle
"D" for "driver bundle"), would that be a good solution to make the library
"see" the classes?  I suspect not, because it might screw up that library's
bundle's classloading.

If I'm implementing the above factory example, is there a way I can
leverage the context classloader with an overloaded variant of
Class.forName that won't screw up normal classloading.

Obviously, my normal usage revolves around the service registry but the
"factory" and "legacy integration" cases are sometimes problematic, and I'd
like to solve that in the most "correct" way possible.

Thanks,
Christopher

Re: OSGi and context classloader use-cases

[Thomas Joseph <op...@gmail.com>]

Hi Christopher,

Perhaps you can look into
1. http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html -
which talks in details about loading classes dynamically
2.
http://stackoverflow.com/questions/7330011/how-to-set-up-connection-pooling-in-an-osgi-bundle

Also, you may want to look at OSGi JDBC specifications.

Thanks,
Thomas Joseph


On Fri, May 3, 2013 at 12:51 PM, Christopher BROWN <br...@reflexe.fr> wrote:

> Hello,
>
> General question about context classloaders (as in
> Thread.get/setContextClassLoader), with two use cases:
>
> * I need to create a bundle that has to instantiate a class based on a
> supplied class name (such as a factory object that creates objects of a
> named, where tracking existing instances won't work)
>
> * I need to integrate a bundle (OSGi-fying an existing library for
> example), such as a database connection pool, that stubbornly uses
> Class.forName() in such a way that I'd need to fork it to make it more
> OSGi-friendly.
>
> If the client code (in bundle X) sets the context classloader to it's own
> bundle's classloader (or in the case of the database pool example, bundle
> "D" for "driver bundle"), would that be a good solution to make the library
> "see" the classes?  I suspect not, because it might screw up that library's
> bundle's classloading.
>
> If I'm implementing the above factory example, is there a way I can
> leverage the context classloader with an overloaded variant of
> Class.forName that won't screw up normal classloading.
>
> Obviously, my normal usage revolves around the service registry but the
> "factory" and "legacy integration" cases are sometimes problematic, and I'd
> like to solve that in the most "correct" way possible.
>
> Thanks,
> Christopher
>