struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: composable RequestProcessor
Date Tue, 03 Jun 2003 10:37:25 GMT
Yep. Having a look at the processXXX methods in the RP Id say that most
arent really amenable to chaining anyhow.
(One likely exception is the processPreprocess() hook, however if chaining
is required for this it could perhaps be done by an implementation of its
interface 'PreprocessProcessor' that has the logic to call multiple other
PreprocessProcessor implementations.)

Im guessing that for the configuration flexibility we need, we will want to
add more xml elements in struts-config as child elements of the controller
element that can provide the necessary info, Id prefer this to just having a
whole bunch of extra attribute directly hanging off the controller element.

-----Original Message-----
From: Matthias Bauer []
Sent: Tuesday, 3 June 2003 18:10
To: Struts Developers List
Subject: Re: composable RequestProcessor

>This driving request processor who selects the instances of the sub
>request processors should be the one who keeps the members. Every sub
>request processor must be allowed to modify these members. Therefore the
>driving request processor must pass a reference to himself to each
>method now (like in the above sample code). The members that are exposed
>(e. g. the action map)  must be accessible with getter methods then.
>This way of having the driving RequestProcessor be the one that implements
>process() and calls the other is probably the best way to go IMHO. The
>driving request processor will also itself implement all the various
>interfaces, and in the absence of a SubRequestProcessor implementing
>processXXX the RequestProcessor would call itself for processXXX. (Do we
>aditionally want certain SubRequestProcessors to provide support for a
>of implementors? )
In my opinion it is enough to go without chaining support.

>btw: Since the processXXX implementation classes for those overridden parts
>are instantiated at startup, rather then having the RequestProcessor pass a
>reference to itself each time it calls a SubRequestProcessor we could
>perhaps set the reference at instantiation time in each
>or are there drawbacks to this that I havent spotted?
I don't think there are any drawbacks. It will definitely make sense to
establish the references at startup time. This is also the approach I am
going in the workflow extension.

--- Matthias

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

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

View raw message