Hi, how about proposing to use only the "prefix"-noptation for the servlet-mappings (/do/... instead of /*.do).
Then it might be possible to specify the mappings like: /(application_1)/* --> application-1 action-servlet /(application_2)/* --> application-2 action-servlet Wouldn't that make it easier. For bakward compatibility *.do still could be used and would drop back to old-style-struts. Just my 2cents... Alexander Jesse -----Original Message----- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 27, 2001 5:26 AM To: Struts Developers List Subject: Re: [Design Discussion] Multiple Controllers Per Web App +1 overall. Very much one of those brilliant ideas that only seem obvious after someone *else* brings it up. Though I wonder if we need to have a single servlet is catch all the requests and then do the mapping. What if the standard servlet-mapping for a sub-app matched their prefix, and we let the request be routed by the container? The specification says the longest one wins, so /this-prefix/*.do should be matched before *.do. A way to look at this is that given a WAR named {application-name}.war our URI breaks down to /(application-name}/{servlet-name}/{action-path} so we might have a configuration like <servlet> <servlet-name>default</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/conf/default.xml</param-value> </init-param> < ... > </servlet> <servlet> <servlet-name>logon</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>servlet-context</param-name> <param-value>logon</param-value> </init-param> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/conf/logon.xml</param-value> </init-param> <init-param> <param-name>default</param-name> <param-value>false</param-value> </init-param> < ... > </servlet> <servlet-mapping> <servlet-name>default</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>logon</servlet-name> <url-pattern>/logon/*.do</url-pattern> </servlet-mapping> I believe a "default" servlet with a *.do or /do/* servlet would then receive any requests not sent to a longer matching URI (e.g one with a servlet-name prefix). So, with the links being expanded to include the servlet-context (when non-blank), and the RequestURI being expanded to return the right configuration based on the expanded URI, we might be able to let the container do the matching in the normal course. I'd also suggest that we call multiple-servlet applications "sub-apps" or "apps", and reserve "application" to refer to that which could be placed into a single Web Application Resource file. Otherwise, it starts to get confusing. This is a *very* exciting idea. It neatly solves several problems, and open several new doors. Besides supporting team development, where each group can be working on parallel sub-apps, it also makes Struts "portlets" much simplier to do. We could start assembling applications out of components apps, and resuse code in bulk. We should give some thought early-on to what other API mechanisms Struts "portlets" might need. For example a customization resource to provide a common look and feel across sub-applications. This might mean a way to specify a global directory (or sub-app) for resources like stylesheets and images. Going the other way, teams working together on parallel sub-apps might also want to share message resources, so that if a key is not found in the sub-app message resource, it could check the "default" or some other global sub-app. The sub-app would then only have to define messages not carried in the global app. Ditto for forwards. If a forward is not found in the local app, should it try the global app? -Ted. "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 > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ -- 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]>
