Comments inline...
Joe Germuska wrote:
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.
Sounds good. I would take it a step further, and, if no init parameter, look for the chain config as "/chain-config.xml", making it possible to provide an intelligent default. We could then, take your idea in #3, and bundle our own "/chain-config.xml" inside Struts. Since it would be on the classpath, it could still be easily overridden by creating a chain-config.xml in the servlet context w/o adding any configuration to web.xml.
[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.
Works for me.
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.
I like for former. We continue to use RequestProcessor, but deprecate it, and make LegacyRequestProcessor the default. This allows Struts extensions to make the transition easier.
Don
[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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
