Description Ray Ellis 2003-12-15 18:00:33 EST

I'm trying to communicate to a J2EE server from an Eclipse plugin using secure 
rmi/iiop.  I'm using IBM's WSAD 5.1.0 (eclipse 2.1.1) and the base_v5 runtime 
(WAS 5, IBM 1.3.1 JVM) on Windows 2000.  I believe the problem I'm having 
applies to all platforms, though I've only tested it extensively on W2K.  And 
while I was hesitant to assign this bug such a high severity, it 
definitely "blocks development and/or testing work" and, if unsolved, will 
force us to abandon using an Eclipse-based interface for this project

The problem occurs during the process of initializing an orb for secure 
communication, when the getInstances static method in 
javax.net.ssl.KeyManagerFactory class (from lib/ext/ibmjsse.jar) is called to 
get a KeyManagerFactory for the configured key types (such as IbmX509).  Since 
the Launcher$ExtClassLoader is not on the parent chain for the plugin 
classloader, if you don't include lib/ext/ibmjsse.jar in the plugin explicitly, 
no classloader will be able to find the javax.net.ssl.KeyManagerFactory class 
and the call will fail immediately.  If you do include lib/ext/ibmjsse.jar in 
the plugin, javax.net.ssl.KeyManagerFactory will be loaded by the plugin 
classloader.

The ibmjsse classes in their turn query java.security.Security for registered 
java.security.Providers.  These providers, such as com.ibm.jsse.t (from 
lib/ext/ibmjsse.jar) are loaded during startup (in this case, by 
Launcher$ExtClassLoader) and registered with java.security.Security.  Since 
java.security.Security is in rt.jar, available through the boot classloader, 
the provider references created during startup are available to the plugin 
(even though the classloader that originally loaded them is not on the 
classloader chain any more).   However, when the KeyManagerFactory attempts to 
insure that the registered providers are of the proper type (i.e., have a 
particular known superclass, in this case javax.net.ssl.KeyManagerFactorySpi or 
com.ibm.net.ssl.KeyManagerFactorySpi, from lib/ext/ibmjsse.jar), the superclass 
it compares them with is a Class loaded by the plugin classloader (the only 
loader remaining on the chain that can find the superclasses).  Since the 
registered providers and their superclasses were loaded by 
Launcher$ExtClassLoader, the superclasses never match (different classloaders), 
the providers appear to be the wrong type, and ORB initialization is never 
successful.

A simple solution is to put the systemClassLoader (or at least the 
Launcher$ExtClassLoader) on the classloader parent path, and that works 
successfully.  However, I understand the difficulties that forcing all the 
plugins to use the same set of extension classes causes.  I tried manufacturing 
my own classloader starting with the plugin classloader and having the 
Launcher$ExtClassLoader in the parent chain, but the public interfaces aren't 
rich enough to allow this.  (And besides, I think it presumes more knowledge of 
the classloading structure than a plugin writer should need to have.)