struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeromy Evans <>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Sat, 26 Apr 2008 04:21:35 GMT
Putting aside the technology for a moment:
 - ability to deploy new actions/replace actions and pages without a 
container restart: highly desirable
 - ability to deploy new/replace business-layer services without a 
container restart: highly desirable
 - ability to evolve Struts2 without fear of breaking an API; highly 

If, through appropriate packaging, OSGi facilities those requirements 
that them I'm all for it. At this point I don't have a good appreciation 
of what *actually exists* in this area.

I'd take care to ensure Struts2 continues to target entry-level 
containers though (ie. Tomcat rather than Glassfish).

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