Tomcat 3.2 uses org.apache.tomcat.util.PrefixMapper for mapping URLs into
mapping URL patterns into servlets. The
org.apache.tomcat.request.AccessInterceptor class handles the security
constraint mappings internally.
> -----Original Message-----
> From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 4:55 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Problem with URLPatternMatcher
>
>
> Well, I was but noticed it had this problem. I did fix the code,
> however I
> am not sure whether or not I am going to use it. I do need a URLMatcher.
> If you have any suggestions as to a fast one that would be great. What is
> tomcat using to do its security path constraint matching now.
>
> Creighton
>
>
> -----Original Message-----
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 25, 2001 5:47 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Problem with URLPatternMatcher
>
>
> Yep, it looks like this code is broken, but it isn't actually
> used anywhere
> within Tomcat. In fact it has been removed in 3.3. Are you trying ot use
> this class directly in your code?
>
> > -----Original Message-----
> > From: Creighton Kirkendall [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 25, 2001 8:57 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: Problem with URLPatternMatcher
> >
> >
> > I have noticed that there is a problem in URLPatternMatcher. It
> > seems that
> > in the match function we do not update the length. This is a
> > problem because
> > it causes the pattern matcher not to return the longest pattern.
> > I noticed
> > this some time ago but thought it was fixed in latter releases
> > but it turns
> > out it is still a problem in 3.2.2. I have included the source
> > with the fix
> > in this email.
> >
> >
> > * <http://www.apache.org/>.
> > *
> > * [Additional notices, if required by prior licensing conditions]
> > *
> > */
> >
> > package org.apache.tomcat.util.pattern;
> >
> > import java.util.Enumeration;
> >
> > /**
> > * A form of pattern matching for URLs in which the object corresponding
> > * to the longest matching pattern is returned.
> > *
> > * @author Harish Prabandham
> > */
> > public class URLPatternMatcher implements PatternMatcher {
> > private ImplicationTable itable = new ImplicationTable();
> >
> > public URLPatternMatcher() {
> > }
> >
> > public void set(String pattern, Object value) {
> > itable.put(new WildcardPattern(pattern), value);
> > }
> >
> > public void remove(String pattern) {
> > itable.remove(pattern);
> > }
> >
> > public Object match(String key) {
> > // Since we want the longest pattern match, we cannot use the
> > // itable.get(key)...
> > int len =0;
> > Object val = null;
> >
> > for(Enumeration e = itable.keys(key); e.hasMoreElements(); ){
> > Object thiskey = e.nextElement();
> > String pattern = thiskey.toString();
> > if(pattern.length() > len){
> > val = itable.getValue(thiskey);
> >
> > /*********************
> > *Update 6-25-001
> > *********************/
> > len=pattern.length();
> > }
> > }
> >
> > return val;
> > }
> >
> > public static void main(String[] args) {
> > PatternMatcher p = new URLPatternMatcher();
> > try {
> > p.set("*", "default");
> > p.set(args[0], "works");
> > System.out.println("Match: " + p.match(args[1]));
> > }catch(Exception e) {
> > e.printStackTrace();
> > }
> > }
> > }
> >
> >
> >
> > Creighton Kirkendall
> > Senior Software Engineer
> > Hobsons
> > [EMAIL PROTECTED]
> >
> >
> >
> > -----Original Message-----
> > From: kevin seguin [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 25, 2001 9:36 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: cvs commit:
> > jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Intercepto
> > r.java
> >
> >
> > [EMAIL PROTECTED] wrote:
> > >
> > > On Sun, 24 Jun 2001, kevin seguin wrote:
> > >
> > > > i've been thinking about this, and, well, isn't this
> > BaseRequest you're
> > > > talking about kind of what org.apache.coyote.Request is?
> does it make
> > > > sense to have two of these kinds of objects hanging around? is
> > > > o.a.c.Request roughly equivalent to core.Request in tomcat 3??
> > >
> > > Certainly not for the second part - the core.Request in tomcat3
> > has a lot
> > > of tomcat3-specific code ( Container, ContextManager, calls
> to hooks to
> > > get special info like encoding, etc ).
> > >
> > > The BaseRequest ( or o.a.c.Request ) is focused on the
> > > "basic" information associated with a request, as received by
> > the protocol
> > > adapter.
> > >
> > > For the first part - that's true, AjpRequest is very similar in
> > goal with
> > > o.a.c.Request ( thanks to the refactoring you did :-).
> > >
> > > As I said, I like o.a.coyote, but right now my goal is to see Ajp14
> > > working, and using the existing (working) AjpRequest is easier. Also,
> > > coyote has more than the base request - I would let this settle down.
> > >
> >
> > i hear that :) my immediate goal is ajp13 for tomcat 4 :) i've checked
> > in an intial version of BaseRequest. it may need some further work...
> >
> > -kevin.
