Joe,
Yes, I seem to pick up this issue every two weeks, and coming back to it
again.
After reading your answers again and delving into the source code, I
think I understand the mechanism pretty well. The problem for me is that
Commons Chain does not seem to have an override capability.
A couple of examples:
- if you want to use Tiles, you need to either a) uncomment the tiles
entry in the default chain config or b) use the replacement tiles chain
config file. IMO, you should be able to add Tiles support by specifying
an additional config file containing only the entries needed to support
tiles. The main config file should be designed to allow entries to be
easily overridden or enhanced. A similar mechanism works very well in
Spring - the way you replace/override existing beans using bean entries
with the same name in a subsequent config file.
- if you want to have different chains per module, you'd seem need a
lot of repeating definitions. I think the result could be pretty
verbose, again because of the apparent absence of an override mechanism.
Also, I do think you would be better off having different sets of chain
instances per module (ie one per ComposableRequestProcessor instance).
The background of all this is that I'm trying to fine tune the way that
Strecks supports Struts 1.3.x (which is now present in Strecks 1.0 beta
3). I'm configuring 1.3 support entirely via chain commands, so it would
make a big difference if this was easy, especially in allowing for
different configurations per module.
The bigger question which is lurking in my mind is whether there is a
real actual (as against hypothetical) benefit to be gained from the 1.3
chain request processor. If the chain was easy to configure, it would be
a no-brainer, but if configuration is not easier, then the advantages
are much less clear.
Phil
Joe Germuska wrote:
At 9:07 AM +0100 6/30/06, Phil Zoio wrote:
Joe,
Could Struts 1.3 set up to have a separate chain per module?
Phil: I thought we discussed this two weeks ago. In short, the
answer is "yes". Looking back at what I wrote, perhaps I gave too
much detail at the wrong time. Here is the core of it:
>>> It is technically possible to change which command is looked up in
the catalogs and executed to process the request as part of the
>>> controller-config on per-module basis.
For context, Struts uses commons-chain code to instantiate a universe
of catalogs which contain commands. You'd use the <controller> to
specify the name of a catalog and the name of a command within that
catalog which is to be executed to process the request. Therefore,
you could specify different "bootstrap" commands for each controller
until you turn blue.
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
