Quoting Martin Cooper <[EMAIL PROTECTED]>: > On Thu, 18 Dec 2003, Craig R. McClanahan wrote: > > > Quoting Vic Cekvenich <[EMAIL PROTECTED]>: > > > > > Craig R. McClanahan wrote: > > > > > > > > Regarding 2.x, an important consideration will be base technology > platforms > > > -- > > > > I'm in favor of using J2SE 1.4 and the relevant standards from J2EE > 1.4 > > > (i.e. > > > > Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the > > > > presentation technology, etc.). > > > > > > > > > > > > > JDK 1.4, yes. > > > > > > One popular? goal mentioned was: > > > "Get away from reliance on Servlet API" > > > > > > I like being on Tomcat 4. > > > What does it gain to be Tomcat 5 technically? > > > > For the portions of the framework that depend on Servlet 2.4, you get two > > modest > > but useful features: > > > > * Ability to execute filters on RequestDispatcher.include and > > RequestDispatcher.forward calls, which is not possible in 2.3. > > This gives you additional degrees of freedom in how you organize > > the processing logic of a framework like Struts -- for example, > > it would now be technically feasible to implement the controller > > as a filter instead of a servlet. > > It would certainly be technically feasible to do that, but are there > practical advantages to doing so? The only thing I can think of is that > it's easy to punt on a request and let something else (i.e. another filter > or a servlet) handle it, but I'm not sure why I would want to do that. Any > good examples? >
One of the things people have said they liked about using a chain to decompose RequestProcessor is that you could easily compose your own chains, adding your own custom processing stages and so on. You can do exactly the same thing with Filters by making each processXxx method its own filter, and using (say) the request attributes to play the role of the Context object in commons-chain. Filters have an additional capability if you're building a servlet-specific framework -- they can wrap the actual request and response objects that are passed on to the next filter in the chain, so you can implement some interesting things not directly possible with a chain based implementation -- such as caching or on-the-fly compression of the response. > -- > Martin Cooper > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
