tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Creighton Kirkendall <ckirkend...@hobsons-us.com>
Subject Problem with URLPatternMatcher
Date Mon, 25 Jun 2001 13:56:56 GMT
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
ckirkendall@hobsons-us.com



-----Original Message-----
From: kevin seguin [mailto:seguin@motive.com]
Sent: Monday, June 25, 2001 9:36 AM
To: tomcat-dev@jakarta.apache.org
Subject: Re: cvs commit:
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33Ajp14Intercepto
r.java


cmanolache@yahoo.com 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.

Mime
View raw message