Sub-applications in Struts 1.1 are one of the biggest advantages over
1.0. They let you break your configuration apart into multiple pieces -
so that different people can work on their piece of the project without
affecting others. This is good for those of us working in a
team-oriented setting where different (groups of) people may be
responsible for different function areas (ok, Bob and Henry - you guys
get the account-maintenance stuff - Frank, Nancy, and Richardo - you
guys get this 'store' module - etc). Still, sub-applications aren't as
functional as they "could be".
Because of the structure imposed on sub-applications [1], I think
several people believe it would be reasonable for sub-applications to be
able to share information with one another[2]. I believe it is expected
behavior, in fact.
Currently, each module loads whatever resources it will need. As a
result, there is unnecessary duplication of certain resources. Some of
those particular resources result in wasting RAM, while others have a
more significant impact. Of those that have a more significant impact,
the most notable is undoubtably the data-source. Data-source is handy.
It's a pool for JDBC connections. The fact that you can configure the
pool to limit connections is undoubtably an important functionality to
those who use it (though I can't say with full certainty, as I do not
use the built-in data-source) - but now that we have sub-applications,
determining how to setup the pool to properly manage connection limits
could be quite ... difficult. Yes, there are many very good OS DBMSs
out there - but we all have to sensibly ration out our connections - if
only because of resource consumption.
The proposal I would like to set forth is thus (this is a suggested order):
1 - refactor data-source instantiation/acquisition so that
duplicates are not created -- *and* sub-apps would they chain the lookup
from the current module to the default module.
2 - refactor message-resource instantiation/acquisition the same way
3 - refactor global-forward ~kind of~ the same way. Global forwards
mentioned in sub-apps would be "pushed up" into the default module.
Yes, I know there's a possibility for clashing.
4 - (optional) introduce module-level forwards that would replace
our current "global" forwards - and have the exact same "scope"
(visibility) as our current "global" forwards.
Disclaimer: No, I haven't yet fully studied what would have to be done
to acheive this proposal in it's entirety. I post this for open
discussion so that ideas can be generated and bad ones pruned.
So, if you take the view that *all* sub-apps are independent of one
another - and should be - obviously this is a very stupid proposal. If,
however, you take the view that all modules are going to be developed in
support of the default module, this is a very logical following (I
think), as it lets you leverage the effort you put into the default
module in your sub-applications.
My view on (3) above is this: I see modules as being like "classes".
All of the resources are instance-level declarations. "Global", in
this sense, would imply being available either apart from the heirarchy,
or being available in the "base class" (which I suppose puts it back at
the "instance"-level actually).
We wouldn't break backward-compatability (that I can think of), since
the changes would be primarily geared toward allowing non-default
modules to access the default modules resources. Nothing (that crosses
my mind!) would have to change for the default module (save for
"global-forwards" being "pushed up" into the default sub-app -- this
wouldn't impact a 1.0 app moving to 1.1 in the slightest).
I suppose, since, as Ted observed, we're involved in "feature lock",
this is something that is viewed as an "enhancement" or a "bug" request.
My view is that it is a bug, but I have to admit I'm unsure about what
precise functionality you all expected to have in 1.1. I should
probably go check the release plan :-), but I don't recall anything
supporting this being there -- nor do I recall seeing anything that
would inhibit this being there :-)
Is this a "post 1.1" thing? Is this even a desirable thing (I believe
it is - what's your opinion)?
(Would the changes necessary to implement 1 & 2 really be that
significant? Those are the really important items as I see it.)
-------------------------------
[1] - Sub-app partitioning gives us something like:
(default)
/ \
Foo Bar
/ \
Baz Bang
[2] - At least non-default sub-apps to share information from the
default sub-app. From [1], Foo would have access to the default
sub-app's config, as would Bang.
--
Eddie Bush
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
