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 JoeGermuska: http://wiki.apache.org/struts/ComposableRequestProcessor The comment on the change is: Brief introduction to CRP, plus mention a few open design ?'s New page: Beginning with Struts 1.3.0, the original RequestProcessor class has been extended in a way that substantially overhauls the way in which a Struts module processes an HTTP Request. Before this version of Struts, the RequestProcessor class implemented a variation of the Template pattern, in that it articulated a primary "process" method which called various protected methods in a reliable order. Users who wanted to alter the request processing lifecycle were advised to extend RequestProcessor and override one or more of those methods. This led to a very inflexible environment, where it was very difficult to synthesize a request processing chain from library code, because of the familiar problems with "single inheritance" in Java. With the introduction of the ComposableRequestProcessor class, every request is handed to a composable chain of commands, each of which can perform a small bit of the request processing. This is done by overriding the central "process" method, which means that earlier RequestProcessor classes which relied on that method's implementation to call other methods in a predictable fashion will no longer work. It should be extremely easy to extract that kind of behavior and put it into classes implementing the ActionCommand interface, while documenting for users how they should modify their chain configurations to insert these new commands in the right position in the chain so that any necessary context has been established. ---- A discussion on StrutsUpgradeNotes12to13 brought up the point that perhaps the responsibility for initializing the chains should be based in the ComposableRequestProcessor, where currently it is done by the ActionServlet. This generally makes sense, but a few things must be considered. First and more trivial, the initialization process relies on some simple resource-loading code which is difficult to extract from the ActionServlet. (Difficult, but certainly not impossible.) More fundamentally, though, the fact that one Struts application may have more than one ComposableRequestProcessor must be considered. The current chain initialization process leverages code from Commons Chain which populates a "global" (to a ClassLoader) CatalogFactory based on static methods. Multiple overlapping initialization processes might cause unexpected effects. It would probably be worth revisiting that initialization strategy anyway, because it does not cooperate well with a DependencyInjection approach. It might be better to have the chain assembled by a mechanism which could also inject dependencies like business service objects into various commands. This deserves more consideration. ---- Other notes on the ComposableRequestProcessor are welcomed! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
