On Sun, 13 Jan 2002, Michael Nash wrote:
> Date: Sun, 13 Jan 2002 10:44:04 -0500
> From: Michael Nash <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: RE: The BIG Check-In for Multi-App Support
>
> Craig:
>
> > OK, I think I've got it working now -- the support for multiple Struts
> > sub-applications in a single web-app, that is.
>
> I'm happy to hear about this, as it's one of the things we extended in
> Struts 1.0 when we connected it with Expresso, as the "sub-app" concept was
> important for Expresso applications, like eForum, ePoll, etc.
>
> I'd like to merge what we did with where you're going, and of course any
> bits of what we've done already that are useful you're welcome to as well.
>
> Just some observations on the parallels, for people using both Expresso and
> Struts - they're pretty close in most cases, so a merge wouldn't be a
> serious "impedance mismatch" from what I can see:
>
> > * All of the configuration information about a sub-app is stored
> > in the ApplicationConfig object, including a bunch of stuff that
> > used to be set with init parameters on the controller servlet.
>
> This sounds a lot like what we currently call a "Schema" object (which is a
> misleading name, I know). The relative path to the MessageBundle for the
> sub-app lives in the Schema. In Expresso the Schema object also defines the
> list of DBObjects, Jobs, and Controllers (Action) objects, so we can do
> things like default security, DB creation, etc. Sounds like maybe "Schema
> extends ApplicationConfig" is in the cards...
>
If I was building from scratch, knowing what we know now (how many times
have we said *that* before :-), I probably would have ended up with
something more like this. I left MessageResources bundles separate,
though, because quite a few apps seem to look them up individually and I
wanted to minimize the backwards-incompatible changes.
However, having the config stuff in a separate object tree has already
helped in one major respect -- adding new configuration parameters doesn't
require any tweaks to the controller servlet any more. All you do is add
the getter and setter to the appropriate Config bean, and voila ...
> > * A multi-app environment still runs from a single instance of the
> > controller servlet, but you can have multiple struts-config.xml
> > files -- one per sub-application.
>
> One of our contributors extended ControllerServlet to simply read all xml's
> with the appropriate DTD in a specific directory, one per sub-app. Might
> this be easier than having to least each app in the web.xml? One less thing
> to configure? Just thinking out loud... Or does the param to the
> ControllerServlet also define the prefix? We do the same kind of thing with
> Lo4j config files - put each of them in a specific directory, then read
> everything that matches that doctype. Makes configuring a new app pretty
> quick and painless.
It's certainly possible to do "all the XML files in directory foo" in a
Servlet 2.3 environment, because you can use
ServletContext.getResourcePaths() to identify them in a portable manner.
In a Servlet 2.2 world, though, you have to rely on file i/o for that --
something I'd prefer to avoid since it is not guaranteed to be available
everywhere.
Instead, I used a trick that I've done in other environments -- the prefix
for a subapp is part of the parameter name. For my example scenario, you
have "config" (which is backwards compatible :-), "config/catalog", and
"config/checkout".
>
> > * The sub-application that applies to a particular request is based
> > on matching an "application prefix" at the beginning of the
> > context-relative URI (similar to the way that a servlet container
> > chooses the web app to run based on the context path prefix of the
> > request URI.
>
> In Expresso we have a table in the DB that lists all the "Schema" objects,
> and each one has a prefix like this associated with it. It also forms a
> prefix for finding related JSP/HTML/doc for the sub-app, so it serves
> double-duty in that sense.
>
I did a subsequent checkin that lets you configure different
RequestProcessor instances (and even implementation classes) for each
sub-app, in case they need different customizations to the standard
request processing functionality.
> > * Like a servlet container, there is the notion of a "default"
> > sub-application that is used to process requests not assigned to
> > any sub-applicaiton. The prefix for this application is ""
> > (i.e. the empty string).
>
> Great news - we're already on this path, so that's no change at all.
>
Great minds and all ... :-)
> > * All of the "context relative" values in struts-config.xml are now
> > "application-relative" instead -- in other words, the request URI
> > equals "context path" + "application prefix" + "local value". This
> > works even for the default sub-application, because its prefix is
> > a zero-length string.
>
> Ditto, no change here.
>
> > * A known issue is that sub-apps won't work for path-mapped actions --
> > only extension mapped at the moment. I believe this can be fixed, but
> > wanted to focus on getting the basics right first.
>
> Has there been any thought to extended path info as parameters? We were
> doing this before Expresso 4.0, but dropped it when we integrated Struts
> 1.0 - does make for cleaner URLs sometimes...
>
One of the challenges with path info is it *only* works for path mapping
-- if you use extension mapping, there is no such thing. This made it
less attractive in my mind.
The way I'm thinking about dealing with the path mapping stuff is to map
the servlet to more than one path (/do/*, /catalog/do/*, and
/checkout/do/*) -- but the logic that figures out how to map from the
"action" parameter of a form to the corresponding action won't deal with
this correctly at the moment.
> I look forward to seeing this evolve, and helping Expresso evolve with it.
> Thanks for the update!
>
Likewise .. I appreciate your help and suggestions!
> Regards,
>
> Mike
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
