[Struts Wiki] Update of "RequestProcessor" by MichaelJouravlev

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.

The following page has been changed by MichaelJouravlev:
http://wiki.apache.org/struts/RequestProcessor

------------------------------------------------------------------------------
- Package: org.apache.struts.action
+ In Struts 1.1-1.2.x RequestProcessor contains the processing logic that the Struts controller servlet performs as it receives each servlet request from the container.  You can customize the request processing behavior by subclassing this class and overriding the method(s) whose behavior you are interested in changing. 
  
- RequestProcessor contains the processing logic that the Struts controller servlet performs as it receives each servlet request from the container.  You can customize the request processing behavior by subclassing this class and overriding the method(s) whose behavior you are interested in changing.
+ Therefore a new new request processor can  be plugged in without touching the Servlet. (Users did not like to subclass ActionServlet.) RequestProcessor also made possible to use a different request processor for each module, if needed.
  
- Experience has shown that requiring people to extend a single RequestProcessor class to customize the processing flow is cumbersome, and is particularly challenging when one wants to integrate custom processing from more than one source, because of Java's single inheritance limitations.  There was [http://marc.theaimsgroup.com/?l=struts-dev&m=105415755227385&w=2 some discussion] about whether Struts should move towards a single interface for Request Processor, behind which multiple services could be integrated, or whether a composable request processor would be more useful.
+ The problem is that RequestProcessor class was still an all-or-nothing object. Extensions like Tiles and Workflow both needed to subclass the RequestProcessor in different ways for their own reasons.
+ 
+ Experience has shown that requiring people to extend a single RequestProcessor class to customize the processing flow is cumbersome, and is particularly challenging when one wants to integrate custom processing from more than one source, because of Java's single inheritance limitations.
+ 
+ This lead to development of ComposableRequestProcessor, which is shipped with Struts 1.3.x.
+ 
+ 
+ 
+ === todo ===
+ 
+ There was [http://marc.theaimsgroup.com/?l=struts-dev&m=105415755227385&w=2 some discussion] about whether Struts should move towards a single interface for Request Processor, behind which multiple services could be integrated, or whether a composable request processor would be more useful.
  
  Since then, the StrutsChain project has been developed and added to the contrib branch of Struts source repository.  It implements the composable model, and has gotten considerable interest from other developers.  In fact, much developer list discussion indicates that it will eventually replace the existing RequestProcessor.  See the StrutsChain page for details.