Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8CCAA7CCC for ; Fri, 30 Sep 2011 15:14:43 +0000 (UTC) Received: (qmail 39088 invoked by uid 500); 30 Sep 2011 15:14:40 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 38912 invoked by uid 500); 30 Sep 2011 15:14:40 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 38902 invoked by uid 99); 30 Sep 2011 15:14:40 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Sep 2011 15:14:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates 212.85.38.228 as permitted sender) Received: from [212.85.38.228] (HELO tor.combios.es) (212.85.38.228) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Sep 2011 15:14:33 +0000 Received: from [192.168.245.129] (p549E93CF.dip0.t-ipconnect.de [84.158.147.207]) by tor.combios.es (Postfix) with ESMTPA id 9FD5BDA0288 for ; Fri, 30 Sep 2011 17:14:11 +0200 (CEST) Message-ID: <4E85DCAC.8040403@ice-sa.com> Date: Fri, 30 Sep 2011 17:13:48 +0200 From: =?ISO-8859-1?Q?Andr=E9_Warnier?= Reply-To: Tomcat Users List User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: [OT] Logging properties of attributes in the HttpSession References: <4E8496F5.4010503@christopherschultz.net> <4E84AFA0.2030909@christopherschultz.net> <4890864004171834961@unknownmsgid> <4E85BE1B.30606@ice-sa.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Konstantin Kolinko wrote: > 2011/9/30 Andr� Warnier : >> 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