Plugins

[Miguel De Anda]

I'm making a program (actually a few that need the same functionality) that
needs to be able to pick up new plugins. This particular project is an mp3
player based on the javalayer library that has two types of plugins, display
plugins and controller plugins. The display plugins will receive updates of
media that is currently playing and the controller plugins will be able to
send commands to the player. I've made simple interfaces to both plugins but
I'm not sure what the best way is to start them up.

These are a few options that I had in mind:

1) When the program starts, it will look in a folder and assume the *.class
files are plugins.

2) Have a configuration file that lists what plugins to use and possibly
where to find them.

3-10) Whatever anybody else may suggest.

I'm thinking that there will only be one instance of each plugin and if a
plugin can support multiple people, then it will handle that itself. I've
already made a controller and display plugin that runs on a particular
socket to allow for remote administration.

(I will need to read up on synchronization a bit since it may become a
problem on this application since multiple things are controlling the same
object)

 

[Brad BARCLAY]

I'm making a program (actually a few that need the same functionality) that
needs to be able to pick up new plugins. This particular project is an mp3
player based on the javalayer library that has two types of plugins, display
plugins and controller plugins. The display plugins will receive updates of
media that is currently playing and the controller plugins will be able to
send commands to the player. I've made simple interfaces to both plugins but
I'm not sure what the best way is to start them up.

I've had to deal with such issues in Java with my jSyncManager project
(http://www.jsyncmanager.org) for the last 4 years. And let me tell you
-- at this time, there is no single, good solution.

These are a few options that I had in mind:

1) When the program starts, it will look in a folder and assume the *.class
files are plugins.

This is doable, but you can run into problems when you start running
your appplication outside of a traditional filesystem. If your
ClassLoader is loading classes from a DBMS or over a network, such a
mechanism isn't going to work. Which mean you either have to code
different mechanisms for different types of classloader, or make running
your code on a local filesystem as a fixed restriction.

So far, I've shunned this sort of solution with the jSyncManager.

2) Have a configuration file that lists what plugins to use and possibly
where to find them.

This is what the jSyncManager currently does. When we build the GUI
elements to allow the user to select the relevent plug-in (we have two
different plug-in specs -- one for "transports", which are designed to
control I/O to different bus/network types, and one for "jConduits",
which encapsulate data synchronization logic), we read the properties
file for a list of classnames.

However, a developer (or user) may not want to have to update the
properties file each time they introduce a new plug-in, so we also
provide a text input field where they can type in the classname (we
enforce specific packages where the plug-ins must reside, so the user
doesn't have to type the entire fully-qualified classname). We've also
provided a registration system for plug-ins to make it easy for plug-in
developers to write installation scripts that will automatically add the
relevent information to the property file.

3-10) Whatever anybody else may suggest.

Eventually for the jSyncManager project we'll probably create an online
database of plug-ins which the jSyncManager client can connect to to
grab a search list of possible plug-in classes, which can be used to
search the system to automatically build the selection GUI. This will
probably eventually get expanded to the point where you can actually
download the class over the network and instantiate it (we'll need to
build a whole signing mechanism and user-configurable trust system to
make this work securely).

But even with such a system, we'll still need to keep around the
current mechanism for those users who aren't constantly online.

HTH!

Brad BARCLAY

 

[Ashak]

I'm making a program (actually a few that need the same functionality) that
needs to be able to pick up new plugins. This particular project is an mp3
player based on the javalayer library that has two types of plugins, display
plugins and controller plugins. The display plugins will receive updates of
media that is currently playing and the controller plugins will be able to
send commands to the player. I've made simple interfaces to both plugins but
I'm not sure what the best way is to start them up.

These are a few options that I had in mind:

1) When the program starts, it will look in a folder and assume the *.class
files are plugins.

2) Have a configuration file that lists what plugins to use and possibly
where to find them.

3-10) Whatever anybody else may suggest.

I'm thinking that there will only be one instance of each plugin and if a
plugin can support multiple people, then it will handle that itself. I've
already made a controller and display plugin that runs on a particular
socket to allow for remote administration.

(I will need to read up on synchronization a bit since it may become a
problem on this application since multiple things are controlling the same
object)

As an extension of your point number 1, if you gave your program a
location (or possibly more), then could it not check all the class
files to see if they are subclasses of your interfaces? That would
ensure that any class files could be there and that only the ones that
implemented your interfaces would be considered as actual plugins...

I s'pose it's a bit of a rough way to do it.... but it would work and
should be fairly simple.

 

[Miguel De Anda]

Sounds like a good plan. I'll probably do it similar.