+1 Eddie's right about the brokenness of the behavior he's trying to patch and he's right about the importance of addressing sub-app issues before the next release-- the importance of at least discussing them. Is it somehow taboo to discuss these things at this stage of 1.1's development?
My 2c (ignore freely): To me, sub-app support is also one of the most important features of 1.1 and I've found it odd that struts-dev has been so silent on Eddie's patch and other multiple sub-app issues such as property sharing. I see sub-apps being very important to large organizations that are perfectly happy to trade simplicity for flexibility so long as it's supported in a "released" version of the framework. It seems a shame to be so close to a very powerful feature and not fully implement it in the next major release. -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 03, 2002 12:27 PM To: Struts Developers List Subject: Applying patches I'm sure there's some protocol for applying patches that fits into the Struts development cycle, but I'm not aware of what it is. I have to admit it's somewhat annoying to find a bug, patch it, build a patch file, and submit it, only to have it seemingly ignored. I honestly don't believe they are intentionally ignored, and I do realize that the commiters have other things they have to do than just examine/commit proposed fixes to bugs, but I would also like to state that it's somewhat aggrevating to see developed/tested patches sit idle (without explaination) when there are likely folks out there that may be hitting on problems the patch addresses - some of which, being unsure of themselves (because they are new, perhaps), are absolutely beating their head against the wall to try to get Struts to behave as it rightly should - only to find they "still don't get it" (through no fault of their own - the behavior is broken and they could not make it work no matter how hard they try). <emote:standingOnSoapBox> I'm not trying to step on any toes - the last thing I want is to offend anyone here. Each of you is highly respected by me. However :-) I feel that patches that address glaring bugs which inhibit a person from making proper use of important (!) functionality of the framework should be examined and applied quickly - they should have a high priority. Sub-Applications (the ability to bust your configuration file into as many different files as your application has functional areas) is one of the most significant features introduced in Struts 1.1 over Struts 1.0. Their arrival is a "good thing" - but they do not work properly. The most glaring way in which they do not properly function is in selection. The current selection algorithm is to iterate over the set of known prefixes of the sub-apps and see if the requested URI starts with one of the prefixes. This just really isn't acceptable, and here's why: /foo.do /foo/bar.do Suppose you have the scenario setup by the above two actions. What *should* happen when you invoke /foo.do? Obviously, the controller should select the default application and execute "foo.do" from that module. What *does* happen when you invoke /foo.do? Well, you switch to sub-app foo because of the "startsWith()" criteria being used to select the sub-app. Another example: /foo/index.do /foo/bar/index.do (where /foo/bar is a sub-app name) Suppose you have this scenario. Again, you can see (I think) that you won't necessarily select the proper application. Ok - point made: it's definitely broke. What I'm getting at, I suppose, is that it's disheartening and discouraging to see fixes having been submitted for this bug continue to not be applied. Why would a person, acting with a sense of urgency to fix something that is broken, act with that same sense of urgency to actually contribute their changes back to the project, when their patch will not be applied (assuming it does in fact fix the behavior to be as it should) with that same sense of urgency? It's in everyone's best interest that each of us act with as much of a sense of urgency as is practical for us (each individual will have different constraints placed upon their ability to execute and the timeline they are able to do so on) to address important issues as we find them - is it not? </emote:standingOnSoapBox> I've previously stated that it was irrelevant to me whether my patches were used - and I meant that sincerely. I do believe, when provided with a patch, it should be examined for merit and applied accordingly. Should the commiter have some reason why a given patch is unacceptable, it would really be nice for them to add a comment to the bug report itself stating why they found the patch inappropriate (doesn't fully address the issue - fixes one problem but creates another - whatever). I just hate to see folks turning away from sub-applications because their implementation is (partially, at least) broke - and I know for a fact some are. I also hate to think of the possibility where someone might choose another framework over Struts because this gives them the mistaken impression that it's not worthy of their use. Maybe I just take too much pride in Struts. It's not like I have any "ownership" here - but I feel like I do. Is there anything I can do, beyond submitting a patch (and doing so in a format that makes it easily applied - ie diff -u), to get a bug fixed in a timely manner? It makes me sad to think of the nightly builds which could have already incorporated this fix ... and the people suffering from it having not been incorporated. Kindest Regards, Eddie -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
