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
controller:
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:
<servlet>
<servlet-name>action</servlet-name>
<servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
<!-- The default sub-application -->
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/struts-config-main.xml</param-value>
</init-param>
<!-- The catalog sub-application -->
<init-param>
<param-name>config/catalog</param-name> <-- Includes prefix! -->
<param-value>/WEB-INF/struts-config-catalog.xml</param-value>
</init-param>
<!-- The checkout sub-application -->
<init-param>
<param-name>config/checkout</param-name> <-- Includes prefix! -->
<param-value>/WEB-INF/struts-config-checkout.xml</param-value>
</init-param>
... other global parameters ...
</servlet>
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
instead.
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.
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
