Friday, February 12, 2010

Plugin Architecture for Java EE Web Applications?

Java EE Web Applications are usually self-contained, in the sense that there is only limited runtime extensibility. It begs the question: How to support plugins architecture in a Java EE webapp?

Examples in the real world:
  • Mozilla Firefox addons
  • NetBeans modules
  • Eclipse IDE plugins
  • Servlet containers and WARs
A plugin system for Java EE would basically allows you to load in arbitrary jars as plugins. In case of plugins containing web resources, they would probably be WARs, not just JARs.

The plugin system requires the capability to load a plugin WAR (a sub-WAR, perhaps) inside an already running WAR. These plugin WARs can be added, removed, configured, at runtime just like relationship of normal WARs with the container.

Java Portlets are the closest thing to a standard way of doing this. You deploy portlet WARs into a Liferay container, easy. But since we're creating something like a Portlet container, it isn't straightforward.

OSGi is probably the best bet, however it also has its own complexities and classpath model.

What's your advice?

2 comments:

  1. Maybe by creating your own container with annotations and (sniffer, deployer, container, appcontainer). This is the way i'm trying currently :)

    http://blogs.sun.com/dochez/entry/glassfish_v3_extensions_part_5

    Grtss

    ReplyDelete
  2. Thank you Jerome.

    I tried to comment on your blog, but comments are closed.

    It seems a bit complex for me... and proprietary.

    I think similar feat can be achieved through OSGi Blueprint service. Basically we're just using OSGi, but with annotations.

    Another problem with OSGi-style components are JAR deployments. Meaning it's practically impossible to do exploded-archive rapid development (aka .class-driven development vs. JAR-driven development).

    I don't think your proposed solution handles exploded-archive development. Seems to handle component as JAR.

    ReplyDelete