struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Don Brown" <mr...@twdata.org>
Subject Re: [s2] A thought - next generation OSGi-based?
Date Sun, 27 Apr 2008 10:49:39 GMT
Ok, I promised a more detailed proposal, so here it is:

http://cwiki.apache.org/confluence/display/S2WIKI/Struts+2.5+Based+on+OSGi

I converted Jeromy's goals into a more proper tech spec (with the
pretty diagrams to follow...)

I highly recommend those not familiar with OSGi to take a look at the
references section, specifically the tutorials.  OSGi brings some
significant, game-changing elements to the table, so to fully
understand the proposal and its possibilities, give them a look.

I'll be updating the proposal to incorporate more feedback as I
receive it.  I'll be at JavaOne next week, so swing by the Atlassian
booth and let's talk shop.

Don

On Sat, Apr 26, 2008 at 2:21 PM, Jeromy Evans
<jeromy.evans@blueskyminds.com.au> wrote:
> 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
> desirable
>
>  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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> >
> >
> >
> >
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>  For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message