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]
