Does RequestDispatcher.forward bypass ServletFilters? (Jetty 4.2.17)

Discussion:

Jason Sando

2004-02-09 21:54:56 UTC

This may be more of a servlet API question than a Jetty question, let me
know.

I have one context forwarding to another via:

ServletContext theContext = getServletContext().getContext
(targetContext);
theContext.getRequestDispatcher (targetPath).forward (request,
response);

The path being forwarded to is a servlet that has a ServletFilter. When
invoked directly, the filter is executed, but when the request is forwarded
from the second web app the filter is not invoked.

Looking at the Servlet 2.3 spec, it doesn't even mentioned filters in
section 8 Dispatching Requests.

Thanks!

-j

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Greg Wilkins

2004-02-10 02:19:49 UTC

Permalink

2.3 Dispatching does bypass filters.

In 2.4, you can specify a filter to apply to requests, forwards,
includes and/or error dispatches. Jetty5 implements this.

The latest Jetty4 releases actually have the 2.4 filter
capability under the hood, but you cannot configure it with
web.xml.

cheers

Post by Jason Sando
This may be more of a servlet API question than a Jetty question, let me
know.
ServletContext theContext = getServletContext().getContext
(targetContext);
theContext.getRequestDispatcher (targetPath).forward (request,
response);
The path being forwarded to is a servlet that has a ServletFilter. When
invoked directly, the filter is executed, but when the request is forwarded
from the second web app the filter is not invoked.
Looking at the Servlet 2.3 spec, it doesn't even mentioned filters in
section 8 Dispatching Requests.
Thanks!
-j
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Jetty-support mailing list
https://lists.sourceforge.net/lists/listinfo/jetty-support

Jason Sando

2004-02-10 04:17:08 UTC

Permalink

I guess its time to start playing with Jetty 5.

Thanks for the quick answer.

-j

-----Original Message-----
Wilkins
Sent: Monday, February 09, 2004 6:20 PM
Subject: [Jetty-support] Re: Does RequestDispatcher.forward bypass
ServletFilters? (Jetty 4.2.17)
2.3 Dispatching does bypass filters.
In 2.4, you can specify a filter to apply to requests, forwards,
includes and/or error dispatches. Jetty5 implements this.
The latest Jetty4 releases actually have the 2.4 filter
capability under the hood, but you cannot configure it with
web.xml.
cheers

is forwarded

Post by Jason Sando
from the second web app the filter is not invoked.
Looking at the Servlet 2.3 spec, it doesn't even mentioned filters in
section 8 Dispatching Requests.
Thanks!
-j
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Jetty-support mailing list
https://lists.sourceforge.net/lists/listinfo/jetty-support

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Jetty-support mailing list
https://lists.sourceforge.net/lists/listinfo/jetty-support

Jason Sando

2004-02-10 19:51:57 UTC

Permalink

Okay, so now I'm working on Jetty-5.0.beta1, and the forwarded request is
still not triggering the forwarded-to filters. I have upgraded my web.xml
to the 2.4 format, and have included

<filter-mapping>
<filter-name>txFilter</filter-name>
<servlet-name>action</servlet-name>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>

in the web.xml file. I have verified this file is in fact getting deployed
by changing "FORWARD" to "monkey" and verifying that it gets a xml
validation message.

I hit the servlet in the debugger, and when I step into the forward it ends
up in org.mortbay.jetty.servlet.WebApplicationHandler, at line 396 it does
this:

// Forward or include
requestType=
((Dispatcher.DispatcherRequest)request).getFilterType();
if (requestType == FilterHolder.__FORWARD)
{
// Error
requestType= FilterHolder.__ERROR;
}

Its changing my FORWARD into an ERROR! Is this a typo?

Thanks,

-j

-----Original Message-----
Sando
Sent: Monday, February 09, 2004 8:17 PM
Subject: RE: [Jetty-support] Re: Does RequestDispatcher.forward bypass
ServletFilters? (Jetty 4.2.17)
I guess its time to start playing with Jetty 5.
Thanks for the quick answer.
-j

Post by Jason Sando
This may be more of a servlet API question than a Jetty

question, let me

Post by Jason Sando
know.
ServletContext theContext = getServletContext().getContext
(targetContext);
theContext.getRequestDispatcher (targetPath).forward (request,
response);
The path being forwarded to is a servlet that has a

ServletFilter. When

Post by Jason Sando
invoked directly, the filter is executed, but when the request

