On Thu, 27 Dec 2001, Donnie Hale wrote:
> Date: Thu, 27 Dec 2001 01:22:24 -0500
> From: Donnie Hale <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: [Design Discussion] Multiple Controllers Per Web App
>
>
>
> > -----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?
Servlet 2.3 won't help on this particular issue -- "/this-prefix/*.do" is
not a valid URL pattern for a <servlet-mapping>, any more than it was in
Servlet 2.2.
I have a few other ideas for how to gradually leverage Servlet 2.3
concepts in optional features for Struts 1.x -- however, I suspect that
the changes to fully incorporate these notions will lead us to a "Struts
2.x" architecture that won't necessarily be as fully backwards compatible.
>
> >
> > 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?
>
That's the idea behind a "default" sub-application, or whatever it is
called. It mirrors precisely the way that Tomcat 4, for example, passes
requests it cannot assign to a particular webapp to the ROOT webapp.
> 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>.
My thought was that the underlying technology (RequestDispatcher.forward()
wasn't going to change, since that is provided by the container. Instead,
the path you specify in a <forward> element would automatically be
prefixed by the application-prefix for the current subapplication. That
way, a sub-application could be *transparently* reconfigured to be the
default application (or vice versa) with no changes to the
struts-config.xml file for it.
(Ted's absolutely right - we need a better name than "application" for
this thing :-).
>
> 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?
>
I haven't looked in detail at the resource manager or config handler
notions with respect to this proposal, but I think you'd treat want to
think of this as an alternative design. My intent is to maximize
backwards compatibility (if we're going to call the next version 1.1, the
number of changes needed to a Struts 1.0 app should be *very* small).
> Donnie
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
