Eddie:
Please be assured that I was not trying to "talk down" your code. (I don't time for that kind of thing.) I've been at this long enough to know that mistakes are always possible. (Only our bosses are perfect ;-) I was just questioning a point where (now obviously) I misread what you were doing. I really thought there might have been a convention where people were using "module/" as their module names. My concern in this issue is mainly to steer the fix to this bug in a direction that does not prevent the use of "multi-level" modules (which we had been using successfully prior to the release of 1.1b2). On this point, I will continue to advocate. Sorry for my error, Steve -----Original Message----- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 3:09 PM To: Ditlinger, Steve Subject: Re: FW: DO NOT REPLY [Bug 12702] - ActionServlet selects wrong appl ication module from URL 81101 [HttpProcessor[8081][0]] DEBUG org.apache.struts.util.RequestUtils - Selecting module for path /member 81101 [HttpProcessor[8081][0]] DEBUG org.apache.struts.util.RequestUtils - Activating module /member No, my code doesn't add the trailing "/". You have to specify one beyond what you want a sub-string of (which normally would have been accomplished by indexOf, but, since I started one beyond the string, I had to add one). I always thought it was kind of quirky too, but that now it is. Did you test it? As you can see (by the snippet of logging output above), it returns precisely what is needed. Get rid of the +1 and you won't have a valid sub-app name. I know - I just tried :-) (Hey, I'm not claiming to be perfect!) Using lastIndexOf as the upper-bound on your substring (as you have done), gives you something that does not need modification. The need to do so in my case is subtle difference between the two approaches. I'm not trying to compete either - just stating why I did what I did. I suppose I took your explaination of my patch as an "attempted fix" agressively. For that you have my apology. It does, in fact, bring it in line with what is the currently-stated functionality for sub-applications. That was my intent, and that is what I accomplished ;-) Please don't talk my code down until you at least compile it and run it though -- I did that before I submitted the patch, and never would have submitted it if it did not, in fact, accomplish the desired goal. The debugging before and after application selection was added by me - so I could, in fact, see exactly what I was doing. Ditlinger, Steve wrote: >My variation on what you've done does not break what you've done. It works >equally well for single level modules as well as multi-level, whereas the >version you posted precludes the use of multi-level modules. > >Also I think you should not have the trailing "/" in the matchPath as the >solution you have posted does. The prefixes don't include the trailing "/", >unless, perhaps, you have defined the module name as "module/" in the >web.xml. > >I was not trying to initiate a competition, but I think the solution that >allows the greater flexibility is the way to go, unless we specifically want >to prevent users from defining multi-level modules. > >I went ahead and posted a variation to the proposed patch in Bugzilla (bug # >12702). > >Your truly, > >Steve > -- Eddie Bush -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
