Extending Web Applications
I'm not sure where the best place to post this message is, but since the most recent line of research I've been doing has lead me to OSGi and Spring dm (which is close, but still not quite there), this looks like the right place to post.
I've got some real-world scenarios that the OSGi platform seems very well suited to, but, from what I can tell from research, still does not quite hit the mark. Let me mention a few, and then talk about at least as far as I've gotten. Maybe there is already some technology that solves these problems, or maybe this is "in the works" but not built yet.
Scenarios:
1) Web application A is deployed. Customer 1 likes it plain. Customer 2 wants a couple of stylesheet tweaks for branding. Customer 3 wants a little bit of the business logic changed. So the end result are three new virtual applications that are the result of A merged with a set of changes for each customer.
2) Web application A is deployed. Optional application module B is developed and needs to be plugged into A, not just adding new files, but also making small tweaks to some of the existing files (adding menus, adding fields to existing pages, adding additional workflow, new pages to wizards, etc). So when B is deployed, the end result is a new virtual applicaiton that merges A and B together.
3) Web application A is deployed. Bugs are found. A patch (call it P1) that contains just the patched files is plugged in. The new application (that results of merging A with P1) is tested and something isn't working. The patch is then unplugged and reworked until it is gotten right.
I was pretty excited to read about dyamic modules, and learn about OSGi fragments as a way to solve some of these problems. As it turns out, I don't think dynamic modules or fragments can solve any of these.
For example:
Case #1 sure seems to call for fragments. However, in order to get this to work, you'd need multiple copies of the base application A deployed 3 times, each one modified by a different fragment and accessible by a different hostname (or context path or something). Having multiple copies of the base application is not very efficient (you end up with multiple copies of JSP classes compiled, multiple classloaders, one for each app, loading all the classes for the app, etc). What you really want to be able to merge a set of fragments with a web application "virtually" so you really only have one base set of classes and instances loaded in memory.
Case #2 sure seems like fragments would come to the rescue here as well. However, since fragments can't override content in the base (just add to it) it can't be done. Instead you would have to munge the original application to add the ability to "configure" it to add in the extra stuff needed to handle the presence or absense of module B. That's fine if you are the primary owner of the base application. But what if you really just wanted to overlay your new module B on top of some existing web bundle, maybe one that was produced by someone else, to get your new extended application without having to modify the base code (i.e. treat it as a 3rd party/vendor provided module)?
Case #3 also seems like dynamic modules would come to the rescue. Unfortunately again, fragments can't override content in the base, so you can't augment an OSGi module with a fragment that merges with it to produce a patched module. It seems OSGi CAN handle this through simply upgrading to the latest version of the modules with the "update" functionality, and if that doesn't work, you can always roll back. But it seems that's not the "traditional" patching model (where the patch is placed ahead of everything else in the lookup path so its stuff comes first, and if you want to unpatch, you just remove it from the lookup path and the original versions of stuff will be found).
All the problems seem to be related, and it seems like a single solution might be able to address all 3 of these issues. OSGi and fragments sure seem to be "close" to the solution, but not quite. So, is there a solution, using Spring, OSGi, or some other technology to any of these problems? If the answer to these is that there really is no good standardized solution to these problems that exists now, then is there anything that might be already specified and not built, or even some upcoming specifications that might help solve these problems?
Thanks in advance!
-J.C.
Originally Posted by Costin Leau
