felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Wicket and Oscar
Date Wed, 17 Aug 2005 04:13:35 GMT
Johan Compagner <jcompagner@j-com.nl> 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.

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 

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 

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