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
> 
                                          

Reply via email to