On Mon, 30 Aug 2004 10:14:15 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On Mon, 30 Aug 2004 06:09:02 -0400, Ted Husted <[EMAIL PROTECTED]> wrote: > > It was once proposed that we "leap frog" Serlvet 2.3 and go straight to 2.4 for > > Struts 2.x. But, I continually see references to little things people could do > > better if our minimum were Servlet 2.3. > > > > Since no code has been written for Struts 2.x, it does not seem reasonable to hold > > back enhancements that we could make today, if our minimum platform were Servlet > > 2.3. > > > > Here's my +1 for moving the minimum platform to Servlet 2.3, today. Carpe Diem! > > > > -Ted. > > > > +1 to updating the minimum platform for Struts .Next to be Servlet 2.3 > (and JSP 1.2), although the technical benefits of going one step > further (2.4/2.0) are so compelling I'd be in favor of going there > instead: > > * Servlet filters can run on request dispatcher calls > > * Cleaned up semantics for internationalized apps
How might we want to take advantage of these newer Servlets features in Struts? I've seen a list of why we want to advance to 2.3, but I'm not clear on what 2.4 might do for Struts specifically. (My own requirements are for 2.3, but I'm still interested in what the future might hold. ;) > * JSP 2.0 has many new features, including EL everywhere, > simple tag apis, tag files, much better XML syntax, ... JSP 2.0 definitely has lots of good stuff in it. However, my feeling is that we want to avoid, or at least isolate, JSP dependencies in the Struts core. So in that sense, JSP 2.0 doesn't really matter to us very much. -- Martin Cooper > > The counterbalance, of course, is the smaller number of deployed > containers supporting these APIs -- but that couterbalance gets > smaller over time, and I suspect will be non-existent by the time we > could get to a complete enough release to be GA quality. > > I also suspect, given our track record :-), that re-engineering Struts > from scratch based on the latest platform APIs wouldn't take more time > than a gradual refactoring from the current code. > > Regarding branches, STRUTS_1_2_BRANCH should definitely be created if > it's not yet, for ongoing development on that track, so the head can > be used for new development. > > And, since we'll contemplate non-backwards-compatible changes anyway, > let's just call it Struts 2 and be done with it. > > Craig > > > > > On Sun, 29 Aug 2004 10:47:01 -0700, Martin Cooper wrote: > > > I would be very much in favour of breaking out the multipart > > >ïhandling properties into their own section. However, I don't really > > >ïwant to do this now. I'd prefer to wait until we rip out the > > >ïmultipart code into a filter, rationalise the interface, and better > > >ïalign the implementation with Commons FileUpload. With that set of > > >ïchanges, the specific parameters will likely change, so I'd prefer > > >ïto change everything at once. (This is one of my own itches that > > >ïhas needed to wait for a Struts 2.x or higher, because of the > > >ïServlets 2.3 requirement. ;) > > > > On Sun, 29 Aug 2004 20:22:57 -0500, Joe Germuska wrote: > > >ï29668 is basically a statement of the problem I am facing. ïI guess > > >ïI should have looked through bugzilla. ï ïIt looks as though 29824 > > >ïproposes using setCharacterEncoding, so I don't think it would > > >ïcompile with Servlet 2.2. ï(I haven't tried it yet.) > > > > --------------------------------------------------------------------- > > 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]
