You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Richard Sayre <ri...@gmail.com> on 2011/09/29 15:18:02 UTC
Logging properties of attributes in the HttpSession
Hi,
I am logging all local host access using the following config:
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
prefix="localhost_access_log." suffix=".txt"
pattern='%h %l %u %{userObject}s %t "%r" %s %b'
resolveHosts="false"/>
The userObject HttpSession attribute is a Java Object and right now it
is logging it by calling its toString method.
I wanted to log a specific property of that object (userId) so I tried
%{userObject.userId}s but that did not print anything.
Is it possible to log properties of an object that is in session? I
can add the information to the toString method but I want avoid that
for now (I would have to re check the whole application 1500+ pages to
make sure that it is not called anywhere else).
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Logging properties of attributes in the HttpSession
Posted by André Warnier <aw...@ice-sa.com>.
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
Re: Logging properties of attributes in the HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 10/3/2011 4:16 PM, Konstantin Kolinko wrote:
> 2011/10/3 Christopher Schultz <ch...@christopherschultz.net>:
>> On 9/30/2011 2:18 PM, Konstantin Kolinko wrote:
>>> 2011/9/30 Christopher Schultz <ch...@christopherschultz.net>:
>>>> The OP should be able to put the Filter into the <Context>
>>>> in such a way that the Filter wraps the AccessLogValve, no?
>>>>
>>>
>>> 1. You cannot put a Filter into Context.
>>
>> Mmm. Why do I always think that you can do this sort of thing?
>> Maybe I'll log an enhancement that allows us to do this: it seems
>> reasonable to allow Filters to be interspersed with Valves,
>> especially for things like this.
>
> This: https://issues.apache.org/bugzilla/show_bug.cgi?id=51754
> worries me a bit more.
Allowing <Valve> and <Filter> to be arbitrarily ordered shouldn't
affect that bug, which has to do with where the default filters are
inserted into the valve/filter chain. That problem would still exist
and, IMO, not get any worse by allowing <Filter> to appear anywhere a
<Valve> can appear.
>>> 3. A Valve can modify a Request, while Filter cannot.
>>
>> Both Filter and Valve can wrap the request, which can be seen as
>> "modifying" it, though it's not really modifying it.
>
> Valve has access to o.a.c.connector.Request object, which is
> modifiable.
Right: it is directly modifiable instead of... maskable :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6LLFEACgkQ9CaO5/Lv0PBvsACeNB77v1spBBGq3M+q+Gm9S8RM
QRMAniS6odp+lVkhTcTMz5sYFvtET63h
=2H7h
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/10/3 Christopher Schultz <ch...@christopherschultz.net>:
> On 9/30/2011 2:18 PM, Konstantin Kolinko wrote:
>> 2011/9/30 Christopher Schultz <ch...@christopherschultz.net>:
>>> The OP should be able to put the Filter into the <Context> in
>>> such a way that the Filter wraps the AccessLogValve, no?
>>>
>>
>> 1. You cannot put a Filter into Context.
>
> Mmm. Why do I always think that you can do this sort of thing? Maybe
> I'll log an enhancement that allows us to do this: it seems reasonable
> to allow Filters to be interspersed with Valves, especially for things
> like this.
This:
https://issues.apache.org/bugzilla/show_bug.cgi?id=51754
worries me a bit more.
>
>> 3. A Valve can modify a Request, while Filter cannot.
>
> Both Filter and Valve can wrap the request, which can be seen as
> "modifying" it, though it's not really modifying it.
Valve has access to o.a.c.connector.Request object, which is modifiable.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 9/30/2011 2:18 PM, Konstantin Kolinko wrote:
> 2011/9/30 Christopher Schultz <ch...@christopherschultz.net>:
>> The OP should be able to put the Filter into the <Context> in
>> such a way that the Filter wraps the AccessLogValve, no?
>>
>
> 1. You cannot put a Filter into Context.
Mmm. Why do I always think that you can do this sort of thing? Maybe
I'll log an enhancement that allows us to do this: it seems reasonable
to allow Filters to be interspersed with Valves, especially for things
like this.
> 2. AccessLogValve in Tomcat 7 cannot be wrapped. It does not act as
> a true "valve", but more as a marker interface.
>
> 3. A Valve can modify a Request, while Filter cannot.
Both Filter and Valve can wrap the request, which can be seen as
"modifying" it, though it's not really modifying it.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6J58kACgkQ9CaO5/Lv0PAQpQCZAUxprioYXm5MQsChC4seTlco
+2IAnjnMOjLLPC6qTdFyFfVh6lwOlyKw
=0dgS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/9/30 Christopher Schultz <ch...@christopherschultz.net>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Konstantin,
>
> On 9/30/2011 9:27 AM, 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.
>
> The OP should be able to put the Filter into the <Context> in such a
> way that the Filter wraps the AccessLogValve, no?
>
1. You cannot put a Filter into Context.
2. AccessLogValve in Tomcat 7 cannot be wrapped. It does not act as a
true "valve", but more as a marker interface.
3. A Valve can modify a Request, while Filter cannot.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Konstantin,
On 9/30/2011 9:27 AM, 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.
The OP should be able to put the Filter into the <Context> in such a
way that the Filter wraps the AccessLogValve, no?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6GAF4ACgkQ9CaO5/Lv0PCVGwCfRKafqELtU56KCO4wngj+tPQ8
WXUAn3srp9jQDELhN5xxoGbhRXmQUwPF
=Wbqg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Konstantin Kolinko <kn...@gmail.com>.
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.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by 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 ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Pid * <pi...@pidster.com>.
The changes from the Spring security filter can't be seen by the
access log valve.
p
On 30 Sep 2011, at 12:40, Richard Sayre <ri...@gmail.com> wrote:
> I'm still having some trouble. I added the Spring filter and then in
> my web app I called:
>
> getRequest().getRemoteUser() and getRequest().getUserPrincipal().getName()
>
> Both methods returned the logged in user name. (getRequest() returns
> the HttpServletRequest)
>
> However, in the logs %u is still returning '-'.
>
> Is there anything else Tomcat needs to have before whatever part of
> the API gets called for %u will return the remoteUser?
>
> Thanks,
>
> Rich
>
>
> On Thu, Sep 29, 2011 at 3:32 PM, Richard Sayre <ri...@gmail.com> wrote:
>> Ahh yes I just discovered it when you replied:
>>
>> http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/servletapi/SecurityContextHolderAwareRequestFilter.html
>>
>> Thanks
>>
>> Rich
>>
>> On Thu, Sep 29, 2011 at 3:19 PM, Christopher Schultz
>> <ch...@christopherschultz.net> wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Rich,
>>>
>>> On 9/29/2011 12:18 PM, Richard Sayre wrote:
>>>> Thanks, I'm trying to log the user name. I am not using Tomcat
>>>> for authentication and I need that info in my access logs.
>>>
>>> So, that means that %u isn't an option, then? :(
>>>
>>>> Perhaps I will create a new attribute to hold that value rather
>>>> than accessing the object I have in session and calling toString.
>>>
>>> You have a couple of options, here:
>>>
>>> 1. Write a Filter that wraps HttpServletRequest and overrides
>>> the getRemoteUser to return userObject.getUserId. Then, use
>>> "%u" in your access log pattern.
>>> 2. Write a Filter that checks the session for "userObject" and no
>>> "userId", and sets "userId" as appropriate.
>>> 3. Modify your login process to set both "userObject" and, say,
>>> "userId" in the session.
>>>
>>> I would say those are in order of easiest-to-hardest.
>>>
>>>> On that note if I know the username, is it possible to somehow
>>>> inject it so that Tomcat logs it using the %u pattern.
>>>
>>> Yup, see above.
>>>
>>>> Previously we used Tomcats built in authentication but we recently
>>>> switched to Spring Security. If I could still use %u, then I
>>>> could use the 'common' pattern and in turn use
>>>> FastCommonAccessLogValve. If not I will use the HTTP Session.
>>>
>>> Hmm.... I'm surprised that Spring Security doesn't better integrate
>>> with the container in order to provide ServletRequest.getPrincipal and
>>> ServletRequest.getRemoteUser. I wonder if there is a Filter that
>>> already exists in Spring Security that would do what I suggested in #1.
>>>
>>> - -chris
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.10 (MingW32)
>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>>
>>> iEYEARECAAYFAk6Er6AACgkQ9CaO5/Lv0PB+FACgqb6s6BSBcoiMf4Ka1+awxArC
>>> UHoAnR0LSUHNGRnuyHSpvW7vEYONDJuK
>>> =NFZ/
>>> -----END PGP SIGNATURE-----
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Richard Sayre <ri...@gmail.com>.
I'm still having some trouble. I added the Spring filter and then in
my web app I called:
getRequest().getRemoteUser() and getRequest().getUserPrincipal().getName()
Both methods returned the logged in user name. (getRequest() returns
the HttpServletRequest)
However, in the logs %u is still returning '-'.
Is there anything else Tomcat needs to have before whatever part of
the API gets called for %u will return the remoteUser?
Thanks,
Rich
On Thu, Sep 29, 2011 at 3:32 PM, Richard Sayre <ri...@gmail.com> wrote:
> Ahh yes I just discovered it when you replied:
>
> http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/servletapi/SecurityContextHolderAwareRequestFilter.html
>
> Thanks
>
> Rich
>
> On Thu, Sep 29, 2011 at 3:19 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Rich,
>>
>> On 9/29/2011 12:18 PM, Richard Sayre wrote:
>>> Thanks, I'm trying to log the user name. I am not using Tomcat
>>> for authentication and I need that info in my access logs.
>>
>> So, that means that %u isn't an option, then? :(
>>
>>> Perhaps I will create a new attribute to hold that value rather
>>> than accessing the object I have in session and calling toString.
>>
>> You have a couple of options, here:
>>
>> 1. Write a Filter that wraps HttpServletRequest and overrides
>> the getRemoteUser to return userObject.getUserId. Then, use
>> "%u" in your access log pattern.
>> 2. Write a Filter that checks the session for "userObject" and no
>> "userId", and sets "userId" as appropriate.
>> 3. Modify your login process to set both "userObject" and, say,
>> "userId" in the session.
>>
>> I would say those are in order of easiest-to-hardest.
>>
>>> On that note if I know the username, is it possible to somehow
>>> inject it so that Tomcat logs it using the %u pattern.
>>
>> Yup, see above.
>>
>>> Previously we used Tomcats built in authentication but we recently
>>> switched to Spring Security. If I could still use %u, then I
>>> could use the 'common' pattern and in turn use
>>> FastCommonAccessLogValve. If not I will use the HTTP Session.
>>
>> Hmm.... I'm surprised that Spring Security doesn't better integrate
>> with the container in order to provide ServletRequest.getPrincipal and
>> ServletRequest.getRemoteUser. I wonder if there is a Filter that
>> already exists in Spring Security that would do what I suggested in #1.
>>
>> - -chris
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iEYEARECAAYFAk6Er6AACgkQ9CaO5/Lv0PB+FACgqb6s6BSBcoiMf4Ka1+awxArC
>> UHoAnR0LSUHNGRnuyHSpvW7vEYONDJuK
>> =NFZ/
>> -----END PGP SIGNATURE-----
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Richard Sayre <ri...@gmail.com>.
Ahh yes I just discovered it when you replied:
http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/servletapi/SecurityContextHolderAwareRequestFilter.html
Thanks
Rich
On Thu, Sep 29, 2011 at 3:19 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rich,
>
> On 9/29/2011 12:18 PM, Richard Sayre wrote:
>> Thanks, I'm trying to log the user name. I am not using Tomcat
>> for authentication and I need that info in my access logs.
>
> So, that means that %u isn't an option, then? :(
>
>> Perhaps I will create a new attribute to hold that value rather
>> than accessing the object I have in session and calling toString.
>
> You have a couple of options, here:
>
> 1. Write a Filter that wraps HttpServletRequest and overrides
> the getRemoteUser to return userObject.getUserId. Then, use
> "%u" in your access log pattern.
> 2. Write a Filter that checks the session for "userObject" and no
> "userId", and sets "userId" as appropriate.
> 3. Modify your login process to set both "userObject" and, say,
> "userId" in the session.
>
> I would say those are in order of easiest-to-hardest.
>
>> On that note if I know the username, is it possible to somehow
>> inject it so that Tomcat logs it using the %u pattern.
>
> Yup, see above.
>
>> Previously we used Tomcats built in authentication but we recently
>> switched to Spring Security. If I could still use %u, then I
>> could use the 'common' pattern and in turn use
>> FastCommonAccessLogValve. If not I will use the HTTP Session.
>
> Hmm.... I'm surprised that Spring Security doesn't better integrate
> with the container in order to provide ServletRequest.getPrincipal and
> ServletRequest.getRemoteUser. I wonder if there is a Filter that
> already exists in Spring Security that would do what I suggested in #1.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6Er6AACgkQ9CaO5/Lv0PB+FACgqb6s6BSBcoiMf4Ka1+awxArC
> UHoAnR0LSUHNGRnuyHSpvW7vEYONDJuK
> =NFZ/
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rich,
On 9/29/2011 12:18 PM, Richard Sayre wrote:
> Thanks, I'm trying to log the user name. I am not using Tomcat
> for authentication and I need that info in my access logs.
So, that means that %u isn't an option, then? :(
> Perhaps I will create a new attribute to hold that value rather
> than accessing the object I have in session and calling toString.
You have a couple of options, here:
1. Write a Filter that wraps HttpServletRequest and overrides
the getRemoteUser to return userObject.getUserId. Then, use
"%u" in your access log pattern.
2. Write a Filter that checks the session for "userObject" and no
"userId", and sets "userId" as appropriate.
3. Modify your login process to set both "userObject" and, say,
"userId" in the session.
I would say those are in order of easiest-to-hardest.
> On that note if I know the username, is it possible to somehow
> inject it so that Tomcat logs it using the %u pattern.
Yup, see above.
> Previously we used Tomcats built in authentication but we recently
> switched to Spring Security. If I could still use %u, then I
> could use the 'common' pattern and in turn use
> FastCommonAccessLogValve. If not I will use the HTTP Session.
Hmm.... I'm surprised that Spring Security doesn't better integrate
with the container in order to provide ServletRequest.getPrincipal and
ServletRequest.getRemoteUser. I wonder if there is a Filter that
already exists in Spring Security that would do what I suggested in #1.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6Er6AACgkQ9CaO5/Lv0PB+FACgqb6s6BSBcoiMf4Ka1+awxArC
UHoAnR0LSUHNGRnuyHSpvW7vEYONDJuK
=NFZ/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Richard Sayre <ri...@gmail.com>.
Thanks, I'm trying to log the user name. I am not using Tomcat for
authentication and I need that info in my access logs. Perhaps I will
create a new attribute to hold that value rather than accessing the
object I have in session and calling toString.
On that note if I know the username, is it possible to somehow inject
it so that Tomcat logs it using the %u pattern. Previously we used
Tomcats built in authentication but we recently switched to Spring
Security. If I could still use %u, then I could use the 'common'
pattern and in turn use FastCommonAccessLogValve. If not I will use
the HTTP Session.
Thanks,
Rich
On Thu, Sep 29, 2011 at 1:34 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Rich,
>
> On 9/29/2011 9:18 AM, Richard Sayre wrote:
>> I am logging all local host access using the following config:
>>
>> <Valve className="org.apache.catalina.valves.AccessLogValve"
>> directory="logs" prefix="localhost_access_log." suffix=".txt"
>> pattern='%h %l %u %{userObject}s %t "%r" %s %b'
>> resolveHosts="false"/>
>>
>>
>> The userObject HttpSession attribute is a Java Object and right now
>> it is logging it by calling its toString method.
>
> Right.
>
>> I wanted to log a specific property of that object (userId) so I
>> tried %{userObject.userId}s but that did not print anything.
>
> Right. It's looking for an object in the session with the key
> "userObject.userId", rather than doing what you expect, which is to
> get "userObject" and then call "getUserId" on it with no arguments.
> AccessLogValve doesn't do that kind of thing: it's not very smart.
> (It's nice and fast, though).
>
>> Is it possible to log properties of an object that is in session?
>
> Not with the current code: you'd have to modify the AccessLogValve.
>
>> I can add the information to the toString method but I want avoid
>> that for now (I would have to re check the whole application 1500+
>> pages to make sure that it is not called anywhere else).
>
> Honestly, no code should be depending on the return value of toString
> on any complex object. I'm not saying it doesn't happen... I'm just
> saying that it /shouldn't/ happen.
>
> Adding such a feature to AccessLogValve is certainly possible, but I'm
> sure that it won't be added to the "%{...}s" syntax because of the
> overhead of parsing the {...} to determine how to dereference and
> navigate the object tree, etc. Such code exists: it's available
> through any number of libraries and the syntax all looks the same or
> similar (Java EL, etc.): it just needs to be configured to do that.
>
> I'd be in support of a *new* escape sequence that would support this
> kind of thing because I think it would be useful but it needs to be
> distinct from the existing one so that it doesn't kill performance for
> everyone who is already using it. To be sure, AccessLogValve is
> intended to be run for every request, so speed is of the essence :)
>
> Patches are always welcome.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk6ElvQACgkQ9CaO5/Lv0PBiuQCfUErS2/N6sbJ/CgfYPmc3CSZY
> ZhAAoLayLJI66d35xwsla/Y8lUboTcco
> =K166
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Logging properties of attributes in the HttpSession
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rich,
On 9/29/2011 9:18 AM, Richard Sayre wrote:
> I am logging all local host access using the following config:
>
> <Valve className="org.apache.catalina.valves.AccessLogValve"
> directory="logs" prefix="localhost_access_log." suffix=".txt"
> pattern='%h %l %u %{userObject}s %t "%r" %s %b'
> resolveHosts="false"/>
>
>
> The userObject HttpSession attribute is a Java Object and right now
> it is logging it by calling its toString method.
Right.
> I wanted to log a specific property of that object (userId) so I
> tried %{userObject.userId}s but that did not print anything.
Right. It's looking for an object in the session with the key
"userObject.userId", rather than doing what you expect, which is to
get "userObject" and then call "getUserId" on it with no arguments.
AccessLogValve doesn't do that kind of thing: it's not very smart.
(It's nice and fast, though).
> Is it possible to log properties of an object that is in session?
Not with the current code: you'd have to modify the AccessLogValve.
> I can add the information to the toString method but I want avoid
> that for now (I would have to re check the whole application 1500+
> pages to make sure that it is not called anywhere else).
Honestly, no code should be depending on the return value of toString
on any complex object. I'm not saying it doesn't happen... I'm just
saying that it /shouldn't/ happen.
Adding such a feature to AccessLogValve is certainly possible, but I'm
sure that it won't be added to the "%{...}s" syntax because of the
overhead of parsing the {...} to determine how to dereference and
navigate the object tree, etc. Such code exists: it's available
through any number of libraries and the syntax all looks the same or
similar (Java EL, etc.): it just needs to be configured to do that.
I'd be in support of a *new* escape sequence that would support this
kind of thing because I think it would be useful but it needs to be
distinct from the existing one so that it doesn't kill performance for
everyone who is already using it. To be sure, AccessLogValve is
intended to be run for every request, so speed is of the essence :)
Patches are always welcome.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6ElvQACgkQ9CaO5/Lv0PBiuQCfUErS2/N6sbJ/CgfYPmc3CSZY
ZhAAoLayLJI66d35xwsla/Y8lUboTcco
=K166
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org