tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Loïc Lefèvre <llefe...@fivia.com>
Subject RE: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? +++
Date Wed, 08 Aug 2001 09:31:10 GMT
As no answer has been given, I repost my message... :)
note: I would like to help you... and me...

Loïc Lefèvre

> On Mon, 6 Aug 2001, Loïc Lefèvre wrote:
>
> > Would/Must the RewriteValve do that?
> >
>
> Well, you can certainly use Valves if you don't mind being tied to Tomcat
> 4.  But, to implement a controller type mechanism that uses request
> dispatchers, a Filter is a much better answer (the only way a Valve can do
> the dispatch is to change the Request URI to select the appropriate
> servlet).

Indeed, I think a filter is better.

>
> Doing the pattern matching yourself (say, with the jakarta-regexp
> package) inside a Filter still avoids all the "thousands of if
> statements" you are worried about.  (But talking about how to implement
> this is straying into TOMCAT-USER topics -- this list is for Tomcat
> development related questions).

2nd Indeed ;), but if I've send this mail here (the DEV mailing list),
it's because of the  catalina/docs/dev/todo.html file and because of
the before the end paragraph:


			Valve Provided Functionality

Priority                    Action Item
Volunteers
...
LOW       Design and implement a valve that provides functional
rt      -
          similar to the Apache server Rewrite family of directives that
          support transformations on the request URI.
          [org.apache.catalina.valves.RewriteValve]
...

Does this answer (your mail) means this action item has been recently
deleted? :(

Second question:
Will Tomcat allow sharing cookies (I mean path="/")?
I think it could be interesting and thus the server.xml don't have a DTD,
this
could be done like this:

        <Host name="www.something.com">
        	<Context path="/www"
            	     docBase="webapps/www"
                 	 crossContext="false"
                 	 debug="11"
                 	 reloadable="true"
			 cookie-path="/">           <---- :))))))))))))))))))) (would be great!)
        	</Context>
        </Host>

How about it?

Third question:
Does the servlet specification (2.2 or 2.3) tell all that Tomcat have to do
or
such idea can become true? :) :) :) :)

note: Does this mail stands in the "PROPOSALS FOR TOMCAT" category or is it
a best way to do it? :)

>
> > Loïc Lefèvre
> >
>
> Craig

Loïc Lefèvre


> note  : thanks Pier ;)
> note 2: it worked before, I mean the e-mail address
>
> -----Message d'origine-----
> De : Craig R. McClanahan [mailto:craigmcc@apache.org]
> Envoyé : samedi 4 août 2001 04:08
> À : 'tomcat-user@jakarta.apache.org'
> Cc : 'tomcat-dev@jakarta.apache.org'
> Objet : Re: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)?
>
>
>
>
>
> On Thu, 2 Aug 2001, Ru, Simon wrote:
>
> > I wonder if Servlet 2.3's Filter allow partial URLPatternMatching.
> Something
> > like:
> >
> > <filter-mapping>
> > <filter-name>timerFilter</filter-name>
> > <url-pattern>/Controller?action=timer*</url-pattern>
> > </filter-mapping>
> > If it can, then we can use the Filtering mechanism as a controller to do
> > request dispatching. We can avoid having thousands if statements in the
> > Controller and we can easily modify the dispatching route without
> recompile.
> >
> > If it can't, is it something worth enhancing? What needs to add to have
> that
> > capability? Thanks in advance.
> >
>
> While what you propose might be quite nice, Tomcat needs to conform to the
> servlet spec's rules for what a legal <url-pattern> can contain -- it's
> the same for both filter mappings and servlet mappings -- and this pattern
> is not legal.
>
> One strategy would be to match for "/Controller/*" and let the filter look
> at the query parameters to decide whether or not to do anything
> special.  Otherwise, it can just pass the request on unmolested.
>
> > Simon Ru
> > Software Engineer
> > (510) 897-5331
> > http://www.worldchain.com
> >
>
> Craig McClanahan
>
>


Mime
View raw message