struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "PILGRIM, Peter, FM" <>
Subject RE: composable RequestProcessor
Date Mon, 02 Jun 2003 14:04:36 GMT
> -----Original Message-----
> From: Matthias Bauer []
> I will try to wrap up, what we are up against: The current 
> RequestProcessor implementation does not support chains of request 
> processors. So the developer has to decide which request processor to 
> choose. This brings him into a dilemma, if he wants to use two struts 
> extensions that both implement their own request processor, e. g. 
> ExtOneRequestProcessor and ExtTwoRequestProcessor. Only if one of the 
> two extensions provides a ExtOneExtTwoRequestProcessor that  
> integrates 
> the functionality of both of them, the two extensions can be 
> used together.
> For two extensions being around this can be accomplished. But 
> as soon as 
> the number of extensions grows beyond 2 (which has already happened) 
> this is fairly impossible. Providing a RequestProcessor 
> interface does 
> not really relieve the situation. Even though it will  make 
> it easier to 
> compose a request processor from other request processors, a subclass 
> for each possible combination of request processors must be 
> implemented.
> Thus, by now I believe the request processor architecture should be 
> changed more fundamentally to allow a more selective change of 
> functionality. Maybe they should be working more like servlet 
> filters, 
> so they can be chained?

I disagree here. There are far too many methods in the RequestProcessor
class to delegate. The question is which method of which controller
do you call, and in what order? 

My XML config approach tried to address this, but I am in design flaw.
The cost of making a generic XML approach compared to getting your
finger out and coding the aggregated methods way exceeds the effort.

The controllers that I have seem only subclass one or two methods
of the RequestProcessor class itself. Compared your approach
and the StrutsChaining guys and realise there are only intercepting
the ubiquitous ``execute'' Command method, and not all ten 
`process*Whatever()' methods.


Peter Pilgrim,
Struts/J2EE Consultant, RBoS FM, Risk IT
Tel: +44 (0)207-375-4923

      Visit our Internet site at

This e-mail is intended only for the addressee named above.
As this e-mail may contain confidential or privileged information,
if you are not the named addressee, you are not authorised to
retain, read, copy or disseminate this message or any part of it.
The Royal Bank of Scotland plc is registered in Scotland No 90312
Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB 
Regulated by the Financial Services Authority

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message