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.
