Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <436d9a250804281535s6137b0dcha0ce2bf63f249324@mail.gmail.com>
Date: Tue, 29 Apr 2008 08:35:18 +1000
From: "Don Brown" <mrdon@twdata.org>
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [s2] A thought - next generation OSGi-based?
In-Reply-To: <37e451880804280646n34893ebav6ea85f6bce713a9e@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <436d9a250804240909x39ded697h452e25b942e750df@mail.gmail.com>
	 <4812ADCF.4070807@blueskyminds.com.au>
	 <436d9a250804270349q4dca76aese3d5c791f030924f@mail.gmail.com>
	 <37e451880804280646n34893ebav6ea85f6bce713a9e@mail.gmail.com>

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