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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > James Mitchell > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
