struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taylor, Jason" <>
Subject RE: multiple sub projects
Date Wed, 25 Sep 2002 22:13:26 GMT
I think Eddie's right, with the only question being do you have levels of
inheritance?  Does "/foo/bar/baz" app inherit first from "/foo/bar" or does
it just get "/foo"?

On the other hand, if this question were seen as more a distraction than a
useful discussion, I'd say table it for 1.1, and use the algorithm Eddie

The way I manage the classes right now is to have the different sub-apps be
part of one package structure, so that a "common" set can be reused by
others sub-apps, and I do the same with jsps, using the "contextRelative"
attribute of the forward node in struts-config-xxx.xml with relative links
to shared jsps.  Images, css and js files are referred to using property
keys, so the only things I'm really duplicating are properties and
struts-config.xml settings.  

I looked back through the mail archive and the reason for keeping the
properties & configs totally separate was to avoid serious problems with the
complexity of "cross-dependencies".  My take is that if your sub-apps are
being used to maintain separate, subtly different versions of a large
application, the problems with sub-app redundancy outweigh the worries of
cross-dependencies.  Especially so once you have a product working for one
client, and a second wants almost the same thing-- it would be nice to
extend/reuse the first version without touching the code/JSPs/media that are
working already.

Basically, it makes the framework much more scalable in a certain, important
way to institute some mechanism that allows for property/config inheritance.
Lots of people are going to implement their own home-grown mechanisms to do
the same thing at build time otherwise.  My 2c.


-----Original Message-----
From: Eddie Bush []
Sent: Wednesday, September 25, 2002 2:50 PM
To: Struts Users Mailing List
Subject: Re: multiple sub projects

This is one of the pices of sub-apps that some of us dislike :-)  I 
believe it was Martin Cooper who responded to me by saying that they 
wanted to see how people were using sub-apps before they made any 
decisions about changing behavior.  The behavior he and I discussed (and 
what it sounds as though you would like, as well) would be for the 
default sub-app to be treated as a "framework" on which the other 
modules were hung.  This view holds the default sub-application as the 
final place to go for config data.  So, if it were adopted at-large, 
your application would look for it's configuration first in the sub-app 
config and then go to the default sub-app before deciding something was 
in error.

There are many reasons this should be done, I believe.  For one, it 
helps "normalize" things such as actions and global forwards, so you 
really only have to have one copy of actions that only need one copy. 
 Otherwise, you would, at minimum, have a reference to one action class 
in N different modules.  I haven't looked, but I strongly suspicion that 
each sub-app would actually have it's own instance of the action class 
in question.  That seems wasteful to me.  Would you like to start 
thinking about data-sources?  :-)  Think about your pool configuration 
and how you have no good way to set limits on it now.  Personally, I 
think the "intelligent" thing to do (IMHO) is to have the default 
sub-app act like that "framework" above, and have all sub-apps seek 
their config in their own config-space, but also then go check the 
default sub-app config-space.  In other words:  Make the configuration 
present in the default sub-app "global" to all sub-apps.

I hope the committers agree with me on this!

Anthony Martin wrote:

>I just split up my struts-config.xml into two.  Now actions specific to a
>sub-project are in their own struts-config file.  But I don't like having
>repeat the form-beans in the second file.  We use the same forms for both
>projects.  There are one or two forms that are in one and not the other,
>for the most part, this makes it redundant.  If I leave out the form-beans
>in the sub-project struts-config file, I get error 400.
>Is there a fix for this in the future, or is this something we'll just have
>to live with?
>"Anything is better than IE, and you can quote me on that." - Wil Wheaton.

Eddie Bush

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message