Re: Origin of struts log messages misleading
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
RE: Origin of struts log messages misleading
which is the reason I always put %L (line number) in my Log4j PatternLayout be careful with log4j cache log4j.logger.classPath.myClass = INFO, CACHE log4j.appender.CACHE=org.apache.log4j.RollingFileAppender log4j.appender.CACHE.File = ./logs/cache.log log4j.appender.CACHE.bufferedIO = false log4j.appender.CACHE.ImmediateFlush=true //never implement cache without flush if you dont RollingFileAppender will cache the original entry until its flushed Martin Subject: Re: Origin of struts log messages misleading To: user@struts.apache.org From: nhar...@gmx.at Date: Wed, 22 Jul 2015 10:12:00 +0200 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
Re: Origin of struts log messages misleading
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
RE: Origin of struts log messages misleading
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
Re: Origin of struts log messages misleading
Thanks, Martin, for your reply. But aren't you talking about my own logging messages? I was talking about the log messages from struts itself. Kindest Regards, Norbert. On 18.07.2015 02:16, Martin Gainty wrote: Norbert: you can always dig out the class name e.g. logger.getClass().getName() OR implement log4j and configure log4j.xml thusly: Configuration status=warn name=MyApp packages= Appenders File name=MyFile fileName=logs/app.log PatternLayout Pattern%2 %d %p %c{1.} [%t] %m%n/Pattern /PatternLayout /File /Appenders /Configuration Pattern of %2 is your class name http://logging.apache.org/log4j/2.x/faq.html best regards, Martin To: user@struts.apache.org From: nhar...@gmx.at Subject: Origin of struts log messages misleading Date: Fri, 17 Jul 2015 23:57:36 +0200 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. I am using: struts-2.3.24 tomcat-7.0.61 Thanks and regards, Norbert. - 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
Re: Origin of struts log messages misleading
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 -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
RE: Origin of struts log messages misleading
Norbert: you can always dig out the class name e.g. logger.getClass().getName() OR implement log4j and configure log4j.xml thusly: Configuration status=warn name=MyApp packages= Appenders File name=MyFile fileName=logs/app.log PatternLayout Pattern%2 %d %p %c{1.} [%t] %m%n/Pattern /PatternLayout /File /Appenders /Configuration Pattern of %2 is your class name http://logging.apache.org/log4j/2.x/faq.html best regards, Martin To: user@struts.apache.org From: nhar...@gmx.at Subject: Origin of struts log messages misleading Date: Fri, 17 Jul 2015 23:57:36 +0200 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. I am using: struts-2.3.24 tomcat-7.0.61 Thanks and regards, Norbert. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org