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 <[email protected]> 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 >