is forwarded

Greg Wilkins

2004-02-11 05:48:36 UTC

Permalink

Jason,

That is indeed a leftover from a previous life! And I found two other
config bugs with the filter configuration while I was testing this!

Don't know when I broke it, but it is fixed in CVS now and a beta2
release will be out in an hour or two.

cheers

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

Jason Sando

2004-02-11 18:01:44 UTC

Permalink

Greg,

Thanks, I'll keep an eye out for the beta2 release.

I confirmed that the filter was running by adding
<dispatcher>ERROR</dispatcher>, but now I'm having session problems, both
with cookies and URL encoding. But I've seen you answer several questions
about that so I'll go research it.

Let me ask you this: what I'm trying to do is make an administration
front-end for all my web applications. For each deployed application it
will track a MODE, which defines whether users can access the application,
or whether it is being shutdown. With this tool I can then get a new
release ready for deployment, tell the system to shutdown, and then wait for
existing users to logout. New attempts to access the system will receive a
"Application not available" page, while existing users will be encouraged to
save their work and logout.

When the application is shutdown the front-end will continue to provide a
meaningful page to the users, rather than "Servlet not initialized" or "Not
Found" or whatever. So the front-end needs to be a separate application,
rather than a filter, since a filter would be shutdown with the application.

So I'm trying to implement the front-end using cross-context dispatchers,
which gives me a portable technique, although looking at the amount of
objects created its probably taking quite a performance hit.

Have you seen anything like this? Would you recommend a different approach?

Thanks!

- Jason

-----Original Message-----
Wilkins
Sent: Tuesday, February 10, 2004 9:49 PM
Subject: [Jetty-support] Re: Does RequestDispatcher.forward bypass
ServletFilters? (Jetty 4.2.17)
Jason,
That is indeed a leftover from a previous life! And I found two other
config bugs with the filter configuration while I was testing this!
Don't know when I broke it, but it is fixed in CVS now and a beta2
release will be out in an hour or two.
cheers
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Jetty-support mailing list
https://lists.sourceforge.net/lists/listinfo/jetty-support

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Jason Sando

2004-02-11 20:20:17 UTC

Permalink

Okay, I now have sessions working within one context that's being
consistently dispatched to from another context. But I am totally confused
about the difficulties involved.

The target context was creating a session and setting the cookie (or URL
encoding). The cookie path was set to the target context. Subsequent
requests would always create a new session, although the original session
appeared to be accessible via Dispatcher.super.getSession. Whether it uses
a cookie or encoded URL it was always creating a new session.

Per one of the prior postings regarding this subject, I invoked
AbstractSessionManager.setUseRequestedId(true), and now it is working. But
I'm clueless as to why this is needed.

I can understand the cookie path problem, in theory. Except that my request
logs show the browser sent the cookie even though the path was different.
But even using URL encoding it didn't work originally. My front-end servlet
is forwarding it to the target context with a URL that includes the
";jsessionid=blahblahblah", so shouldn't that allow the target context to
pick up its original session?

Thanks,

-Jason

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Greg Wilkins

2004-02-12 03:44:51 UTC

Permalink

Jason,

the problem is that only a single session ID can be associated
with a response that will propogate back in the next request.

So if one context is forwarding to another and both contexts
wish to have sessions -then they MUST agree on the session id,
else one context or the other will replace the session ID of the
other in the cookie or URLs.

regards

Post by Jason Sando
Okay, I now have sessions working within one context that's being
consistently dispatched to from another context. But I am totally confused
about the difficulties involved.
The target context was creating a session and setting the cookie (or URL
encoding). The cookie path was set to the target context. Subsequent
requests would always create a new session, although the original session
appeared to be accessible via Dispatcher.super.getSession. Whether it uses
a cookie or encoded URL it was always creating a new session.
Per one of the prior postings regarding this subject, I invoked
AbstractSessionManager.setUseRequestedId(true), and now it is working. But
I'm clueless as to why this is needed.
I can understand the cookie path problem, in theory. Except that my request
logs show the browser sent the cookie even though the path was different.
But even using URL encoding it didn't work originally. My front-end servlet
is forwarding it to the target context with a URL that includes the
";jsessionid=blahblahblah", so shouldn't that allow the target context to
pick up its original session?
Thanks,
-Jason
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Jetty-support mailing list
https://lists.sourceforge.net/lists/listinfo/jetty-support