Johan Compagner <[EMAIL PROTECTED]> wrote on 08/16/2005 04:49:23 AM: > If you search the web by the way with classloading / oscar / > objectinputstream > you do find many more people with the same quiestions. > A lot of eclipse plugins for example. But eclipse has as far as i can > read some kind of override mechanism for the > objectinputstream so that you can specify classloaders..
Eclipse has a couple of different things in this space (though not designed specifically for this scenario). In particular, there are the "contextfinder" and "buddy classloading" mechanisms. See the following for more info. http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html http://help.eclipse.org/help31/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html https://bugs.eclipse.org/bugs/show_bug.cgi?id=87775#c57 In short, the context finder is a context classloader that Eclipse installs by default for all threads. Its job is to look down the current execution stack for a classloader to use and then delegate to it. Typcially this means finding the loader that loaded the class that contains the method that made the loadClass() call to Thread.getContextClassloader(). This helps libraries that do serialization etc get hooked into the OSGi classloading structure. Note that in effect, this converts context classloader usage to Class.forName(). Buddy loading is a means of bundles saying that they need help loading classes. A bundle can specify a policy to use when searching for other classloaders to use. Some of the typical policies are: app (Java application classloader), ext (Java extension classloader), registered (other bundles that have identified themselves as willing to help), ... Note that both of these are quite experimental but have been useful in real scenarios. It would be interesting to see what can be done for OSGi R5. Jeff
