Martin Cooper wrote: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 haven't made the time to do anything. I was hoping to have some this weekend, but if you're ready to plunge ahead, I don't want to hold things up. If you think there's a good way to split tasks up, let me know. Below I've interspersed what I was thinking about doing.
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.
The idea of these in web.xml is the ability to specify a custom chainConfig that would be used as the default for all modules; same with the command name. My goal would be to make it possible to use an existing Struts 1.1/1.2 app without any changes. To meet this goal, all these configuration options are optional and defaults will be used if necessary.
Earlier, we had discussed using one init parameter in web.xml as a list of chain-config files, each of which would be sought first in the servlet context and then on the classpath, each of which would be processed using the default chain digester that adds catalogs to the pool.
I would suggest skipping the chainConfig and chainCommand parameters in the web.xml in favor of explicitly setting them in each controller. Too many config options can be more trouble than they are worth.
The discussion of how to configure the Controller or the RequestProcessor touched off a lot of talk earlier on struts-dev, but I'd be happy to settle for two properties on ControllerConfig just to move forward.
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?
I don't know, but I think we should move it out to o.a.s.chain.ComposableRequestProcessor.
- The controller would have additional optional attributes:
I think the controller should simply have optional command and catalog attributes which would be used like this:
CatalogFactory.getCatalog(catalog).getCommand(command)
if no catalog is specified, the "default" catalog is retrieved with getCatalog(). If no command is specified, then these default values would be used:
catalog = struts
command = servlet-complete
If catalog were specified without a command, an exception would be thrown.
I am still inclined to package most of what is now struts-chain separately from the core. This may be part of why I haven't moved as quickly. Here are all the classes in struts-chain:
org.apache.struts.chain.legacy.CatalogConfiguratorPlugIn becomes obsolete
org.apache.struts.chain.legacy.TilesPlugin
can be made obsolete if we remove the check in the base TilesPlugin which insists on a specific request processor. I don't see any reason not to do that.
org.apache.struts.chain.legacy.ComposableRequestProcessor org.apache.struts.chain.legacy.DispatchAction org.apache.struts.chain.legacy.ChainAction Move these three to core and up to o.a.s.chain
org.apache.struts.chain.AbstractAuthorizeAction org.apache.struts.chain.AbstractExceptionHandler org.apache.struts.chain.AbstractExecuteAction org.apache.struts.chain.AbstractPerformForward org.apache.struts.chain.AbstractPerformInclude org.apache.struts.chain.AbstractPopulateActionForm org.apache.struts.chain.AbstractRequestNoCache org.apache.struts.chain.AbstractSelectAction org.apache.struts.chain.AbstractSelectForward org.apache.struts.chain.AbstractSelectInput org.apache.struts.chain.AbstractSelectLocale org.apache.struts.chain.AbstractSelectModule org.apache.struts.chain.AbstractSetContentType org.apache.struts.chain.AbstractValidateActionForm org.apache.struts.chain.Constants org.apache.struts.chain.CreateAction org.apache.struts.chain.CreateActionForm org.apache.struts.chain.ExceptionCatcher org.apache.struts.chain.SelectInclude org.apache.struts.chain.UnauthorizedActionException org.apache.struts.chain.util.ClassUtils org.apache.struts.chain.servlet.AuthorizeAction org.apache.struts.chain.servlet.ExceptionHandler org.apache.struts.chain.servlet.ExecuteAction org.apache.struts.chain.servlet.PerformForward org.apache.struts.chain.servlet.PerformInclude org.apache.struts.chain.servlet.PopulateActionForm org.apache.struts.chain.servlet.RequestNoCache org.apache.struts.chain.servlet.SelectAction org.apache.struts.chain.servlet.SelectForward org.apache.struts.chain.servlet.SelectInput org.apache.struts.chain.servlet.SelectLocale org.apache.struts.chain.servlet.SelectModule org.apache.struts.chain.servlet.SetContentType org.apache.struts.chain.servlet.TilesPreProcessor org.apache.struts.chain.servlet.ValidateActionForm
Move all of these to a Struts TLP like "legacy-chain" or perhaps just "struts-chain". I wasn't involved in the initial implementation, but I don't think these are something that belongs in the core. They work fine, but I think the Abstract classes are over-engineered. Also, I think we should move towards actions which operate on a StrutsContext or ActionContext rather than having such a highly configurable mechanism for looking up context-relevant objects (like ActionMapping and ActionForward). I think the config for setting context keys for each important object is an example of over abstraction which make these harder to understand. This TLP would also include a default chain-config which works with this set of classes in the JAR.
Is there a compelling reason to put specific command implementations in the core? I kind of feel like it would be nice to feel less bound to them.
If we do this repackaging, perhaps it would make sense to change the Java package for these classes. I don't have a strong opinion.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
