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 Mon, 28 Apr 2008 22:35:18 GMT
Nope, no changes to XWork are necessary, and most likely no changes to
Struts 2 core either.

Don

On Mon, Apr 28, 2008 at 11:46 PM, James Mitchell <jmitchtx@gmail.com> wrote:
> How does this affect XWork?  It seems like most of this would need to be
>  integrated into XWork core, so, would XW need to be completely overhauled?
>  Move it to the ASF?
>  Or do we drop XW altogether for something else?
>
>  Is there enough here with this proposal for an Action Framework JSR?
>
>
>
>
>  On Sun, Apr 27, 2008 at 6:49 AM, Don Brown <mrdon@twdata.org> wrote:
>
>  > 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
>  >
>  >
>
>
>  --
>  James Mitchell
>

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


Mime
View raw message