On Thu, 2 Sep 2004 22:20:33 -0700, Martin Cooper <[EMAIL PROTECTED]> wrote: > 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. ;-)
One other related point: I cannot make architectural decisions for my products based on the hope that the container support will be there before I'm done - something I would have no control of. That means that, realistically, I would be unable to *start* development using a Servlet 2.4-based version of Struts until the app servers were available, at least as Beta versions. With a Servlets 2.3-based version of Struts, I can start development as soon as I believe that the necessary core interfaces are stable - and, of course, I have the ability to help make that happen in the timeframe that I need. -- Martin Cooper > > -- > 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]
