Thanks for addressing this much-desired feature. I have read the archives on this thread (last entry around 8.30am today) so hopefully I am not repeating anything here.
While this is a step in the right direction, I think it does not exploit the full potential of having multiple struts controllers. IMO, the most important requirement for supporting multiple controllers (sub-apps) is as follows. "Development and Deployment management: The underlying resources of a Struts app should be manageable and deployable by separate teams as a single web-app without requiring development or runtime inter-dependencies." The proposed approach addresses splitting of the struts-config.xml resource. But Struts being highly extensible can and does pull in other resources (for e.g., tiles-definition.xml, message resource bundles). In our project, we have also changed the Winterfeldt validation framework so the validation.xml is loaded via a controller servlet configuration parameter rather than being a separate servlet of its own. These other resources also need to be split up along the same lines as the struts-config.xml. In other words, the multiple controllers idea would be really powerful if the various Struts extensions and their underlying resources can also participate in it. If one follows that line of reasoning there are 2 options available. 1. Use the current approach but modify all extensions to take advantage of the concept of a "sub-app context". Lot of rework, I think. 2. Rethink the current approach in favor of something that is more like the Multi-Controller extension from Stoehr Sukachevin. Practically no rework for any of the extensions. There is an excellent e-mail thread titled "Multiple ActionServlet instances in a web app" on the struts-dev group from March 2001 that discusses the multiple servlet approach in great detail. The message at http://marc.theaimsgroup.com/?l=struts-dev&m=98525810803935&w=2 is probably of most interest. Although having multiple action servlet instances does require more memory, I think the ease of management for large projects more than compensates for this. "Craig R. McClanahan" wrote: > > One of the highly requested features for Struts has been the concept of > wanting to define multiple "applications" (or multiple "controllers") > within a single Struts-based web application. Implementing this feature > in the current controller servlet is pretty complicated, due to its > assumpations all over the code that there is only one controller. > > Recent discussions on the STRUTS-DEV list, some thought that Ted Husted > put in on the "ContextHelper" class recently checked in, and a little bit > of time (Sun is shut down this week, so I've got a little quality time to > put in on Struts) leads me to propose a way to accomplish the goals of > multiple applications, using a single controller servlet, in a way that > should remain backwards-compatible for current users (which is *always* a > very important consideration IMHO). > > The basic design would include the following elements: > > * Running multiple "applications" within a single web app will be > accomplished by defining each "application" to have a particular > prefix on the context relative path. Thus, a complete request > URI gets divided into: > > /{context-path}/{application-prefix}/{action-select-path} > > * When the controller processes an incoming request, it will parse > the request URI and try to match it to a particular "application > configuration" by matching against the application prefixes it > knows about, in a manner similar to how a servlet container figures > out which web app to run by matching against the context paths > that it knows about. > > * In addition to the defined application prefixes, there will be a > "default" application that processes all requests that cannot be > assigned to any other application. This default application will > be configured *exactly* as the current one-and-only application is > defined, thus maximizing backwards compatibility. > > * Each application that is defined will have its own struts-config.xml > file. The initialization parameters of the controller servlet will > define an application prefix, and corresponding path to the config file, > for each supported application. > > * Internally, all of the static configuration information from a > particular struts-config.xml file will be organized into a single > "application configuration" object. I've checked in a new package > of classes (org.apache.struts.config) to represent this data. Each > ApplicationConfig object will be exposed as a servlet context attribute, > rather than all of the individual objects (ActionMappings, > ActionForwards, and so on). LIKELY EXCEPTION: The actual > javax.sql.DataSource objects for connection pools. > > * All cases of "context-relative" paths in the current Struts environment > will be modified to be "application-relative" instead. This allows you > to configure an application's XML file completely independent of the > application prefix that will be assigned -- exactly the way a web app is > independent of the context path to which it is assigned. (Note also > that this still works for the "default" application -- think of this as > having a zero-length String as the prefix, so that all application > relative paths are actually context relative. > > * All logic in the existing classes (and custom tag implementations) that > currently looks up the configuration information in servlet context > attributes, or via method calls on ActionServlet, will need to be > modified to look up the info for the current application instead. To > facilitate this, we'll add a utility method to RequestUtils that looks > up the appropriate ApplicationConfig object for a given request URI. > > * Existing classes in org.apache.struts.action that represent the config > information will be deprecated in favor of the new classes in > org.apache.struts.config. The exception will be ActionMapping (because > it is passed as an argument to the perform() method of action classes), > but ActionMapping will be modified to subclass > org.apache.struts.config.ActionConfig instead of being its own class. > This maximizes backwards compatibility, but *will* require applications > to be compiled against the version of Struts that they are going to > be run against (not a big restriction, IMHO). > > What do you think? Does this sound like a strategy that can accomplish > the "multiple controllers" feature request without messing up existing > Struts based applications? > > Craig McClanahan > Mitesh Mehta S1 Corp (http://www.s1.com) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
