Extending Java Web Applications with plugins

Question

I have this web application that has grown to an unmanageable mess.

I want to split it into a common \"framework\" part (that still includes web stuff like pages and im

Answer 1

Your primary problem is going to center around the physical, static assets of the system -- the rest are simply, effectively, jars.

WARs are separated, in Tomcat, with separate classloaders but also they're separated at the session level (each WAR is an indvidual web app, and has it's own session state).

In Glassfish, if the WARs were bundled in an EAR, they would share classloaders (GF uses a flat class loader space in EARs), but would still have separate session state.

Also, I'm not sure if you can do a "forward" to another WAR in the server. The problem there is that forwards use a relative URL to the root of the Web App, and each WebApp has their own root, so you simply "can't get there from here". You can redirect, but that's not the same thing as a forward.

So these features of the Web App conspire against you trying to deploy them homogenously within the container.

Rather, I think the hot tip is to create an "assembler" utility that takes your individual modules and "merges" them in to a single Web App. It can merge their web.xml, their content, normalize the jars and classes, etc.

WARs are a feature and a bug in the Java world. I love them because they really do make deploying compiled applications "Drag and drop" in terms of installing them, and that's feature is used far more than what you're encountering. But I feel your pain. We have a common "core" framework we share across apps, and we basically have to continuously merge it to maintain it. We've scripted it, but it's still a bit of a pain.

Answer 2

There actually is nothing better than OSGI if you are thinking about splitting application into separate modules. Take a look at Greenpages example. You can create a parent module (core) where you include jars that your application need.

If you know something about component programming, you will soon find out that OSGI modules behave like interfaces, where you have to expose what you will use in other modules. It is quite simple once you understand. Anyway it also can be really painful when you learn how to use OSGI. We had problems using JSON, as a version of Jackson that we added as jar to the module, was overridden by other jar that was contained in the Spring core modules. You always have to double check what version of jar is loaded for your needs.

Unfortunately even OSGI approach does not solve what we are searching for. How to extend a persistent model and existing forms in runtime.