On Thu, 16 Dec 2004 21:47:53 -0800, Don Brown <[EMAIL PROTECTED]> wrote: > Who is working on bringing Struts chain into Struts core? If no one, I > wouldn't mind doing the integration.
I've been wondering the same thing. I have not done anything myself yet, so I'd be happy for you to take this on. ;-) > I'm thinking about using the ComposableRequestProcessor to keep as much > backwards compatibility as possible. The changes I'm proposing by layer: > > web.xml > - A "chainConfig" parameter to override default catalog. If none > specified, a default chain config will be loaded from the Struts jar. > - A "chainCommand" parameter to specify the command to execute if none > specified in modules (optional) I'm probably misunderstanding something, but ComposableRequestProcessor uses two context initialisation params for these already. Those names and default values seem fine to me. > struts-config.xml > - The default request processor class would now be > ComposableRequestProcessor, but the legacy ones would still be available > (deprecated) +1. One thing that I'm a little confused about, though, is that the new request processor is (currently) in a package that includes 'legacy'. Anyone know why that is? > - The controller would have additional optional attributes: > - "chainConfig" - path of chain config to override default chain > catalog. Cannot be used if "catalog" is specified. Why would we need this, in addition to the catalog (below)? > - "catalog" - name of servlet context attribute to locate catalog > for this module. Cannot be used of "chainConfig" is used. Shouldn't this just be the catalog name, now that Chain has named catalogs? > - "command" - name of command to execute. Overrides default chain > command name. Do the above controller config attributes override the web.xml ones, or, if not, how do they inter-relate? > - Remove the need for the chain plugin Yup. If any of the above are stupid questions, my excuse is that I'm really tired, and probably shouldn't be replying tonight at all... ;-) > Of course, if someone is already doing the integration, ignore this. > Otherwise, comments appreciated. I'll target the integration Sunday or > Monday if I don't hear different. Sounds great! -- Martin Cooper > > Don > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
