I've been working on adding support in Strecks
(http://strecks.sourceforge.net/) for the chained request processor,
that is, ComposableRequestProcessor. On the whole, the job has been
pretty straightforward. I have had to tweak a couple of the interfaces
so that they map one to one with Commons Chain command classes. The idea
is that you can still use the standard RequestProcessor, whether with
1.2 or 1.3. The idea is that you will still be able to use Strecks with
1.2. However, if you use 1.3, you can take advantage of the chained
request processor and enable Strecks simply by providing an alternative
commons chain configuration.
I have a couple of questions/thoughts/observations that have arisen:
- the chain configuration appears to apply across the application as a
whole rather than per module. This differs from the 1.2 request
processor which can be varied/subclassed on a per module basis. (Of
course, you can still subclass RequestProcessor on a per-module basis,
but the whole point of the chain is that you should not need to do that)
- the chain seems to be quite good at allowing you to vary the request
processing flow. It is more difficult to apply configuration or make
services accessible to groups of commands in the chain. One way I can
see to do this is by subclassing ComposableRequestProcessor (not that
old chestnut again), overriding init(ActionServlet,ModuleConfig), then
adding the relevant services to the chain context, using
getApplicationScope().put(...). Another way, apparently, would be to
load the configuration in the constructor or synchronized block of one
of the chain commands, then use getApplicationScope().put(). It would be
nice if you could configure chain commands using some form of dependency
injection, a la Spring, and allow these services to be added via the
chain config file. (I suppose I should be addressing this to the chain
developers mailing list, although I suspect that most of the chain
developers are on this list as well).
Also - when is Struts 1.3 expected to go GA?
Regards,
Phil Zoio
http://www.realsolve.co.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
