I actually think there are a number of rather independent ideas here, which should probably be treated as such.
1) Resource sharing. In some application scenarios, it is desirable to share (some) data sources, message resources, etc., across all of the modules in the application. This relates more to application-wide (as opposed to module-wide) configuration than it does to module inheritance. 2) Inter-module communication. On the surface, sharing "truly global" global forwards seems similar to (1) above. The difference, however, is that there is now explicit interaction between modules, and in particular, a shared resource which "knows" about the modules which are part of the application. 3) Hierarchical applications. This *might* be a scenario in which the default module becomes a "framework" that other modules plug into, but it might be something else entirely. For example, there is no real reason to treat the default module as the root of the hierarchy. As you know, I happen to have implemented a hierarchical app that way (actually, it turned out to be a directed graph, but I'm not about to explain that :), and I fear that my spouting about that may have unduly influenced others' thinking about how hierarchical applications should be built. Just because I made it work doesn't mean it's the right/best way to do it! Note that while a hierarchical application may take advantage of (1) and (2), it may also achieve its goals in an entirely different way. That's why I think these ideas are largely independent. In any case, I agree with Craig that this is a post-1.1 topic. As I've said before, we really need to get the modular application concept out there and see what people do with it. Then we can have a more general discussion of how Struts in general, and the module concept in particular, can be expanded to address peoples' needs. -- Martin Cooper > -----Original Message----- > From: Eddie Bush [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 4:19 PM > To: Struts Developers List > Subject: [Proposal] Sub-application inheritence > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
