But, it's also my feeling that the refactoring of the Request Processor could open the door to being able to offer more than one front controller for Struts 1.x.
The default servlet/request processor configuration should be targeted for Servlet 2.2/1.1, but there might be enough flexibility there for another configuration that supported Servlet 2.3/1.2 and shared most of the code that mattered most. Such alternate configurations might be made available here, or as a third-party extension, or on Struts SourceForge, but I can see them existing. It's just a matter of whether anyone cares enough to make it so.
IMHO, the real point of Struts 2.x is to give us a chance to put backward compatibility aside and do things they way they should have been done in the first place. But that doesn't mean that we can't continue to let Struts 1.x evolve closer and closer to what we envision for Struts 2.x.
So, IMHO, 2.x is not about versioning or platforms. It's about starting a new codebase and using all the lessons we have learned (and are still learning) from Struts 1.x, to building a better framework, test by test.
To put it in Jakarta terms, Struts 2.x is a revolution.
-Ted.
Kent Sølvsten Rasmussen wrote:
Regarding the required environment for using Struts: The servlet 2.3 spec is now 2 years old. There seem to be agreement, that it is still too early to switch to that platform.
There also seem to be agreement, that the required platform for Struts 1.x should be servlet 2.2/JSP1.1.
If the Servlet 2.4/JSP2.0 is not yet finalized, when will it be possible to use this as a minimum requirement for trus? 3 years from now?
The corollary of this will be, that if JSP2.0 /JSF should be the required platform for Struts 2.x, then it will be necessary to stick with Struts 1.x/Servlet2.2/JSP1.1 for another approximately 3 years.
IMO this would be a very bad idea. Wouldn't it be better to switch the versioning to 2.x, maybe next summer, and then switch to Servlet2.3/JSP1.2? This should leave space for a couple af "cleanup" releases in between.
Kent
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
