OK, I think I've got it working now -- the support for multiple Struts
sub-applications in a single web-app, that is.

While I'm writing up some documentation for it, here's the key points that
will help you experiment with it:

* All of the configuration information about a sub-app is stored
  in the ApplicationConfig object, including a bunch of stuff that
  used to be set with init parameters on the controller servlet.

* A multi-app environment still runs from a single instance of the
  controller servlet, but you can have multiple struts-config.xml
  files -- one per sub-application.

* The sub-application that applies to a particular request is based
  on matching an "application prefix" at the beginning of the
  context-relative URI (similar to the way that a servlet container
  chooses the web app to run based on the context path prefix of the
  request URI.

* Like a servlet container, there is the notion of a "default"
  sub-application that is used to process requests not assigned to
  any sub-applicaiton.  The prefix for this application is ""
  (i.e. the empty string).

* All of the "context relative" values in struts-config.xml are now
  "application-relative" instead -- in other words, the request URI
  equals "context path" + "application prefix" + "local value".  This
  works even for the default sub-application, because its prefix is
  a zero-length string.

* A primary design goal is that the "struts-config.xml" for an existing
  Struts applicaiton can be used as a sub-application with no changes.
  Failure of this to work should be considered a bug in the current
  implementation, and needs to be fixed.

* In addition to its other duties, the controller servlet creates
  two request attributes for all requests that flow through the

    Action.APPLICATION_KEY    Will contain the ApplicationConfig
                              instance for the sub-applcation that
                              is selected by the current request URI.

    Action.MESSAGES_KEY       Will contain the MessageResources
                              instance for the sub-applcation that
                              is selected by the current request URI.

* WARNING:  If you want to use your existing Struts application as a
  sub-application, then *ALL* of the requests must flow through the
  controller servlet -- no direct linking to pages -- in order for the
  above request attributes to always be set.  In a servlet 2.3
  environment, we'd be able to avoid worrying about this by using
  a filter, but that doesn't help under servlet 2.2.

* A known issue is that sub-apps won't work for path-mapped actions --
  only extension mapped at the moment.  I believe this can be fixed, but
  wanted to focus on getting the basics right first.

As a quick example of the new approach, assume you have three sub-apps:
  main - Main menu and such (this is the default subapp)
  catalog - The shopping portion of a shopping site - prefix "/catalog"
  checkout - The checkout portion of a shopping site - prefix "/checkout"

You would configure the sub-applicaitons in their own struts-config files,
and tell the controller servlet about them like this:



    <!-- The default sub-application -->

    <!-- The catalog sub-application -->
      <param-name>config/catalog</param-name> <-- Includes prefix! -->

    <!-- The checkout sub-application -->
      <param-name>config/checkout</param-name> <-- Includes prefix! -->

    ... other global parameters ...


In such an environment, you might have context-relative request URIs like:

  /index.jsp              Main menu of the entire site
  /logon.do               Log on action (default subapp)

  /catalog/index.jsp      Main menu of the product catalog
  /catalog/addItem.do     Add an item to the shopping cart

  /checkout/index.jsp     Beginning of the "check out" area
  /checkout/checkVisa.do  Check the entered VISA credit card number

Application Development Issues:

* As stated above, I tried to maximize backwards compatibility.  The
  following points are things I know about that might impact porting
  of existing Struts apps into being usable in a multi-sub-app
  environment as a sub-application (no change should be required to
  continue use as the "default" sub-app).

* Applications that are calling Action.getResources() should be modified
  to call Action.getResources(HttpServletRequest) instead.  This allows
  you to pick up the message resources that are unique to this
  sub-application.  Otherwise, the message resources for the default
  sub-app will be used.

* Applications that depend on the ActionFormBeans, ActionForwards, or
  ActionMappings servlet context attributes should be modified to
  get the information they need from the ApplicationConfig object instead.

* Applications that subclass ActionServlet will most likely need to be
  modified because of the refactoring to create RequestProcessor.  It
  should be straightforward to subclass the request processor class

Let's get this new code wrinkled out in the short term so that we can move
towards a 1.1 release as well as the 1.0.1 that was just created.


To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to