Commons-chain is not intended to solve that debate topic originally. Last year, people found when they have two RequestProcessor(s), say A and B, if they need to design a new RequestProcessor C that has methods from both A and B, the best they can do is to let C extend one of them, say A, and then copy the methods (possibly line by line) from B. So a configurable RequestProcessor is somehow needed to reuse portions of several RequestProcessor(s). This is what commons-chain is intended to solve initially.
The composable request processor is what finally got Craig to "scratch the itch", but he's been mentioning the Chain of Responsibility pattern for some time, in several contexts (so to speak).
I don't think it's fair to say Commons-Chain is intended to solve any specific Struts issue. The request processor brought the work to a head, but Chain speaks to the need for a business layer framework. The RequestProcessor is an example of where Struts needs to utilize what amounts to business logic. The rules we want the request processor to follow are not uniform and subject to a RFP, but may differ from application to application. In other words, we want to create arbitrary request processors -- and "arbitrary" often indicates that some flavor of business logic is in play. =:)
It's true that the RequestProcessor is an important proof of concept, but, it's just the beginning. IMHO, Chain is intended to provide core utility that many business layer implementations share, which happens to include the request processor implementation. Another likely candidate in Struts space would be chaining validation commands.
-Ted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
