struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brijesh NK" <>
Subject RE: Sub Apps
Date Tue, 17 Sep 2002 06:09:20 GMT
Thanks Eddie, for the valuable information.

-----Original Message-----
From: Eddie Bush []
Sent: Tuesday, September 17, 2002 10:04 AM
To: Struts Users Mailing List
Subject: Re: Sub Apps

On a very high-level, yes :-)

Back in the old days (Struts 1.0), you used to have one application.
 You configured the action servlet in web.xml, and told it where to find
your one (and only) struts-config.xml file.  This one file was where all
of your application config was kept.  Unfortunately, there was
contention when multiple people needed to update the configuration file.

... along comes 1.1 (beta)

Now, you can have as many configuration files as you have modules.  Each
module will (presumably) be handled by one team, so contention is less.
 Each module can be independently developed - caring nothing about the
others, unless it has to.  This is better for multi-developer settings.
 To ease the transition, there is always one module -- the default
module.  That module lives (speaking in URI-terms) at
http://mydomain.dom/appContext/.  All other modules live at

By default, all paths are treated as relative to the module context.
 Since this happens to be the same as the applciation context for the
default application, struts 1.0 applications should be able to easily
migrate to 1.1.  You could then convert over to the new modules strategy
"one piece at a time".

That a "birds-eye view" of sub-applications.  Is that what you wanted?
 Need more details?  Oh, what the heck - here:

It's really quite easy to implement.  You just ... well, in your
web.xml, you do something like this:

    <!-- Default Sub-Application Config -->
    <!-- ModuleA Sub-Application Config -->
    <!-- ModuleB Sub-Application Config -->

Each file is a struts-config file.  What you're actually doing when you
specify the config elements, is saying "make this module live at
<app-context>/<module>".  So, from the example above, we would reach
module a by using a URL like:


We could reach moduleb by doing something like:


Both of my examples depend on one very important key:  You should have
an action setup for each of them that maps to /index.  Provided that you
have done that, you'll have good results.

Let's look at one of the struts-config files:

    <forward contextRelative="true"
    <forward contextRelative="true"
    <forward contextRelative="true"
    <action path="/index"
  <message-resources key="org.apache.struts.action.MESSAGE"


The global-forwards gives me a way to get from this sub-application
(this is a cut-down excerpt from my struts-default.xml) to my other
sub-applications.  Every one of my struts-<module>.xml files has these
very same global-forwards.  I just copied and pasted them from one to
the other.  I made them all context-relative (that means -- interpret
this path as though it is relative to the APPLICATION-context -- not the
module-context.  Struts, by default, will interpret your paths as being
relative to the module-context).  There are other ways to change
sub-applications too.  org.apache.struts.actions.SwitchAction will do
this for you.  Be sure you give it both required request parameters:
 prefix (the module name preceeded by a '/' -- as in /modulea) and page
(if you do a type-o like I did, and get an exception saying to use
prefix and path just ignore it.  It is incorrect.  I already filed a bug
and submitted a patch).

To make navigation among modules easy, all of them have an index action.
 That is the primary entry-point from one module to another.  I may or
may not have additional links into other sub-applications, depending on
what my requirements are.  That's something you'll have to judge for

You'll notice some convention I use.  Each of my modules has it's own
directory under the application root.  I keep things relating to a given
module in it's own directory.  I also have a common directory which
houses things that get shared (like layouts etc).  Unfortunately, I
haven't managed to make Tiles work correctly with sub-applications yet.
 I may be doing something wrong.  That's why you don't see the
TilePlugin being installed.  I just use JSP pages for my definitions.  I
haven't tried the Validator out with them yet -- haven't got along that
far with my prototype.  I guess I should.

I wasn't going to go into so much depth, but I'm nearly certain the
high-level description I started out with wasn't what you were looking for.

Oh - one last note - you *must* go through the controller (ie through an
action) if you want your request to be associated with one of the
non-default sub-applications.  My experiments have shown that I can view
JSP pages directly, and have resources pulled back, but those resources
are always the ones for the main (default) sub-application.

Brijesh NK wrote:

>Could anybody explain SubApplication concepts in struts frame work
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Hope that helps,

Eddie Bush

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message