On Thu, 2 Sep 2004 21:49:17 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Thu, 2 Sep 2004 13:50:30 -0700, Martin Cooper <[EMAIL PROTECTED]> wrote: > > On Thu, 2 Sep 2004 08:13:21 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > > > On Wed, 01 Sep 2004 22:28:42 -0700 (PDT), Martin Cooper wrote: > > > > * CVS freeze/tag date: Friday, September 3rd @ 6pm (Pacific time). > > > > > > Following discussion on the list, did we want to make that the CVS > > > freeze/tag/branch date? Of course, we could always branch on the tag later too. > > > > I'd been thinking that we'd create the branch, based on the tag, when > > we decide we need / want it. > > > > > Once this release ships, I'd like to update the roadmap and other documents to > > > reflect Servlet 2.3 as the minimum platform for Struts 1.3.x. > > > > Do we want to call that 1.3.x or 2.0.x? I'm thinking that some degree > > of revolution will happen in this next (2.3-based) version, as well as > > some logical evolution. I haven't yet seen any proposed advantages *to > > Struts future* listed for Servlets 2.4, and my own focus is on getting > > away from JSP dependencies in the core, so I'm not sure how much the > > 2.4/2.0 fans want to change that couldn't happen in Struts 1.3/2.0. > > But that's really another thread... > > > > I gathered that the conclusion for the "evolution" branch (which, > IMHO, should be called 1.3 if it's going to focus on things like the > chain version of RequestProcessor but remain fundamentally backwards > compatible).
The conclusion was... I think you didn't quite finish the sentence. ;-) One example of a concrete set of changes that I want to make in a Servlets 2.3 compliant "next" version of Struts will involve the use of a filter for file uploads, as well as significant changes to the interfaces involved. These are interfaces that are exposed as hooks today, so this would certainly break backwards compatibility. That makes it questionable, in my mind, as to whether we should make such changes in a dot release. And then there's the question of changing the core Servlets dependency in a dot release. Some time ago, we decided that we couldn't do that in a dot release, and needed to wait for a major version hike. We're allowed to change our minds, of course, but I just wanted to remind folks of what we had agreed on a while ago. ;-) If calling a "next" release 1.3 means we get to upgrade the dependency to 2.3, but have to remain backwards compatible in all other respects, then I think that would be unnecessarily limiting, and would suggest that we call it 2.0 instead. Of course, it's conceivable that we have a 2.0 based on Servlets 2.3 and a 3.0 based on Servlets 2.4 in development at the same time (a la Tomcat from a couple of years ago), but I think this would be unfortunate, especially if both groups were changing interfaces in different ways. > FWIW, here are some specific technical benefits (for the > framework architecture, for applications based on it, or both) if we > were to choose Servlet 2.4 over Servlet 2.3: > > * 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. These are all nice things to have, and would no doubt help clean some things up somewhat and fix some issues in people's Struts apps. But what I was really trying to ask was: What new Struts features do people have in mind that would *require* the use of Servlets 2.4 to accomplish? > The benefits of JSP 2.0 over 1.2 are even more compelling, but have > been discussed before. My favorite three favorite features are EL > everywhere, tag files (a way to create "simple UI components" with > just JSP code), and the simple tag API. > > Counterbalancing all of this, of course, is the question of installed > base. And, of course, that is a question that has a different answer > at different times. If we want to work towards a GA quality 1.3 > release in 3-6 months (possible if the set of changes is limited), > than staying with 2.3/1.2 makes a lot of sense. But if it takes us > the more typical 12-18 months, where do *you* think the world is going > to be by then? To be honest, I expect that some app server vendors will not be much further along than they are today. It is only recently, for example, that WebSphere has even supported JDK 1.4, and not *that* long since IBM and BEA introduced support for Servlets 2.3 / JSP1.2. However, I would be very happy to be wrong about that. ;-) -- Martin Cooper > NOTE: None of this is to suggest that maintenance activities on 1.2.x > should not continue. However, it should, IMHO, be focused on bug > fixes rather than feature enhancements, and should (of course) remain > based on Servlet 2.2 / JSP 1.1. > > > -- > > Martin Cooper > > Craig > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
