Differences between revisions 7 and 8
Revision 7 as of 2005-03-22 05:48:36
Size: 4707
Editor: anonymous
Comment: missing edit-log entry for this revision
Revision 8 as of 2009-09-20 23:11:43
Size: 4711
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 6: Line 6:
The code committed to [http://struts.apache.org/acquiring.html#SourceCode SVN] has started to diverge from the old standalone struts-chain project. Here is a summary of the changes:
 * Struts has been updated so that the ActionServlet initializes chain catalogs using the value of the init parameter '''chainConfig''', which should consist of one or more paths to XML files which can be processed by the standard Chain [http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/config/ConfigParser.html ConfigParser]. The paths may be either classpath resources or servlet context resources; the initialization process has methods for checking in both places without additional configuration. This and the changes to the RequestProcessor obsolete the CatalogConfiguratorPlugIn. If no '''chainConfig''' parameter is specified, then Struts defaults to looking for '''org/apache/struts/chain/chain-config.xml''' which is included in struts.jar. If any '''chainConfig''' value is specified, then if you also want Struts to use the default config, you must include it in the list of config files.
The code committed to [[http://struts.apache.org/acquiring.html#SourceCode|SVN]] has started to diverge from the old standalone struts-chain project. Here is a summary of the changes:
 * Struts has been updated so that the ActionServlet initializes chain catalogs using the value of the init parameter '''chainConfig''', which should consist of one or more paths to XML files which can be processed by the standard Chain [[http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/config/ConfigParser.html|ConfigParser]]. The paths may be either classpath resources or servlet context resources; the initialization process has methods for checking in both places without additional configuration. This and the changes to the RequestProcessor obsolete the CatalogConfiguratorPlugIn. If no '''chainConfig''' parameter is specified, then Struts defaults to looking for '''org/apache/struts/chain/chain-config.xml''' which is included in struts.jar. If any '''chainConfig''' value is specified, then if you also want Struts to use the default config, you must include it in the list of config files.

struts-chain was a package designed to open up the RequestProcessor chain to more flexible extension. It was moved into the Struts Core repository and work is well under way to making Struts 1.3.x default to using ComposableRequestProcessor and commons-chain commands to services HTTP requests.

Some of the changes for this are fairly wide ranging, so it is risky to commit them to SVN until more is accomplished. We'll use this page to discuss implementation plans and questions, and to link to interim distributions.

What's in SVN

The code committed to SVN has started to diverge from the old standalone struts-chain project. Here is a summary of the changes:

  • Struts has been updated so that the ActionServlet initializes chain catalogs using the value of the init parameter chainConfig, which should consist of one or more paths to XML files which can be processed by the standard Chain ConfigParser. The paths may be either classpath resources or servlet context resources; the initialization process has methods for checking in both places without additional configuration. This and the changes to the RequestProcessor obsolete the CatalogConfiguratorPlugIn. If no chainConfig parameter is specified, then Struts defaults to looking for org/apache/struts/chain/chain-config.xml which is included in struts.jar. If any chainConfig value is specified, then if you also want Struts to use the default config, you must include it in the list of config files.

  • Struts has been adjusted to use the ComposableRequestProcessor by default. You may switch back to the original RequestProcessor by specifying it as the processorClass in the <controller> element of your struts-config file. By default, the ComposableRequestProcessor begins processing with the servlet-complete command in the struts catalog. This may be changed by specifying the catalog and command attributes in the <controller> element of your struts-config file.

  • You can now specify a chain command to be executed as part of any <action> element in a struts-config file. Simply include values for the catalog and command attributes. If a command is configured, then it will be executed before (or instead of) any action, forward, or include which is also configured in the <action> element. This effectively obsoletes the ChainAction class. Note that this functionality is only implemented in a chain command; if you revert to using the original RequestProcessor, these configuration values will be ignored.

  • The default chain has been reconfigured to be a bit simpler, and most importantly, to split processing into two sub-chains. These chains are "process-action" and "process-view", and while the default "process-view" chain is only "PerformForward", this seems to be a cleaner arrangement. It will also allow a command to terminate action processing early (such as when a form is determined to be invalid), saving later actions from the trouble of re-checking to see if the form is valid.

  • As part of this reconfiguration, the "process-action" chain is provided with an instance of a new interface, ActionContext. This allows the commands to use typesafe methods to extract values like the ActionForm and ActionConfig rather than having to rely upon

String constants and casting. This is something which still merits user feedback, as there are some questions about the best time and manner to construct an ActionContext, whether it should also be passed to the "process-view" chain, and whether it should even be made available outside of Struts in a final view handling technology like JSP or Velocity.

What's in Development

At this time, there are no major initiatives; it would be good to get folks testing what's in SVN and flushing out bugs. Near-term tasks might be to adapt more of Struts to use the ActionContext API, helping to get out of direct dependencies on the Servlet API. Other suggestions are welcome, either on this page, or on the Developer mailing list.

Where can I get it?

As of the nightly builds for 20050208, there is no major functionality which isn't readily available. You can get this code from SVN or from the nightly builds archives: see http://struts.apache.org/acquiring.html

Valiant testers are welcome! If you are interested, it would probably be good to join the developer's mailing list: http://struts.apache.org/using.html#Lists

StrutsChain (last edited 2009-09-20 23:11:43 by localhost)