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