Plug-in classloaders and class path

[rexguo]

Hi!

For those of you who have implemented
custom class loaders for plug-in purposes,
what are your strategies for handling
the class paths required by those
classes that the class loader is loading?
If the class loader does not know how
to search class paths, it will fall
back to the system class loader which
uses the app's class path. This method
obviously defeats the purpose because
one will then need to know in advance the
plug-ins' required class paths before
launching the app.

Any suggestions appreciated!

..rex

 

[Thomas Weidenfeller]

For those of you who have implemented
custom class loaders for plug-in purposes,
what are your strategies for handling
the class paths required by those
classes that the class loader is loading?

A ClassLoader not necessarily needs a class path at all. Only if you
implement your class loader that way (to search along a certain path for
a class). You could come up with completely different strategies, e.g. a
class loader which loads its classes from a database, some binary image,
or e.g. via a proprietary protocol over a serial line. Non of these
would require a search class path.

If the class loader does not know how
to search class paths, it will fall
back to the system class loader which
uses the app's class path.

This is wrong in at least two ways. ClassLoaders delegate the other way
around. When a class is needed, the request is first delegated to the
ClassLoader's parent ClassLoader (which might further delegate it to its
parent etc.). Only when the parent fails (can't find the class), then
the actual class loader gets a shot at it.

Second, as already mentioned, a class loader is not required to work
with a search class path at all.

This method
obviously defeats the purpose because
one will then need to know in advance the
plug-ins' required class paths before
launching the app.

What plug-in? What purpose? Loading a plug-in? To load a plug-in, a
class loader has indeed to be able to find the plug-in. A well behaving
plug-in should then be self-contained. It should only rely on standard
classes and classes which are contained in the plug-in. The standard
classes are easily found by the system class loader. And since you
managed to find the plug-in and load its main class, it should also be
no problem to apply the same mechanism you used for this to find the
remaining specific classes of the plug-in.

In general, I don't see the point in implementing an own custom class
loader for loading plugins. You could require that plugins are supposed
to go into an application specific location and have that location in
the normal class path. Or you could use an URLClassLoader to load
plug-ins from all kinds of locations, including jars.

/Thomas

 

[Chris Uppal]

For those of you who have implemented
custom class loaders for plug-in purposes,
what are your strategies for handling
the class paths required by those
classes that the class loader is loading?

There must be some way that your application has been told about any
particular pluggin. Maybe it searched some well-known directory for .JAR
files.
Maybe something more complicated. Anyway, it must have been given some
starting data.

You use that data to create a classloader, and use that to load the pluggin.
That's to say that it's /your/ choice what kind of classloader to use, and
where/how it looks for the pluggin code. E.g. if you had a directory into
which pluggins in the form of JARs could be dropped, then you'd create
classloader (probably an instance of java.net.URLClassLoader) for each JAR.

If the pluggin wants to use more classloaders then that it it's affair --
nothing to do with you -- but the classloader that loads the pluggin's "main"
class(es) will be the one that your code defines and creates.

-- chris