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. [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]
