I've finally had a chance to spend a little time looking at this, and it's *very* cool.
Regarding backward compatibility, I tried running a large, complicated Struts 1.0 app, complete with customisations of ActionServlet and friends, on top of the latest nightly build, and saw no problems at all. It worked flawlessly. Awesome, Craig! One area that we might give more thought to is that of message resources. In both Struts 1.0.x and the latest code, the apparent assumption is that each application has a single source of message resources. (Alternatively, it is assumed that any other message resources are handled independently of Struts.) In practise, that is not always the case. Each application may have multiple sets of message resources, one of which would typically be the default. Since the DTD now includes support for (default) message resources, how about expanding that capability to allow for the definition of multiple message resources per application, where each non-default resource would have an identifier (key) associated with it? -- Martin Cooper ----- Original Message ----- From: "Craig R. McClanahan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, January 12, 2002 4:52 PM Subject: The BIG Check-In for Multi-App Support > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
