Re: Origin of struts log messages misleading

2015-07-22 Thread Norbert Harrer

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

2015-07-22 Thread Martin Gainty
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

2015-07-21 Thread Norbert Harrer

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

2015-07-21 Thread Martin Gainty
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

2015-07-18 Thread Norbert Harrer

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-18 Thread Lukasz Lenart
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

2015-07-17 Thread Martin Gainty
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
 
  

Origin of struts log messages misleading

2015-07-17 Thread Norbert Harrer

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