You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Creighton Kirkendall <ck...@hobsons-us.com> on 2001/06/25 15:56:56 UTC
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
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.
RE: Problem with URLPatternMatcher
Posted by Marc Saegesser <ma...@apropos.com>.
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:ckirkendall@hobsons-us.com]
> Sent: Monday, June 25, 2001 8:57 AM
> To: 'tomcat-dev@jakarta.apache.org'
> 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
> 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.