struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Newton <>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Thu, 24 Apr 2008 16:52:17 GMT
I'm also pretty stoked about the possibilities of OSGi; I think it's a
potentially Pretty Big Win for all sorts of functionality. I don't know a
whole lot about OSGi yet, but it sure seems like a globally-useful tool.

I'm all for it; +1.


--- 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:

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

View raw message