No, the byte count doesn't actually have anything to do with the status
code. I simply added that statement as another reason for using the
wrapper. Sorry for the confusion.
I agree with your earlier statement that sometimes the response code
doesn't get set (or at least it gets set at some point farther
downstream than the filters themselves). What I did with my wrapper
class was create a protected variable named status and initialized it
with 200. Then I overrode setStatus to look like this:
public void setStatus(int sc) {
status = sc;
super.setStatus(sc);
}
And overrode getStatus to look like this:
public int getStatus() {
return status;
}
That way, I *always* get back a status code. It's assumed to be a 200,
which might not necessarily be correct, but at least it's a valid code.
This could be why the logging mechanism that comes with Tomcat was
implemented as a valve; a response code may not necessarily be
guaranteed to be set until the valve layer in the code. Response size
is the same way, as far as I can tell, which is why you have to do a
similar trick with it. I haven't torn apart the AccessLog valve source,
so I'm only operating on assumptions here. For all I know, the
AccessLog valve may do the same thing.
Perhaps one of the old-timers could comment on this?
I have source, if you're interested.
B.
Yair Zohar wrote:
Hi Brantley,
Thanks for replying.
I've tried to pass a wrapper to the filter's chain, here is the
wrapper's code:
import java.io.IOException;
import javax.servlet.http.*;
public class TestResponse extends HttpServletResponseWrapper {
private int statusCode;
public TestResponse(HttpServletResponse response) {
super(response);
}
public int getStatus() {
return statusCode;
}
public void sendError(int errorCode) throws IOException {
this.statusCode = errorCode;
super.sendError(errorCode); }
public void sendError(int errorCode, String errorMessage) throws
IOException {
this.statusCode = errorCode;
super.sendError(errorCode, errorMessage); }
public void setStatus(int statusCode) {
this.statusCode = statusCode;
super.setStatus(statusCode);
}
}
I hopped tomcat will use the wrapper's setStatus() method and then I
will be able to get the status code.
What actually happened is that sometimes the status code returned was 0
and sometimes 404 or 304. It seems tomcat used the wrapper's setStatus()
method only in part of the cases (maybe only when there was a problem
getting the page).
How does the byte count gives information on the status code ?
How do you get the byte count from the output stream ?
Yair.
Brantley Hobbs wrote:
Yair,
I too would be interested in this. I wrote a logging filter that does
what you describe, but the best that I could come up with was a
response wrapper that was passed along the filter chain. In the
wrapper, I could set a status, thus guaranteeing that I would end up
with a status at the end. The wrapper extends
HttpServletResponseWrapper.
You may also find a wrapper useful because response sizes are not
always set either, at least in my experience. With the wrapper, you
can monitor the output stream to get a byte count.
B.
Yair Zohar wrote:
Hello,
I'm trying to create a filter that will do the access logging for my
web application
(I would like to write the information directly to the database not
to a file).
I have a problem to get the status code of the response.
The filter receives a ServletResponse object that do not have a
getStatus() method.
Any idea ?
Yair Zohar.
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To start a new topic, e-mail: [email protected]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
