tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Saegesser" <marc.saeges...@apropos.com>
Subject RE: Problem with URLPatternMatcher
Date Tue, 26 Jun 2001 15:07:16 GMT
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:ckirkendall@hobsons-us.com]
> Sent: Monday, June 25, 2001 4:55 PM
> To: 'tomcat-dev@jakarta.apache.org'
> 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:marc.saegesser@apropos.com]
> Sent: Monday, June 25, 2001 5:47 PM
> To: tomcat-dev@jakarta.apache.org
> 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: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.


Mime
View raw message