In my opinion it is enough to go without chaining support.
<snip> 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. </snip>
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 chain
of implementors? )
btw: Since the processXXX implementation classes for those overridden partsI 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.
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 SubRequestProcessor,
or are there drawbacks to this that I havent spotted?
--- Matthias
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
