Great questions, J.C.!
We'd certainly considered pluggable styling as a use-case for Slices, but hadn't considered that users may want to deploy multiple copies of the same application each with different styling on the same dm Server instance.
Originally Posted by jchamlin
If I've understood you correctly, you'd like to be able to deploy the same application to three different context roots, and then to style the application differently depending on which context root it was accessed via?
You can do this with fragments and Bundle-ClassPath, although you would have to modify the existing bundle. A host bundle can reference a Jar in its Bundle-ClassPath header that doesn't actually exist in the host. A fragment can then attach to the bundle to provide this Jar. If you specify the Jar before '.' (the default for Bundle-ClassPath) then it can override the bundle's content. This approach is described in section 3.8.1 of the OSGi 4.1 spec.
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)?
As described above, you can override content with a combination of fragments and Bundle-ClassPath so, hopefully, OSGi can offer you a solution here.
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?
I'm hopeful that you can get pretty close today with the use of Bundle-Classpath and fragment bundles. Your very first requirement isn't something that can be done today with Slices, but it's not beyond the realms of possibility.
The response was to look at Spring Slices. So we did. It is a very cool technology, and definitely close to what we're thinking we'd like to do, but not quite. Slices requires partitioning of the application modules via a sub-context path. As well, the slices really do not know and cannot interact with each other.
What we're thinking is a bit more general purpose... slice-like modules that would plug-in and basically provide classes and resources that come ahead of the WAR in the search path. Some resources would override, some resources could merge (css, web.xml, etc), some could extend the parent resources.
Thoughts on what we might want to look into? Maybe we could talk in more detail about what we wanted to do, and how Slices might be adapted to fit a more general problem? I think possibly an adaption of this technology could be used for customization, modules, and patches.
I look forward to your feedback on the fragment and Bundle-ClassPath approach described above. I'd also love to hear some more details on your requirements, particularly those related to Slices, so that we can consider them in our development work.
Thank again for the thought-provoking questions.