Please give an advise on how to do "plugin" architecture for Java web application.
Currently we are using quite simple and standard Spring+Hibernate+Struts 2 in Tomcat servlet container. (Built with maven)
I need something like Redmine. Where any module can be enabled/disabled, updated
Please exclude heavy options like OSGi, Portlet.
OSGi is too heavy, there is no good adoption of the technology for web. I already looked at Eclipse Germini;
Portlet it just old, and never was popular.
I will try to provide several possible solution. I did spent some time preparing small PoCs for the project I'm working on, so let's hope the options below are relevant.
Important note: it is really easy to define some extension point, do resolve and find available implementations. There are a lot of solutions available, for example good and simple one -- JSPF
Resources are the main problem for WEB applications
OSGi
OSGi, is not that bad and can be useful. It seems to be heavy (and some implementations are heavy) but this is price of standardized platform. I would suggest to check Apache Felix. It can be used in a "lightweight" mode. By the way, it includes Web Console which is build as loosely coupled plugin-based application, could be helpful:
Some examples Extending the Apache Felix Web Console
The Web Console can be extended by registering an OSGi service for the
interface javax.servlet.Servlet with the service property
felix.webconsole.label set to the label (last segment in the URL) of
the page. The respective service is called a Web Console Plugin or a
plugin for short.
You can also check eie-manager which is clean and simple and uses OSGi to manage plugins. Could be a good example for you.
Custom plugin framework
I would suggest to review solution behind Jenkins/Hudson. I would say Jenkins plug-in system is quite mature and reliable. Can be used as a good example.
Please also check Hudson Plugin Architecture
Simple solution
For my project I've build plugin abstraction layer based on JSPF with custom dependency resolver.
PROS:
simple and small
clean concept
works good
CONS:
without proper plugin management can be slow (full classpath search)
provides very basic functionality
may require additional attention
I would suggest to use JSPF only if you really need some simplicity and want to control everything. JPF provides a lot of interesting features out of the box, for example:
Plug-ins can be "hot-registered" and even de-registered during
application execution. What's more, registered plug-ins can be
activated and deactivated "on the fly", minimizing runtime resource
usage.
The problem is JPF is dead.
Suggestion
Do spend some time with Apache Felix. It is mature enough, so your time investments may pay back a lot.
Check out the answers to this question: Best way to build a Plugin system with Java
If you don't trust the plugin code, you can implement sandboxing, as described here: Sandbox against malicious code in a Java application
The open-source Java Plug-in Framework project supports plugin deactivation, you can get inspired from it even if it is too heavy for your purposes.
Atlassian open sourced their plugin system here. I see it is being worked heavily by Atlassian team. Worth to explore its documentation
Related
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?
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 (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
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).
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.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
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.
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
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?
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 (and blogged about it) that consists of two plugins, one of which is denied access to local resources.
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).
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.
Use PF4J.
It has support for Web, Spring and Wicket.
Easy to use and build the applications
There is also JPF (Java Plugin Framework).
I worked on OSGi for a week--an intense, nothing but OSGi week. At the end it was like a bad dream but I learned a lot.
I was able to get OSGi working (not easy, all examples are out of date, everything on the net is at least three years old if not five), but I had serious trouble getting it integrated into an existing project because of issues with the jar manifests.
In short, there are only a few obscure tools used for building manifests and they are not well documented (BND Tools is hardly obscure, but it is designed for a certain process in Eclipse). Also, most of the OSGi information available is not targeted towards application developers who have an existing desktop application.
This makes a lot of the context for the information foggy or inappropriate. Neil Bartlett's blog posts were the biggest help, but even those failed to get a working system (I grabbed some code from the Felix tutorial and pieced it together to get the embedded framework rolling). I found his book draft that he posted for free years ago, which is excellent, but the examples in Eclipse do not work because of changes in Eclipse OSGi support.
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.
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
We are planning to use IBM Web Experience Factory for our future enhancements. From the project management point of view we are thinking of using Maven. But due to no online help available for using both the things together we are not able to move ahead.
Please let me know if anyone can provide inputs.
We did a web application that needed to be deployed on IBM Websphere and we learned a couple of things. Maybe they can help you:
If your application depends on certain IBM API's (like Virtual Member Manager), you should declare that dependency as provided and let the container manage it for you. For compilation purposes, you should add the required JARS to your Maven Repository (in our case, Archiva).
For deployment you should relay on Jython scripts to do the Job. The execution of the scripts can be done with was6-maven-plugin (they say that they can handle the EAR deployment, but it can only be donde through Jython and wsadmin. Maybe you're more lucky than us)
There is no direct maven integration for the IBM Web Experience factory.
Your best shot is using maven and ant. There are some guides on build automation in the Web Experience Factory Wiki.
You have to do some preparations and afterwards you can generate the war.
You can integrate those tasks with Maven AntRun.
We tried generating the war files with ant, however even though everthing compiled and the war looked good, we encountered problems within the application that stopped us continuing with this approach. It wasn't reliable enough.
For the point Maven i don't understand how you get to say "no online help available" ...despite the official books http://sonatype.com/Support/Books you can read many things online on http://maven.apache.org/ furthermore there some other books which can be bought via Amazon or take a look at http://maven.apache.org/articles.html for an overview. Or for a starting point you can read at http://maven.apache.org/users/index.html. Last but not least you should take a look at the mailing lists for Maven. If you are searching for particular help about IBM WebSphere Portlet factory in relationship with Maven you should be more specific about the problem.
I want to know why OSGI framework is used when building java applications. I am searching the web for this but answers look complex to me. Can anyone please explain few points on why we need to adopt osgi.
Am sorry if the question does not suit stackoverflow
I appreciate the patience of the readers. Thanks.
OSGi provides a modular system with versioning of the modules, and further a bit of life cycle management. It manages dependencies between modules, dynamic/lazy startup/uninstall of modules, lookup/discovery and such.
Part of this will become part of the java language. It enables a lesser complexity than a spaghetti wiring of classes.
IMHO OSGI on its own requires a a lot of boiler plate code for what it does. However if you use a library like Karaf & iPOJO most of the overhead is hidden and you get most of the benefits.
The main benefit is being able to control which versions are used and proper module isolation. For example you can
have the container download the right versions from a maven repository like nexus.
use multiple version of the same library and have the modules which need those use the right ones.
stop, upgrade and start modules while the application is running.
a web console to see the state of all your modules and manage them collectively or individually.
For me the best part of OSGi is that it promotes a service-oriented view of your system, which helps decoupling, testing and teamwork.
I don't think it has to be complex, as I tried to demonstrate with my "OSGi for mere mortals" example application [1] and slides [2] (both shameless plugs ;-)
[1] https://github.com/bdelacretaz/OSGi-for-mere-mortals
[2] http://www.slideshare.net/bdelacretaz/osgi-for-mere-mortals
Go through with this tutorial thoroughly. You might get your answer.
OSGi is a fast framework because it knows that which service will be loaded into OSGi environment thanks to pre-defined xml file. It reduces runtime cost thanks to lazy state. Service instance is created when they needed. Some bundle's different version can be used by other bundle at the same time. Since each plug-in has it own class loader, any bundle can be stopped, started, installed or uninstalled without stopping Java Virtual Machine.The communication among the bundle is possible by using declarative service or service tracker in OSGi environment via interfaces. Using interface frequently pay the way for reusable code. Although OSGi framework contains quite a few class and interface, powerful projects can be created by using it. Since java runs everywhere, OSGi can also run.
I am creating an application which uses the Java Plugin Framework to load plug-ins and integrate them into the program.
My question is: Is there any way to restrict certain operations (such as starting a new process) in the plug-ins? What I have in mind is something like Java WebStart, i.e when the application wants to access the FileSytem, the user is prompted whether or not to allow the action.
I was thinking of maybe creating a security manager and, if so, how can I do that?
I suggest you look at these
http://www.google.co.uk/search?q=system+set+security+manager+example
One question comes to my mind - why did you choose JPF and not Equinox? I was curious and looked at the JPF pages and it looks like the projects last update is two years ago.
They started the project to decouple the eclipse plugin framework of Eclipse 2.x but Eclipse itself moved to OSGi (Equinox) starting with version 3.0. Equinox has become the reference implementation of OSGi and there's a lot of good books available and even more excellent experts that can provide help on any aspect.
To my opinion: JPF was a good idea some years ago (just as the first implementations of a plug-in framework in early Eclipse releases) but the actual standard for a plug-in framework seems to be OSGi now.
Sure, that does not answer your question, but my message was just to long for a comment.
Here's a site that explains implementing security with Equinox (or at least gives some hints): http://www.eclipse.org/equinox/security/