Since I started playing with the OSGi plugin this has been on the back of my mind, I think it would be a good idea (support for OSGi is showing up all over the place, I just read somewhere that glassfish will run on an OSGi platform)
musachy On Thu, Apr 24, 2008 at 12:09 PM, Don Brown <[EMAIL PROTECTED]> wrote: > As I learn more and more about OSGi, I wonder if it might be the > solution to several big problems we seem to have at the moment: poor > reloadability and the lack of a solid API. With OSGi, you can drop > bundles in and out of the system at runtime, even running multiple > versions of the same bundle side-by-side, but the feature I'm most > interested in right now is how it would allow us to put in a proper > API while maintaining full backwards-compatibility. > > Evolving a web framework is hard because apps tend to be written on a > specific version, and to migrate them to new versions has two > problems: development may not be continuously funded and the upgrade > may require too many changes to the application. On the other hand, > if you don't evolve your web framework, you quickly go out-of-date and > lose interest from new developers. In our case, despite being a > relatively new framework, we have legacy code around from 2004 that we > can't just remove, yet we want to provide an attractive, modern, clean > framework for new development. > > The specific issue it hand that I've been thinking about is how to get > a proper API into Struts 2 yet keep backwards compatibility, and I > think OSGi might provide a solution. What about this: > 1. Struts 2 and its plugins remain the way they are now - 100% > backwards-compatibility > 2. An OSGi plugin provides the platform for the next generation of Struts 2 > 3. A new API bundle is created, implemented by the underlying Struts > 2 framework > 4. Old apps can continue to write and deploy code against Struts 2, > yet new development can start to use the new API > 5. Later, when we want to write API version 2, we create a new bundle > that runs side-by-side the old bundle, both implemented by Struts 2 > > Basically, OSGi would allow us to write a clean layer on top of a > framework, much like how Grails builds on Spring, but we get, as a > side benefit, all the architectural advantages of OSGi for free. > Furthermore, if we do it right, users don't have to know or care that > OSGi is under the hood - all they know is they write a jar, drop it in > a directory or upload it via a form and they just installed part of > their application at runtime. > > Don > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
