Date: 2004-10-26T06:01:32 Editor: JoeGermuska <[EMAIL PROTECTED]> Wiki: Apache Struts Wiki Page: RequestProcessor URL: http://wiki.apache.org/struts/RequestProcessor
no comment Change Log: ------------------------------------------------------------------------------ @@ -2,6 +2,12 @@ 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. +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. + +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. + +In the meantime, if you are interested in extending org.apache.struts.action.RequestProcessor, some historical information is retained below: + A simple example of a custom RequestProcessor is: {{{ @@ -22,22 +28,3 @@ }}} See the [http://jakarta.apache.org/struts/dtds/struts-config_1_2.dtd struts-config.xml DTD] for the complete list of attributes accepted by the controller element. - ----- - -Has anyone considered a mechanism to make a composite RequestProcessor? It seems like the biggest obstacle is the struts-config DTD. I think you could get there by extending ControllerConfig and setting properties on it, and making sure that your ControllerConfig and your RequestProcessor could see each other. ----- -This would be an awesome feature. Currently we are looking to incorporate three different RequestProcessors (TilesRequestProcessor,BC4JRequestProcessor,WorkflowRequestProcessor) and the only solution is to take all the sources and modify them into one RequestProcessor. It would be great if I could add them all together without modifying the third-party source code. ----- -[http://marc.theaimsgroup.com/?l=struts-dev&m=105415755227385&w=2 This discussion] ensued on the StrutsDevMailingList, and the conclusion seems to be that there should be a RequestProcessor interface, and that the current concrete class should implement the interface. I have created [http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20356 RFE 20356 in bugzilla]. - -=== Implementation Ideas === -This wiki doesn't seem to support "strike-through" formatting, so I'll just note that this earlier statement: -{{{ From what I take from the discussion, demand for composition in a configuration - file is not high. It may be that all people want is a single interface exactly like the - current implementation class, and they'll do all the work of composing by - instantiating other request processor classes as needed behind the interface. }}} -is less clearly true right now. The discussion on the list seems relatively split between an single-interface solution vs a solution that supports external configuration of a chain of processors. In the interest of organization, I'm spawning two sub-pages for the alternate views: - - * /SingleInterface - * /Composable --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
