----- Original Message ----- From: "Craig McClanahan" <[EMAIL PROTECTED]> Sent: Friday, September 03, 2004 6:02 AM
> On Fri, 3 Sep 2004 01:10:43 +0100, Niall Pemberton > <[EMAIL PROTECTED]> wrote: > > I agree with what Vic said in this thread on the Servlet Spec issue - if we > > can take the Servlet version out of the equation so that any version can be > > plugged in to the core controller than that would be really good. > > We have that already, right? Struts runs on Servlet 2.2 / 2.3 / 2.4 > platforms today. Mostly, but some of it doesn't because its constrained by 2.2 - such as the multipart handling or encoding > What you can't do is a fundamental redesign of a controller > architecture that depends on 2.4 features and craft it in such a way > that it's an optional add-on feature that can be plugged in on top of > 2.2 or 2.3. Adding something like "filters that work on a > RequestDispatcher call" cannot be added at the application level -- > they have to be done by the container. I haven't put much thought into this, but what I understood Vic was saying was that the *core* controller element of Struts could move to Commons Chain and be agnostic about the underlying technologies. Using the multipart example again, it would be easier to plug in different mechanisms to wrap the request for different Servlet Specs. Clearly people could resolve this in the current version with a custom RequestProcessor - but its not practical for Struts to ship multiple RequestProcessors for every flavour people want. If we move to CoR though it would probably be practical to ship a set of components for the different servlet specs that users could just plug in. Seems like you're thinking along different lines though. I'm not up to speed with the 2.4 Spec so I don't know the killer features I would want to base a fundamental redesign on - the kinds of things I was thinking about are more periferal. Guess I need to find time to take a look at it :-( > Unless, of course, you plan on re-inventing what RequestDispatcher and > Filter do ... but that seems like a monumental waste of time. > > > > > The JDK thing is a different issue though - it could be developed with > > compatibility to existing JDK versions and keep everyone happy. I have no > > technical reasons, but I would like to go to JDK 1.5 simply for the reason > > that it scratches my itch to play with the latest stuff and hopefully > > produce simpler, cleaner code with the new features it provides. > > Standard JDK 5.0 annotations cannot be used (inside of Struts) if you > want to work on prior JDKs. Neither can generics. Or autoboxing. Or > (insert-your-favorite-new-feature-here) ... > > Without all of that, what's the point again? :-) I wrote that badly - meant it to read as an either/or something like.... Either it could be developed with compatibility to existing JDK versions and keep everyone happy. or go with JDK 1.5 and my preferernce would be to go to JDK 1.5 and use all those favorite-new-features. > > > > Niall > > > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
