You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2005/11/03 17:40:11 UTC
Rewrite features
Hi,
As part of the JBoss Web project, I have developed a URL rewrite valve,
more or less cloned on mod_rewrite. It doesn't support everything from
mod_rewrite, and there's no docs at the moment, but it's not too hard to
figure out how to use it.
For looking at it and testing, it's here (of course, it's neither
polished nor well tested at the moment):
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
> The reason I ask - I'm playing with coyote standalone, I have a
> trivial mapper, file server, hello world adapter - for simple http
> serving.
I would love, love, love to see this. What's the download footprint size?
Thanks,
Yoav
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Costin Manolache <co...@gmail.com>.
Have you considered placing it at a lower level, as a coyote adapter ?
The reason I ask - I'm playing with coyote standalone, I have a
trivial mapper, file server, hello world adapter - for simple http
serving. This would fit well before entering the servlet engine.
Costin
On 11/3/05, Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> The TomcatResolver instance is holding a reference to the Request instance,
> and is in a TL. As a result (because of the way the ThreadPool works) it
> will live very much longer than just during the processing of a given
> Request. This is all fine for all of the current Connectors except Nio/AJP,
> since they happen to bind the Request instance to the Thread instance so you
> always get the right Request instance.
>
> Adding a setRequest method to TomcatResolver would "fix" this with the
> minimal amount of work.
Since TomcatResolver is a very simple object, I replaced the thread
local by a new TomcatResolver.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Thursday, November 03, 2005 12:11 PM
Subject: Re: Rewrite features
>Costin Manolache wrote:
>> On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
>>
>>>It probably doesn't matter (since nobody uses it :), but using
ThreadLocal
>>>won't work with the Nio/AJP Connector. That one doesn't bind a Request
>>>instance to a Thread instance, so a particular Request instance will
process
>>>on many different Threads during its lifecycle.
>>
>> Does the spec say anything about the thread model when executing a
>> servlet ? ( too lazy to search, I know some people on the list have
>> memorized the spec already :-)
>>
>> I'm not sure how this happens - I tought that the request is bound to
>> a thread during service() execution, and kept-alive connections are no
>> longer bound. How do we unbind the service() from the thread ???
>
>There must be a misunderstanding somewhere: the thread is indeed bound
>during the execution of the adapter process method, so TLs should work
>the way I am using them. Using notes is difficult for this because there
>can be "nested" rewrites (one at host level + one at context level, for
>example). I would have preffered using that for performance, of course;
>maybe an array would do it, or something, but TLs are cleaner to
>understand. I do need plenty of TLs anyway, as the regexp engine is per
>thread. For some reason, it took me a long time to figure out a design
>that I liked, worked and met the requirements (I suck).
>
The TomcatResolver instance is holding a reference to the Request instance,
and is in a TL. As a result (because of the way the ThreadPool works) it
will live very much longer than just during the processing of a given
Request. This is all fine for all of the current Connectors except Nio/AJP,
since they happen to bind the Request instance to the Thread instance so you
always get the right Request instance.
Adding a setRequest method to TomcatResolver would "fix" this with the
minimal amount of work.
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
>
>>It probably doesn't matter (since nobody uses it :), but using ThreadLocal
>>won't work with the Nio/AJP Connector. That one doesn't bind a Request
>>instance to a Thread instance, so a particular Request instance will process
>>on many different Threads during its lifecycle.
>
> Does the spec say anything about the thread model when executing a
> servlet ? ( too lazy to search, I know some people on the list have
> memorized the spec already :-)
>
> I'm not sure how this happens - I tought that the request is bound to
> a thread during service() execution, and kept-alive connections are no
> longer bound. How do we unbind the service() from the thread ???
There must be a misunderstanding somewhere: the thread is indeed bound
during the execution of the adapter process method, so TLs should work
the way I am using them. Using notes is difficult for this because there
can be "nested" rewrites (one at host level + one at context level, for
example). I would have preffered using that for performance, of course;
maybe an array would do it, or something, but TLs are cleaner to
understand. I do need plenty of TLs anyway, as the regexp engine is per
thread. For some reason, it took me a long time to figure out a design
that I liked, worked and met the requirements (I suck).
As for putting this at a lower level, no, because Mladen wanted to be
able to specify per host and per context rules, so mapping has to occur
first, and then be performed again (there are other features which need
). Having it as a rule is equivalent to putting it (unless in stupid
cases where the rewrite valve is set after another valve that is
expensive to invoke). Since it's our product, we have some specific
requirements ;)
Side effect: if MessageByte and CharChunk were implementing
CharSequence, I could just give them to the regexp engine without having
to do useless toString calls.
Note: this feature is something that I don't want in Tomcat; just
imagine the non portable mess that webapps would become if rewrite was
readily available ...
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Costin Manolache <co...@gmail.com>.
On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
>
> ----- Original Message -----
> From: "Costin Manolache" <co...@gmail.com>
> To: "Tomcat Developers List" <de...@tomcat.apache.org>
> Sent: Thursday, November 03, 2005 11:30 AM
> Subject: Re: Rewrite features
>
>
> On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
> >> It probably doesn't matter (since nobody uses it :), but using
> ThreadLocal
> >> won't work with the Nio/AJP Connector. That one doesn't bind a Request
> >> instance to a Thread instance, so a particular Request instance will
> process
> >> on many different Threads during its lifecycle.
> >
> >Does the spec say anything about the thread model when executing a
> >servlet ? ( too lazy to search, I know some people on the list have
> >memorized the spec already :-)
>
> When an AJP Request comes in, the Connector gets a Thread from the Pool to
> process the Request. After the Request is done processing, it returns the
> Thread to the Pool. There is no reason that it should get the same Thread
> instance each time it does this.
Yes, but I tought all the service() method is still running in one
thread from start to finish.
The next AJP Request is a different servlet request - in the past it
was in the same thread only if Keep-Alive was used. If the connection
has expired ( keep alive timeout, or multiple connections from browser
) - it'll go to different thread.
The only case I knew where a service() will lose thread in the middle
is the Jetty continuation, where the thread is released by a sepecial
exception and extrenal event reaquire a random thread to continue.
> >
> >I'm not sure how this happens - I tought that the request is bound to
> >a thread during service() execution, and kept-alive connections are no
> >longer bound. How do we unbind the service() from the thread ???
> >
>
> We don't unbind the service() from the Thread. However, in Coyote Request
> instances are very long lived objects that (at least for HTTP/1.1) persist
> over many connections.
But this is not guaranteed - you can't rely on this, there are many
cases where you would get a different thread.
> The APR Connector uses a ThreadLocal to bind the Request instance to a
> single Thread instance. The next request that it handles may have been
> received on a different Socket than the last, but it is bound to the Thread.
> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
> init() method of ThreadPoolRunnable.
I still don't understand the problem.
2 requests from the same browser can be assigned different threads in
both connectors. They get same thread in the old connector more often
- if they happen to use the same socket, but this is not allways the
case.
I suppose I'm missing something trivial here...
>
> The Nio/AJP Connector binds the Request instance to a Socket connection (via
> the SelectionKey.attachment).
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Thursday, November 03, 2005 12:18 PM
Subject: Re: Rewrite features
>Bill Barker wrote:
>> We don't unbind the service() from the Thread. However, in Coyote
Request
>> instances are very long lived objects that (at least for HTTP/1.1)
persist
>> over many connections.
>>
>> The APR Connector uses a ThreadLocal to bind the Request instance to a
>> single Thread instance. The next request that it handles may have been
>> received on a different Socket than the last, but it is bound to the
Thread.
>> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via
the
>> init() method of ThreadPoolRunnable.
>>
>> The Nio/AJP Connector binds the Request instance to a Socket connection
(via
>> the SelectionKey.attachment).
>
>Personally, I always considered the Request/Response objects were tied
>to the thread. I don't know for sure, but it could mean that my valve
>may not work with your connector then (the utility object that resolves
>special variables uses the request, and it could be an issue).
>
As I said, it probably doesn't matter since nobody (except me :) uses my
Connector. Also, if you're using AJP it's likely that you'd be using
mod_rewrite for this sort of thing anyway ;-).
>Rémy
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> We don't unbind the service() from the Thread. However, in Coyote Request
> instances are very long lived objects that (at least for HTTP/1.1) persist
> over many connections.
>
> The APR Connector uses a ThreadLocal to bind the Request instance to a
> single Thread instance. The next request that it handles may have been
> received on a different Socket than the last, but it is bound to the Thread.
> With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
> init() method of ThreadPoolRunnable.
>
> The Nio/AJP Connector binds the Request instance to a Socket connection (via
> the SelectionKey.attachment).
Personally, I always considered the Request/Response objects were tied
to the thread. I don't know for sure, but it could mean that my valve
may not work with your connector then (the utility object that resolves
special variables uses the request, and it could be an issue).
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Costin Manolache" <co...@gmail.com>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Thursday, November 03, 2005 11:30 AM
Subject: Re: Rewrite features
On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
>> It probably doesn't matter (since nobody uses it :), but using
ThreadLocal
>> won't work with the Nio/AJP Connector. That one doesn't bind a Request
>> instance to a Thread instance, so a particular Request instance will
process
>> on many different Threads during its lifecycle.
>
>Does the spec say anything about the thread model when executing a
>servlet ? ( too lazy to search, I know some people on the list have
>memorized the spec already :-)
When an AJP Request comes in, the Connector gets a Thread from the Pool to
process the Request. After the Request is done processing, it returns the
Thread to the Pool. There is no reason that it should get the same Thread
instance each time it does this.
>
>I'm not sure how this happens - I tought that the request is bound to
>a thread during service() execution, and kept-alive connections are no
>longer bound. How do we unbind the service() from the thread ???
>
We don't unbind the service() from the Thread. However, in Coyote Request
instances are very long lived objects that (at least for HTTP/1.1) persist
over many connections.
The APR Connector uses a ThreadLocal to bind the Request instance to a
single Thread instance. The next request that it handles may have been
received on a different Socket than the last, but it is bound to the Thread.
With the Java HTTP/1.1 Connector, the Request is bound to the Thread via the
init() method of ThreadPoolRunnable.
The Nio/AJP Connector binds the Request instance to a Socket connection (via
the SelectionKey.attachment).
>
>Costin
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Costin Manolache <co...@gmail.com>.
On 11/3/05, Bill Barker <wb...@wilshire.com> wrote:
> It probably doesn't matter (since nobody uses it :), but using ThreadLocal
> won't work with the Nio/AJP Connector. That one doesn't bind a Request
> instance to a Thread instance, so a particular Request instance will process
> on many different Threads during its lifecycle.
Does the spec say anything about the thread model when executing a
servlet ? ( too lazy to search, I know some people on the list have
memorized the spec already :-)
I'm not sure how this happens - I tought that the request is bound to
a thread during service() execution, and kept-alive connections are no
longer bound. How do we unbind the service() from the thread ???
Costin
>
> The alternative (which, IMHO looks nicer) is to use (Coyote)Request Notes
> instead of ThreadLocal.
>
> ----- Original Message -----
> From: "Remy Maucherat" <re...@apache.org>
> To: "Tomcat Developers List" <de...@tomcat.apache.org>
> Sent: Thursday, November 03, 2005 8:40 AM
> Subject: Rewrite features
>
>
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
> http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jbos
> s/web/rewrite/
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
>
> This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
>
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Bill Barker <wb...@wilshire.com>.
It probably doesn't matter (since nobody uses it :), but using ThreadLocal
won't work with the Nio/AJP Connector. That one doesn't bind a Request
instance to a Thread instance, so a particular Request instance will process
on many different Threads during its lifecycle.
The alternative (which, IMHO looks nicer) is to use (Coyote)Request Notes
instead of ThreadLocal.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <de...@tomcat.apache.org>
Sent: Thursday, November 03, 2005 8:40 AM
Subject: Rewrite features
Hi,
As part of the JBoss Web project, I have developed a URL rewrite valve,
more or less cloned on mod_rewrite. It doesn't support everything from
mod_rewrite, and there's no docs at the moment, but it's not too hard to
figure out how to use it.
For looking at it and testing, it's here (of course, it's neither
polished nor well tested at the moment):
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jbos
s/web/rewrite/
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Remy Maucherat <re...@apache.org>.
Yoav Shapira wrote:
> Hi,
> Cool, I like it. Two questions:
>
> - Why the RewriteMap interface? It does seem to add much over a normal Map,
> and I doubt you're targeting JDK 1.1 compatibility ;)
It's not a map (at least not a Java map). mod_rewrite calls the
directive RewriteMap.
> - Seems like this could be easily done as a Filter instead of Valve. The
> lifecycle support would be a bit different, start -> init, stop -> destroy,
> etc, but otherwise it doesn't seem like a stretch...
A filter would not work. Doing it this way will (eventually) be a lot
more efficient.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Rewrite features
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
Cool, I like it. Two questions:
- Why the RewriteMap interface? It does seem to add much over a normal Map,
and I doubt you're targeting JDK 1.1 compatibility ;)
- Seems like this could be easily done as a Filter instead of Valve. The
lifecycle support would be a bit different, start -> init, stop -> destroy,
etc, but otherwise it doesn't seem like a stretch...
Yoav
--- Remy Maucherat <re...@apache.org> wrote:
> Hi,
>
> As part of the JBoss Web project, I have developed a URL rewrite valve,
> more or less cloned on mod_rewrite. It doesn't support everything from
> mod_rewrite, and there's no docs at the moment, but it's not too hard to
> figure out how to use it.
>
> For looking at it and testing, it's here (of course, it's neither
> polished nor well tested at the moment):
>
http://anonsvn.labs.jboss.com/trunk/labs/jbossweb/src/share/classes/org/jboss/web/rewrite/
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org