Craig R. McClanahan wrote: >On Mon, 7 Oct 2002, Eddie Bush wrote: > >>From: Eddie Bush <[EMAIL PROTECTED]> >>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. >> >There's sharing and then there's sharing :-). > >Sharing *data* in application scope and session scope is a reasonable >thing to have - the fact that it's all in the same webapp is sort of a >poor man's "single sign on" plus not having to copy your JAR files into >things like "$CATALINA_HOME/common/lib" in Tomcat. > >Sharing *functionality* was not at all in the design goals I had >originally. My view of the world was that sub-apps should be as self >contained and independent as possible, in the same manner that webapps >should be as self contained and independent as possible. The idea is that >you can assemble individual subapps together, and also minimize the >cross-sub-app dependencies that can complicate and slow down development. > >Not everyone agrees with this world view. > Ok - I see your point.
>Another, equally important to me, goal is that any existing Struts (1.0) >app should be able to run in 1.1 by itself, or as a subapp, with zero >changes to the struts-config.xml file. This is where life gets >complicated with your proposal. > >>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. >> >All of these are interesting ideas, but to me I think it's post-1.1 >thinking. Because any of them will likely break backwards compatibility >(and because changes this major will only delay 1.1 further), I'd rather >not focus on implementing them now. OK? > LOL, Craig, you're too cool: "... I'd rather not focus on implementing them now. OK?" ... as though I could obligate you to such a thing :-) The reason I posted the proposal was mostly for feedback and to see what folks' views were. I personally would like to see them dealt with prior to 1.1 Final - but I am not you. I realize there has to be a systematic way of introducing things such as this and that the timing may not be appropriate just now. >>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). >> >Fundamentally, your proposals change an individual struts-config.xml from >being a self contained description of a module to a *partial* description >of a module that cannot be installed and run by itself. Personally, I'd >rather spend a couple of hundred extra bucks for a few more megabytes of >memory than to suffer the complexity costs of this. > Yes, they could potentially be partials. Perhaps there would be some way to specify if a module would inherit or not - and it could be used as a flag to (not) chain to the default sub-app. In fact, the default could be false (if unspecified) - and then 1.0 -> 1.1 wouldn't even have to be a thought because none of the semantics would change. >>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)? >> >Post 1.1 enhancement request. > Understood - thank's for chipping in ;-) >>(Would the changes necessary to implement 1 & 2 really be that >>significant? Those are the really important items as I see it.) >> >It's not so much how big the effort is, it's that you are changing the >semantics of how things work in 1.0 and 1.1b2. That's a very significant >issue. > I understand. >NOTE - that is not at all to say that it's a bad idea on its own merits. >I just think it is not appropriate for 1.1 implementation. > >>------------------------------- >> >>[1] - Sub-app partitioning gives us something like: >> >> (default) >> >> / \ >> Foo Bar >> / \ >> Baz Bang >> >I imagine Martin will like this a lot :-). > Inside joke? ... or are you saying that because he's implemented something similar already? (I know he has but can't share it :-/) >>[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 >> >Craig > -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
