On Fri, 3 Sep 2004 07:11:48 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > OK, to sum up what people seem to be saying here: > > [Struts 1.2.x] > > * The minimums for 1.2.3 will remain Servlet 2.2 > > * We create a branch at the 1.2.3 tag, in case we need to make critical fixes to > 1.2.x later.
As I mentioned, I would prefer to create the tag now (which I'll be doing in a couple of minutes), and create a branch at that tag if / when we need it. In other words, I'd suggest s/in case/when/. ;-) -- Martin Cooper > > [Struts HEAD] > > * For now, Struts HEAD can remain in evolutionary mode, but we will bump the minimum > to Servlet 2.3. At this point in time, this seems like a minor change, and so for > the purposes of the Roadmap, we could assume the next release will be 1.3.0. But the > final decision is up to the PMC when there's something to ready to release. ( > > * If anyone on the PMC feels strongly about the versioning, we can change all the > markers on the Roadmap, so features slotted for 1.3.x ascribe to 2.0.x, and so > forth, but that seems like a lot of churn for little benefit > > * Some of the reasons we are moving to Servlet 2.3 are: > > * It is preferred platform of active Struts developers. > * It is needed for certain enhancements, including some to file upload. > * It simplifies distribution and integration of JavaServer Faces components which > are dependant on Servlet 2.3. > > * If at any time, we decide to move the HEAD to revolutionary mode, so as to stretch > or break backward-compatibility, we can branch again, and assume that the HEAD will > become 2.0.0 at the next release. But, we don't have to make that decision until a > revolutionary commit is pending :) > > * So far, items like Struts Chain count as evolutionary, since it seems we will be > extending the API to support other "Action" signatures (e.g. for Portlets), but not > removing the old ones. (As we did when we changed the signature for Exception > handling.) > > [Struts NEXT] > > * Any time anyone is ready to plunk down some code (or even just branch), several > people sound eager to work on a Servlet 2.4 implementation of Struts. (Whether we > need to also specify JSP 2.0 is yet to be determined, since it might be irrelevant.) > > * How compatible a revolutionary codebase is with Struts will be up to the people > implementing it. (This can be you!) > > * The mechanism by which a codebase is labeled a Struts release is a majority vote > of the Struts PMC. Just because a committer starts a revolution in an Struts > repository, doesn't mean the PMC has to sanction it later. Every release decision > has to be based on the quality of the codebase itself. There can be no guarantees. > > * Any revolutionary implementations should start work under a label, not a version > number. Once there is something to release, the PMC can decide whether it gets > released and what's is version number will be. Tomcat's "Catalina" is one example of > the labeling practice. The Struts "Jericho" whiteboard is another. > > * Some advantages of basing a framework on Servlet 2.4 include: > > * HttpServletRequest.setCharacterEncoding() allows applications to > resolve nearly all the ambiguities of parsing request parameters in > the right encoding (which is a smaller number of problems than it used > to be in 2.4 generally, because the rules have been tightened, and > because of the next feature). > > * You can define (in web.xml) your own mapping table from locale > to character encoding, rather than relying on the container's > undocumented (and likely non-portable) defaults. > > * Filters can be declared to run on RequestDispatcher.forward() calls > as well as on the original request. Without this, it's basically impossible > to write use-case-specific Filters in an MVC framework that uses > RD.forward() the way Struts does today. > > * ServletRequestListener fleshes out the lifecycle model, so you can do things > like adding some resource to the request attributes, and knowing that it will > get cleaned up (after the response has been rendered by the JSP page or > whatever) by your listener. > > * ServletRequestAttributeListener can listen to changes on your request > attributes, similar to how HttpSessionAttributeListener and > ServletContextAttributeListener work in 2.3. > > * On an HttpSessionBindingListener, the listener is invoked when you actually > expect it to be at session end (*before* the session is invalidated, > rather than after). > > * "Welcome Files" can now be servlets, so you can use "index.do" instead > of having an "index.jsp" that forwards to an action that does your setup. > > * Deployment descriptors (web.xml) that conform to the 2.4 schema can > have their elements listed in any order, instead of the pretty arbitrary > sequence required by 2.3. > > Of course, I'll update the roadmap.xml file accordingly, along with any > clarifications made to this thread. > > -Ted. > > --------------------------------------------------------------------- > 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]
