RE: Problem with URLPatternMatcher
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
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.
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.
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.
