Description Igor Fedorenko 2004-01-21 23:32:56 EST

The problem.
Quote from eclipse.platform newsgroup. Jeff McAffer wrote: <quote>Plugins are
self-contained compoents which can express dependencies on other compoents. Jars
are not components and so you cannot have a plugin depend on a jar. Nor can you
put a random Jar on the classpath of a plugin as that jar is not part of the
plugin.</quote> In other words, a plugin must carry all jar files that it needs
at runtime itself or it must depend on other plugins that carry jar files that
it needs. There are, however, situations when it is either not possible or not
practical to distribute all required jar files together with a plugin. 
For example, Oracle JDBC (type 2) driver is tightly coupled with DLL/SO
libraries installed on a computer. That means that JDBC driver from Oracle
client 8.1.7.0 does not work with JDBC driver from 8.1.7.3 client (and vise
versa). My plugin is expected to work with both these versions of Oracle client.
That means that even if I had legal rights to ship oracle JDBC driver (which I
believe I don’t) I cannot do that without breaking support for one of the two
versions of the client. Note that this problem is not specific to Oracle and
applies to any software product file that depends on native libraries.
Another example is WebSphere Application Server (WAS for short). WAS requires
some 200 jar files to be on classpath in order for a client to be able invoke an
EJB deployed into WAS. Although I can package entire WAS client with my plugin,
I don’t find this practical.
To summarize the problem, there are situations when it is necessary to make
external jar files available on plugin runtime classpath. I believe that this
will be a significant enhancement to Eclipse platform, especially useful to but
not limited by Reach Clients (as in Reach Client Platform)


A workaround.
The only workaround for this problem that I am aware of is to create new
classloader instance (URLClassLoader, for example) at runtime and load required
external jar files using that classloader. This workaround has one major
limitation, however. Because of Java classloader delegation model it is not
possible to link plugin classes directly to classes available in external jar
files. To continue my WAS example, consider the following code snippet that
executes code with WAS security context

  com.ibm.websphere.security.auth.WSSubject;
  ...  
  LoginContext lc = ...;
  lc.login();
  WSSubject.doAs(lc.getSubject(), new PrivilegedAction() {
      public Object run() {
         // we have proper security context here
         ... invoke EJB here, 
         ... it will need com.ibm.websphere classes too
      }
  });

Because a classloader delegates to its parent only, an attempt to load the
snippet above into plugin classloader will result in ClassNotFoundError as
plugin classloader does have access to com.ibm.websphere classes (see the
following ascii diagram)

     +--------------------+
     | custom classloader |  definition of com.ibm.websphere..* classes
     +--------------------+
                |
                V
     +--------------------+
     | plugin classloader |
     +--------------------+
                |
                v
     +--------------------+
     | bootstrap classldr |
     +--------------------+

It is possible to make this work by introducing an interface loaded by plugin
classloader and getting an implementation of this interface from the custom
classloader using reflection. But as you can imagine this requires significant
amount of plumbing code that is error prone, depends on very careful packaging
and is clumsy/inconvenient in other ways too.


Proposed solution.
To solve the problem described in this bug report I propose to introduce feature
similar to JDT's ClassPath Containers, only at Eclipse platform level. If this
proposal is accepted, it will be possibly for a plugin to reference a set of
classpath entries using an abstract name. At runtime this abstract reference
will be resolved to a list of specific jar/zip files and directories. Unlike JDT
which provides "JRE System Libraries" classpath container, the platform will
only provide a framework and it will be a responsibility of plugin developers to
provide mappings from abstract names to specific lists.
Over last weekend I wrote a prototype that implement the proposed solution and
it looks promising. If we can agree on design details, I can complete this
prototype and submit a patch. Btw, the prototype also allows to configure a
plugin (not all plugins!) to access classes loaded be extension classloader (see
bug 30919). If you are interested, I will be glad to can discuss this in greater
details. I am available over SameTime (igorf@ca.ibm.com), phone, etc.

Regards,
Igor Fedorenko