On Sat, 2 Mar 2002, Martin Cooper wrote:
> Date: Sat, 2 Mar 2002 15:47:47 -0800
> From: Martin Cooper <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> Subject: Re: [Struts-Dev] Multi-App support and using actions across
> applications
>
> Yes, I expect that the multiple module support will remain essentially as is
> for Struts 1.1. (Unless Craig has any more nice surprises for us, that is!)
> This would be the first step in the scenario I described. Essentially, this
> provides the support many people have requested for hosting multiple Struts
> applications within a single web app.
>
This is my current thinking ... multiple application support has been
highly requested, and I think it's going to take a while to consider how
to do hierarchical things correctly, or even if we want it at all (yes,
Martin, I know you do :-).
In the mean time, my design goal was to make it possible to load multiple
independent Struts applications into a single webapp, for the following
purposes:
* An individual Struts app should be able to be packaged in a WAR
by itself, or in combination with other Struts apps, with *no*
changes to the code, pages, resources, or the struts-config.xml
file.
* There should be no restrictions on using the same name for actions,
form beans, forwards, and other configurable items across Struts
apps -- in effect, each app gets its own "namespace".
* The Struts app that is used to handle a particular request is based
on prefix mapping of the request URI (in a manner similar to the way
a servlet container uses prefix mapping against the various context
paths to choose which webapp to execute.
That being said, nothing stops you from sharing Java classes (actions,
form beans, utilities, and so no) between the individual applications that
are included together. You cannot directly share JSP pages (although it
is easy to set up build processes that make multiple copies from a single
source repository at deployment time, if you need them shared). The thing
that is definitely not shared in the current design is the configuration
information -- each Struts app has to be configured completely
independently to meet the goals described above. IMHO, that's a Good
Thing -- sharing increases complexity and fragility of a large scale
application, by re-introducing cross dependencies that multiple app
support is striving to eliminate.
But we'll have to see how that all works out at some future point when a
solid design for hierarchical sharing is proposed.
> As Ted mentioned, we don't really have an official name yet. At some point
> in the discussions, Ted suggested that "modules" might be a good term for
> the sub-apps. Since then, I have adopted that terminology in the big app I
> am developing, so I, for one, would be happy if we selected that terminology
> for Struts itself. ;-) (At one point, we were calling them plug-ins within
> my team at work. I'm glad we didn't stick with that, since Craig has
> recently introduced to Struts a different feature with that name!)
>
In the internal comments, I've been calling these things sub-applications,
which is at least technically accurate, but not very cool sounding. We've
been laughing off the idea of a Struts-let, but ...
> --
> Martin Cooper
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
