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
