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]>