I think Martin said chain is in trunk.
I would assume that the nighly bulids would then have chain in there, and that it not be a separate download?
Chain is not yet in the core, but getting it there is something I'm interested in working on. It may also be just as well to wait a few days until commons-chain 1.0 is formally released. Meanwhile, I am still looking for more feedback on some of my questions. I'm restating/clarifying them below. Items two and three seem the most controversial.
[1] Chain initialization:
Pending any objection, I would remove the need for the ChainConfiguratorPlugIn and instead have the ActionServlet receive an init parameter, "chains" which would be one or more (comma-separated) paths to XML files. I would follow Don's recent changes so that each path would be tested first as a servlet resource, and, if that failed, as a classpath resource. If a URL were found in either source, it would be passed to o.a.s.chain.config.ConfigParser.parse(URL) If a URL were found in neither source, a ServletUnavailableException would be thrown.
[2] RequestProcessor Configuration:
In the current ChainConfiguratorPlugIn, the catalog name and initial command are settable with servlet init parameters. It seems to me that this should be a per-Module setting, and so I'd argue those should be properties on the RequestProcessor. This is not a high priority to me, but it seems more right.
To achieve this would require either adding yet more properties to ControllerConfig or, my preferred solution, allowing ControllerConfig to hold a reference to an actual RequestProcessor object which could be instantiated and configured by Digester. (Would this involve some ClassLoader issues? the Struts digester instance uses the contextClassLoader when it has been set, as does RequestUtils.applicationInstance(...) so perhaps not a great risk?) I guess the alternative would be a RequestProcessorConfig object that carried the properties -- but this is an example of where I would rather turn away from the config objects and towards something more IoC-like...
The other question here is simply whether to change the behavior of the class named RequestProcessor (probably copying the current behavior to a LegacyRequestProcessor) or rather to change the default class used to point to a new class which implements the Chain-based processing.
[3] Default Chain
Do we import all the classes in struts-chain into core? Or do we pack them as a jar and use them by reference? Based on our stated interest in reducing core dependencies on the Servlet API, I would argue for the first. If we did the first, I think it would be interesting (but low priority) to consider a mechanism for including the chain-config.xml in the JAR and having it be auto-discovered.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
