struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "ComposableRequestProcessor" by JoeGermuska
Date Wed, 03 Aug 2005 13:14:29 GMT
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:

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

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

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:
For additional commands, e-mail:

View raw message