felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher BROWN <br...@reflexe.fr>
Subject OSGi and context classloader use-cases
Date Fri, 03 May 2013 07:21:58 GMT

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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message