tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <jimc...@iname.com>
Subject Re: SimpleMapper2
Date Wed, 28 Jun 2000 18:57:06 GMT
Can't the regx library be leveraged very nicely for these mapping
predicaments?

jim

----- Original Message -----
From: Craig McClanahan <Craig.McClanahan@eng.sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Wednesday, June 28, 2000 2:48 PM
Subject: Re: SimpleMapper2


> One thing to keep in mind when designing mapping algorithms is that users
will do some really interesting things.  One that is relevant here is
nesting one context path inside another -- in other words, I could have a
context with path "/examples" and another context with path "/examples/jsp".
Your mapper needs to make sure that it returns the longest possible match
(no matter what algorithm it uses internally).
>
> The same basic principle applies when matching the request URI against the
registered servlet mappings -- the longest match wins.
>
> Craig McClanahan
>
>
> Costin.Manolache@eng.sun.com wrote:
>
> > Hi,
> >
> > It would be great to have a SimpleMapper2 ! In fact, I would like to see
a
> > mapper that is not so Simple, and shows the power of using alghoritms...
> >
> > >     SimpleMapper2 will first find the context in the requestURI
against a hash with context paths, then it will match the servlet path
(requestURI minus context_path) using a helper class that will be registered
in a note in the previously found context (specifically in the context's
container). This helper class will have 2 hashes: one for exact and prefix
mapping (a kind of PrefixMapper) and one for extension mappings, all
belonging to the context. Exact and prefix mappings will be matched in the
PrefixMapper way. Also, AccessInterceptor will use another instance of this
helper class in order to resolve the security mappings. This second instance
will be register in a second note the same way that the other.
> >
> > It's a valid mapping alghoritm, of course - and not the only one.
> >
> > >     1) Despite the fact that a big hash could be relativelly more
efficient, I'm almost
> > > sure that matching against two little hashes (or even lists!) is
better
> > >  that checking against a hash that has
> > > (number_of_contexts*average_number_of_mappings_x_context) indexes (and
> > > each of these indexes is a longer string than it will be in
> > > SimpleMapper2, because it's prefixed by the context).
> >
> > I don't have any mathematical demonstration ( Knuth-like) - so the only
> > way to verify this is to implement it first.
> >
> > If you do the match from the beginning it may work - but the alghoritm
is
> > not so simple ( the original code in tomcat did the same thing, and you
> > can take a look at catalina to understand why this is bad. By matching
in
> > reverse direction, starting from end, you loose much more than you gain
> > and duplicate most of the effort ).
> >
> > I don't want to stop you - this is very complex and we need as much
> > experiment as possible. I don't think anyone has the answer for this
 or
> > if someone does, I'm not sure I'll be able to understand the equations
:-)
> >
> > If you want, please try a Tree structure first - construct a tree with
the
> > notes==path components. Whenever a mapping is added ( outside critical
> > path ) you split it in components and insert it in the tree.
> >
> > When a new request is received, you do a tree search. If most contexts
> > have one component (/foo, /bar) you'll end up with a context hashtable
and
> > then a tree to match request path.
> >
> > As an optimization - on each note you can use either a Hastable or a
> > linear search if you have only few subnodes.
> >
> > >     2) If the context is obtained from the web server as, for example,
an item in the ajp protocol
> > > , SimpleMapper2 will not need to match against the first hash (the
> > > contexts hash)
> >
> > Yes, that would be nice - but even better to have mod_jk do the full
> > mapping and send servlet path and context path.
> >
> > >     3) Is conceptually simpler.
> >
> > Then we can call it "SimpleMapper0" :-)
> >
> > >     4) AccessInterceptor could use the same mechanism in order to do
its own mapping.
> >
> > Yes, Access interceptor has duplicated code inside - I tried hard to
avoid
> > that, but it is too complex. Maybe next time.
> >
> > > So that's all. I will write the code if you agree with me.
> > +1.
> >
> > Costin
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>


Mime
View raw message