Hi Martin.
Absolutely true. And Struts doesn't reimplement it anyway. Rather the
wrapper around the logger (either JDK, log4j or other) screws up the
information that is logged. In my original mail I used JDK (java.util)
logging. Now here is an example after I switched struts to log4j:
2015-07-22 09:54:16,333 DEBUG
com.opensymphony.xwork2.util.LocalizedTextUtil.debug:73 - Resource
bundles reloaded
2015-07-22 09:54:16,786 DEBUG
org.apache.struts2.interceptor.FileUploadInterceptor.debug:73 -
Überspringe //home
2015-07-22 09:54:44,320 DEBUG
com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.debug:73
- Setting static parameters {}
Notice, that it says it was logged at debug:73 on every line. That is a
bit misleading. It's the line number and method of the logging wrapper
com.opensymphony.xwork2.util.logging.log4j2.Log4j2Logger.
The last log line was actually coming from
com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept:130.
But Lukasz Lenart said it is worked on anyway. So no big deal.
Regards,
Norbert.
PS: And yes. log4j is awesome :-)
On 21.07.2015 14:24, Martin Gainty wrote:
Morning Norbert
ceki gulcu spent years mastering the art of incorporating PatternLayouts and
different Appenders into log4j
Say you have a thread that is spiking CPU or heap when processing a particular
algo
algos code is out of reach from IDEs and you want to test it near Prod
environment (where there there are no Ides)
so you want your logging to NOT add more heap requirement and to NOT add CPU
usage
Latest 2.3 log4j release version allows asynchronous logging
imagine having a staggering 2,652,412 log messages processed/sec (or 1,715,344
log messages processed/sec windows) within the same thread
why should anyone want to duplicate these features when log4j already fulfills
those requirements?
http://logging.apache.org/log4j/2.x/
HTH
Martin
Subject: Re: Origin of struts log messages misleading
To: user@struts.apache.org
From: nhar...@gmx.at
Date: Tue, 21 Jul 2015 13:00:02 +0200
Alright. Only need to be patient then :-)
Thanks.
On 18.07.2015 19:55, Lukasz Lenart wrote:
2015-07-17 23:57 GMT+02:00 Norbert Harrer <nhar...@gmx.at>:
Hi.
I noticed, that all log messages from struts look like this:
Jul 17, 2015 11:31:39 PM com.opensymphony.xwork2.util.logging.jdk.JdkLogger
info
INFO: Parsing configuration file [struts-plugin.xml]
Jul 17, 2015 11:31:39 PM com.opensymphony.xwork2.util.logging.jdk.JdkLogger
info
INFO: Parsing configuration file [struts.xml]
Jul 17, 2015 11:31:39 PM com.opensymphony.xwork2.util.logging.jdk.JdkLogger
info
INFO: Choosing bean (struts) for (com.opensymphony.xwork2.ObjectFactory)
They are all coming from the logging wrapper
com.opensymphony.xwork2.util.logging.jdk.JdkLogger.
While this is true, wouldn't it be much more helpful if the log would show
the actual class that made the logger call?
Sometimes it's helpful to examine the source code of struts classes where
log messages come from. But that way it's very hard to find out where the
log message actually originated from.
That's why we have deprecated the existing logging layer in XWork and
switched to Log4j2 in Struts 2.5
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
