views:

2357

answers:

6

How would you implement a Plugin-system for your Java application?

Is it possible to have an easy to use (for the developer) system which achieves the following:

  • Users put their plugins into a subdirectory of the app
  • The Plugin can provide a configuration screen
  • If you use a framework, is the license compatible with commercial developement?
+18  A: 

Use OSGi.

It is the foundation of the Eclipse plug-in system. Equinox is Eclipse's implementation (licensed EPL) and Felix is the Apache Project's implementation (licensed Apache Public License).

Eclipse provides a concrete example that OSGi can cover the points you mentioned (or you could just build your application on top of Eclipse RCP if you want a full Eclipse/SWT/JFace stack).

Aaron Maenpaa
I have dabbled with OSGi but never found a really good primer for it. It would be great if somebody could recommend some links here.
bmatthews68
I've embedded equinox into my application and used standard OSGi practices to do exactly what the OP wants. In swing too, not SWT. Webstarted as well.good starting resource:http://neilbartlett.name/blog/
basszero
OSGi is ideally the de facto plugin system. However, the leap from standard Java to OSGi programming model is pretty wide...
Hendy Irawan
+11  A: 

First you need an interface that all plugins need to implement, e.g.

public interface Plugin {
    public void load(PluginConfiguration pluginConfiguration);
    public void run();
    public void unload();
    public JComponent getConfigurationPage();
}

Plugin authors should then bundle their plugins into JAR files. Your applications opens the JAR file and could then use an attribute from JAR manifest or the list of all files in the JAR file to find the class that implements your Plugin interface. Instantiate that class, the plugin is ready to go.

Of course you may also want to implement some kind of sandboxing so that the plugin is restricted in what it can and can not do. I have created a small test application that consists of two plugins, one of which is denied access to local resources.

Bombe
the sandbox you mention is actually the most difficult part! but not to fret - osgi already does it for you as mentioned above.
Chii
Sandboxing isn’t that difficult. Took me about two weeks to find out how to do it correctly but once you know that it’s pretty simple. :)
Bombe
So, give us some clues :-)
Sven Lilienthal
http://pterodactylus.net/download/security-test.tar.bz2
Bombe
+6  A: 

There is alos JPF (Java Plugin Framework)

http://jpf.sourceforge.net/index.html

jan
Has anyone here used JPF? Sounds interesting
Sven Lilienthal
+3  A: 

Since 1.6, there's been java.util.ServiceLoader which can be used if you want to code your own simple system.

But if you want anything more than basic features, use one of the existing frameworks.

Pete Kirkham
+1  A: 

I think that recommending OSGi for solving the above stated problem is extremely poor advice. OSGi is "the right choice" but for a scenario as the one above, I think either JPF or some homegrown minimalistic framework is sufficient.

Steen
A: 

Years ago I started a project like that and I hope soon will be ready.I got inspired by projects like NetBeans and Eclipse but meanwhile it changed to something a little bit different. OSGi looks like a good choice now, but I didn't had a chance to compare it with my project.It is similar with JPF mentioned above, but in the same time different in many ways.

The basic idea which motivated me is to be as easy as possible to build Java application, with no separation between web applications, desktop applications or applet/JWS applications(of course this doesn't cover the UI - yet) as a core functionality.

I built the project with a few goals in my mind :

  • it doesn't matter if you build a web application or a desktop application you should start the application in the same way, a plain main method, No fancy web.xml declaration(not that I'm against having a standard web descriptor, but it doesn't go well with a plug-in system, where you add "servlets" - I call them RequestHandler(s) - dynamic at your will).
  • easy to plug in "extensions" around an "extension point" - something from Eclipse but a different approach.
  • self-deployable, since all the plugins are registered(XML files) the application must be self-deployable independent of the build system - of course there is an Ant task and a Maven MOJO which are the links with the ourside world, but in the end it calls the application and instruct it to self-deploy itself at a specific location.
  • borrowed from Maven, it can download code from repositories(including Maven 1 & 2 repositories) so your application can be deployed as a single small jar as long as you have access to the repositories(useful sometime, and basically this provides support for auto-updates - don't you love the idea to be notified by your web application that there is a newer version, it was downloaded and it just needs your permission to install it? I know I love that).
  • basic application monitoring about system health, email notifications in case of failures
adrian.tarau
good luck Adrian!
Hendy Irawan