struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Musachy Barroso" <>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Thu, 24 Apr 2008 16:58:02 GMT
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)


On Thu, Apr 24, 2008 at 12:09 PM, Don Brown <> 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:
>  For additional commands, e-mail:

"Hey you! Would you help me to carry the stone?" Pink Floyd

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message