I'd say that requiring Servlet 2.3 / 1.2 would justify a major version increase, and so maybe we should start whiteboarding Struts 2.0 to use a Filter instead of a Servlet for the controller. Among others, one thing that just came up under the "would've and "should've" heading was handling exceptions at the controller level. In the heat of development, a few of the attribute and class names ended up being a little confusing, like "validate" in the web.xml having nothing to do with the validate method ;-)
My suggestion would be that we put together a design and requirements document for Struts 2.0. Work on the Struts 1.x branch would continue, and would be used to concept-test any new functionality. For example, we can't change the signature to Action.perform in 1.x, but we can easily provide a base Action class to handle mapped exceptions. Where attribute names or class signatures change, we might start looking at a upgrade program from the beginning that would ease migration later. I strongly believe that the architecture and approach is sound, but with the benefit of 20/20 hindsight, there are a number of minor details that should be changed. So to start a Struts 2.0 list + Require Servlet 2.3 / JSP 1.2 + Controller as Filter + Tag extensions as add-ons to JSPTL + PropertyEditor Support + Declarative exceptions handled by Controller + Multiple controllers, multiple configurations + Direct support for Commons Workflow + Direct support for chaining Actions without a forward or redirect + More entry points in class methods for subclassing + Reconsider all class and attribute names, to make the heirarchy more accessible to newcomers. Another thing that people often up is populating multiple ActionForms. I'm not sure what the use case here is, but we should determine if that's something we should be doing, or if it is a documentation issue. Backing an ActionForm with a map to create "dynamic properties" finally seems to be addressed with the latest BeanUtils syntax, but we should probably visit that issue as well. Perhaps a standard base class so that we can better document the approach. Again, I would suggest that, where practical, we first retrofit Struts 1.x with any new functionality proposed for Struts 2.x, as a proof of concept. In many cases, the Struts 2.x functionality would be superior (as in the case of declarative exceptions), but it's important that we leverage the existing code base, and get the features "out there" so developers can bring back their experiences back to the table. This will also help keep us from putting off to 2.0 things we could actually do today ;-) -Ted. "Craig R. McClanahan" wrote: > > I think the question being asked here is "will the Struts controller > functionality (currently implemented in ActionServlet) be implemented as a > javax.servlet.Filter from the Servlet 2.3 API?" It's a pretty interesting > question. > > Had the Servlet 2.3 API been available when Struts was originally > designed, it's a pretty sure bet that I would have implemented the > controller as a Filter instead of as a Servlet. This would have made > possible some interesting approaches to using the Struts controller in > front of (or in front of part of) existing applications that are being > migrated to Struts, as well as the "multiple controllers per webapp" > paradigm that we are currently discussing. > > However, that's not what happened. Struts is currently based on the > facilities of Servlet 2.2 and JSP 1.1, because that provides support on > the very broad range of application servers that support these APIs. I > feel that we ultimately want to migrate to Servlet 2.3 / JSP 1.2 to take > advantage of the new facilities -- the quesion is, when? > > We certainly need to continue to support the ability to run Struts based > applications on a Servlet 2.2 / JSP 1.1 platform for the forseeable > future. However, there are many compelling features of the next > generation APIs that are worth supporting. I'd like to see us explore > taking advantage of those capabilities by offering enhanced (or > alternative) implementations of the basic Struts controller functionality > based on the new APIs. > > What do the other developers think? Are there enough Servlet 2.3 / JSP > 1.2 environments available (obviously, I will be using Tomcat 4 for this, > since I'm pretty intimiate with its internals :-) to make development > *and deployment* of Servlet 2.3 / JSP 1.2 based applications useful, or is > it still a little too early? > > Even if it's too early, we can start exploring those sorts of ideas so > that we're ready when the platforms are readily available. > > Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
