[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Re: [OT] Logging properties of attributes in the HttpSession
From:       André_Warnier <aw () ice-sa ! com>
Date:       2011-09-30 15:13:48
Message-ID: 4E85DCAC.8040403 () ice-sa ! com
[Download RAW message or body]

Konstantin Kolinko wrote:
> 2011/9/30 André Warnier <aw@ice-sa.com>:
>> Pid * wrote:
>>> The changes from the Spring security filter can't be seen by the
>>> access log valve.
>>>
>> And is the "why?" left as an exercise to the reader ?
>>
> 
> Because logging happens after request processing is completed,
> and a filter affects only what happens "inside" the filter in the
> request handling chain.
> 
> The filter wraps request, but log valve sees the original unwrapped request.
> 
> If you need to pass this information to the log valve, I'd suggest you
> to assign it to a request attribute.
> 
Right, makes sense.
It is the same kind of reason why a filter cannot add a header to the original request,
but must wrap it and then add a header to the wrapped request.

Just for information, was this a /necessary/ design feature in Tomcat ?
I mean : in Apache httpd for example, the HTTP Request "object" is not immutable, and a
filter does not need to wrap it; it can modify the original Request as it sees fit.
This simplifies the coding of filters as contrasted with Tomcat (and would also simplify
the case of the logging by the Valve here). (And you could always wrap the original
Request if you wanted to).

So what was the fundamental reason why things under Tomcat are the way they are ? just a
developer's choice, or something mandated by the Servlet Spec e.g. ?




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]