The following is the bulk of a message posted to the Struts Developer's mailing list by Ted Husted. It provides a great historical context for the use of Commons Chain in the implementation of the new ComposableRequestProcessor class in Struts 1.3.
Struts 1.0
In Struts 1.0, requests were processed using a lump of code in ActionServlet. To keep it organized, the code was subdivided in a series of methods. Unsurprisingly, each method in the series had a coherent task and was named after its task.
Struts 1.1.x - 1.2.x
In Struts 1.1, we pulled out that lump of code and turned it into a first class object called the RequestProcessor. The original methods remained mainly the same, but now they were methods in a coherent object, rather than a set of related methods in a larger object.
Since it was a first-class object, we could subclass this new request processor, and plug in a new one, without touching the Servlet. (Users do not like to subclass ActionServlet.)
We were also able to use a different request processor for each module, if need be.
The problem is that it was still an all-or-nothing object. Extensions like Tile and Workflow both needed to subclass the RequestProcessor in different ways for their own reasons.
Struts 1.3.x
For Struts 1.3, we turned the 1.1 request processor methods into Commands. Rather than subclassing a monolithic object, we could now just replace Commands. We could also insert or remove Commands, if needed, to extend or streamline the request processing gauntlet.
Refactoring the RequestProcessor for Chain of Responsibility (CoR) is about extending the request processing cycle using Commons Chain. It's been a straight-line refactoring since the beginning. I don't believe anyone is trying to follow a particular pattern. We are just trying to provide a flexible approach to extend the request processing cycle.
Meanwhile, users are forever trying to "chain" Actions. Since most teams do not have a coherent business application framework of their own, they tend to piggyback one on Struts. The input and outputs to their business logic become embedded in Actions, and so they want to chain a "copy" and a "delete" to do a "move".
Another use of Commons Chain is that people can use it as the base of their own business application framework (and stop misusing Struts Actions).
The idea behind CoR and Struts Chain/Commons Chain is to solve both of these problems:
- A flexible processing layer for business applications
- An extensible request processor for Struts
The refactoring of the request processor is a proof-of-concept for CoR. The request processing gauntlet is the "business logic" of the Struts framework. It's also a hoary example of some very nasty business logic. IMHO, if we can do the Struts request processor in CoR, we can do anything in CoR
Yes, Struts Chain is a challenging application for CoR, and the implementation is not as slick as we might like. But, challenge is a good thing. And, I'm sure as more of us gain experience using CoR in other contexts, we'll devise more elegant solutions. The great thing about CoR is that it's easy to refactor.
I'm using CoR in my own applications, and it's working quite well. I hope to start reapplying some of that experience to Struts Chain, and I'm sure others will too.
Here is a link to Ted's message in the archives:
http://marc.theaimsgroup.com/?l=struts-dev&m=111097810923548&w=2
Other links:
http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains.html
http://www.onjava.com/pub/a/onjava/2005/03/02/commonchains2.html