> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 26, 2001 11:26 PM
> 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.
Are we at the point w.r.t. the servlet 2.3 spec where we say it's OK to rely
on new features in it, namely filters, to help support this concept as
needed?
>
> A way to look at this is that given a WAR named
>
> {application-name}.war
>
> our URI breaks down to
> ...
>
> Ditto for forwards. If a forward is not found in the local app, should
> it try the global app?
Are forwards, as Struts understands them, going to have to change for this
concept? I.e. before getting a RequestDispatcher, the full path has to be
determined from the subapp-relative path. In terms of how a team would work,
for example the project I'm currently on, we'd definitely want to be able to
forward from an /app-context/subapp1/<whatever> to a
/app-context/subapp2/<whatever>.
Not to make it more complex, and perhaps defaulting to the global/default
app is sufficient, but should the subapps be able to specify an app (or
subapp) from which they're "derived"? The top of the chain would implicitly
be the default app. Just a thought, not fully-formed...
Just from the standpoint of teams being able to work independently on parts
of an app w/o having to fight over access to the struts-config.xml makes
this a worthy concept.
I'll have to get the latest head to see how ApplicationConfig fits with the
"ResourceManager" and "ConfigHandler" stuff I worked on recently. How does
ApplicationConfig relate to the "ActionContext" that Ted recently
implemented?
Donnie
>
> -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]>
