plugin & packages

[VisionSet]

My app uses plugins. Plugins are written to implement an interface.
What is the normal way to specify the package with a plugin like this?

I could have the app jar along side a directory for the plugins

myDir/myApp.jar
myDir/plugins/PluginA.class
myDir/plugins/PluginB.class

then just use the default package for the plugins and search that directory
doing Class.forName and checking the class does implement the correct
interface.
Otherwise what package would be logical? A client programmer writes the
plugin and shouldn't add to the existing package. And I thought the JLS
said these days that packages must be used.

Another related query:
If the plugin class that implements the interface requires an object
reference that is created by the system, is it okay to have the interface
specify a setMyObjectINeedPluginToHaveAccessTo() method?
Just seems a bit wierd. Though I realise I could have an abstract class
that does that bit.

 

[Chris Uppal]

My app uses plugins. Plugins are written to implement an interface.
What is the normal way to specify the package with a plugin like this?

Why not just put a text (or XML) description of the plugin into the root
directory (or the root of the JAR file) ? That way plugin authors can use
whatever package they like, and you don't have to scratch around searching the
filesystem for .class files that /might/ correspond to plugin classes.

If the plugin class that implements the interface requires an object
reference that is created by the system, is it okay to have the interface
specify a setMyObjectINeedPluginToHaveAccessTo() method?
Just seems a bit wierd.

I agree. I'd ensure that somewhere in my system there was a /single/ object
from which any data that might be needed by any plugin could be reached, and
then always pass that to each plugin as part of its initialisation. The plugin
could then do whatever it liked with it, and I wouldn't need to worry about the
details. You may have more than one such object, say a <System> object that
holds/represents the total environment, and shorter-lived objects that
correspond to requests you make of the plugin. In such cases I'd pass the
shorter-lived objects as parameters to each request, and ensure that the
<System> object could be reached from every short-lived parameter object.

By the way, I think part of your problem with the
setMyObjectINeedPluginToHaveAccessTo() method is that you are thinking of it as
a setter method -- that you are updating an field of the plugin. That is
obviously coupling your container to the implementations of he plugins, and is
a bad idea. Just pass the data that the plugin /might/ need when you ask the
plugin to do anything (or at initialisation time), and leave it up to the
plugin to decide what to do with it.

-- chris

 

[Chris Smith]

Why not just put a text (or XML) description of the plugin into the root
directory (or the root of the JAR file) ? That way plugin authors can use
whatever package they like, and you don't have to scratch around searching the
filesystem for .class files that /might/ correspond to plugin classes.

I've tended to do this differently; specifically, I'd designate a
directory for plugins, and usually provide a property so that directory
can be changed with a -D option to the VM. That directory would contain
JAR files, and there'd be a plugin description of some type in the META-
INF directory of those JAR files. This has the advantage that the app
can still scan for plugins at runtime, rather than someone having to
maintain a global configuration files that specifies all of the plugins;
and that you can keep information about a plugin bundled with that
plugin itself, so that a plugin can be added or removed with as a single
file.

IMO (to Mike) having loose class files around is just *really* asking
for trouble. JAR files are a nice way to take a set of code and bundle
it all together. With loose class files, you'd have to worry about
identifying which classes are plugins and which are not; which classes
belong to which plugins, and so forth.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[VisionSet]

IMO (to Mike) having loose class files around is just *really* asking
for trouble. JAR files are a nice way to take a set of code and bundle
it all together. With loose class files, you'd have to worry about
identifying which classes are plugins and which are not; which classes
belong to which plugins, and so forth.

It is a very simple demo app, I've got it working with the class files, and
I'm happy with it. The directory is scanned for class files and a
Class.forName gets the class, if it is not assignable to my Inteface it is
rejected. There is only one simple class implementation required. If it
were more elaborate I'd go for jars.

Thanks each.

-
Mike W

 

[Chris Smith]

It is a very simple demo app, I've got it working with the class files, and
I'm happy with it. The directory is scanned for class files and a
Class.forName gets the class, if it is not assignable to my Inteface it is
rejected. There is only one simple class implementation required. If it
were more elaborate I'd go for jars.

Just please don't deploy this, then.

Sounds like you're making things harder than you need to (for example,
you're loading the classes with Class.forName? Does that mean that
you're placing these plugin classes in the classpath?) while
simultaneously preventing people from using good programming techniques.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[VisionSet]

Just please don't deploy this, then.

Sounds like you're making things harder than you need to (for example,
you're loading the classes with Class.forName? Does that mean that
you're placing these plugin classes in the classpath?) while
simultaneously preventing people from using good programming techniques.

how do you mean?

Yes the plugins are on the classpath under a default package.
I'm guessing you are suggesting to at least have some package structure

The purpose is really to avoid having to teach the plugin writer any more
than is strictly necessary to produce the plugin, since this is only a
simple demo app. Java knwoledge isn't an aim rather the algorithm they
write. I'd just like the writer of the plugin to just produce a classfile
and pop it in the right place for it to be detected.

Do you have an improvement without the need to jar the plugin?

 

[Chris Smith]

how do you mean?

I mean that plugins should be loaded from a separate ClassLoader than
the application. The application's ClassLoader should be its parent.
To do otherwise is to make everything dependent on the CLASSPATH
environment variable or equivalent command line options. Since the
CLASSPATH is also used to locate application code, and frequently
modified (against good judgement) by installation of third-party
libraries, that's extremely fragile. This is a lesson that was learned
long ago in Java.

Take a look at java.net.URLClassLoader. It is the answer. You simply
create one, give it the path where it should look to find the plugin
classes, and call loadClass instead of Class.forName.

The purpose is really to avoid having to teach the plugin writer any more
than is strictly necessary to produce the plugin, since this is only a
simple demo app. Java knwoledge isn't an aim rather the algorithm they
write. I'd just like the writer of the plugin to just produce a classfile
and pop it in the right place for it to be detected.

Do you have an improvement without the need to jar the plugin?

URLClassLoader doesn't require you to use JAR files; you can give it
either a directory or a JAR file, and it'll work fine. However, I'd
strongly encourage you to provide at least the option to use JAR files.
Again, by using loose class files you are begging for problems and
frustration. You could easily define a plugin directory, and then allow
plugin code authors to either drop a JAR file in there *or* create a
subdirectory for their plugin.

To be honest, I'd be searching for an alternative very fast if I needed
to distribute loose class files to use your framework.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation