[Apache Struts Wiki] Updated: StrutsChain

[de...@struts.apache.org]

   Date: 2005-01-10T08:54:26
   Editor: JoeGermuska
   Wiki: Apache Struts Wiki
   Page: StrutsChain
   URL: http://wiki.apache.org/struts/StrutsChain

   Elaborate about current chain state; provide links to non-CVS builds

Change Log:

------------------------------------------------------------------------------
@@ -1,3 +1,28 @@
-'''struts-chain''' is a package designed to open up the RequestProcessor chain to more flexible extension.  It is currently in the [http://svn.apache.org/viewcvs.cgi/struts/trunk/contrib/struts-chain/ "contrib"] subdirectory of the SVN repository.  It is not yet being distributed in binary form.
+'''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.
 
-Struts developers have expressed interest in making the struts-chain request processor the default processor in a near-future version of Struts.  This will require a full 1.0 release of the CommonsChain library upon which struts-chain is built, and much documentation.  This page in the wiki may serve as a good scratch pad for struts-chain documentation while people are getting used to it.
+Some of the changes for this are fairly wide ranging, so it is risky to commit them to CVS until more is accomplished.  We'll use this page to discuss implementation plans and questions, and to link to interim distributions.
+
+=== What's in CVS ===
+The code committed to CVS is substantially similar to 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 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.
+
+=== What's under development ===
+JoeGermuska is working on implementing an ActionContext interface which clarifies the API with which Commands can interact with Struts.  This class provides typesafe properties for all of the configuration values which are used by more than one command, and provides analogs for all of the methods which are part of the base Action class.
+
+Code in the development builds includes a WrappingLookupCommand which creates a ServletActionContext class wrapping the current chain Context.  It might be worth brief debate about whether it's safe to wrap the current context, or if instead the command which launches the '''process-action''' chain should copy values into and out of the context.  The problem with the copying is that if users want to pass more values in, the copy process would have to be locally modified.  
+
+Another open question has to do with the current model where commands are separated into Abstract "web" classes and then concrete "servlet" subclasses.  This model was designed to allow for portlet or JSF subclass Commands which share the same Abstract base classes.  By warpping the initial Context in ActionContext, one can no longer cast to [http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/web/WebContext.html WebContext].  If we want to maintain the abstraction layer, then we need to choose a strategy.  
+
+The strategy currently in the distributions (below) is to implement a WebActionContext class which has the same API as WebContext (which is an abstract class, not an interface.)  I might be persuaded to simply move those properties into the base ActionContext, as they are basically just maps for the ApplicationScope, SessionScope, and RequestScope, all of which seem likely to exist in any Struts environment.  It might also help with a question I have in the ActionContextBase regarding the modelling of scopes without any implementations.  Perhaps they could be added as abstract methods and ActionContextBase made into an abstract class.
+
+
+=== Where can I get it? ===
+[http://www.apache.org/~germuska/struts-1.3.0-dev/ Non-CVS development builds] last updated 2005-01-10
+
+The archives available above are to output from a '''maven dist''' run against a local copy.  These changes are not in CVS and are not meant for production use.  They are provided to get feedback from interested parties.  
+
+This latest build has never been executed.  It compiles, but there's no guarantee that the chain config is right or that the implementation classes are doing the right things.  Valiant testers are welcome!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org