Re: class specific logging level

2012-06-11 Thread aggarwal 

So, I found out the why RollingFileAppender wasn't behaving like
ConsoleAppender. Because I had mentioned a threshold level in
RollingFileAppender but not in ConsoleAppender. Removing threshold tag from
RollingFileAppender worked.


aggarwal wrote:
 
 I think I have found the solution to my problem.
 
 This thing is working with org.apache.log4j.rolling.RollingFileAppender
 but not with org.apache.log4j.RollingFileAppender
 
 Thanks for helping me out. :)
 
 
 
 Douglas E Wegscheid wrote:
 
 root being set to ERROR will not block the Myclass DEBUG; the 
 more-specific Myclass logger setting overrides the root setting.
 
 Have you actually tried this?
 
 package com.pkg;
 
 import org.apache.log4j.Logger;
 import com.other.OtherClass;
 
 public class MyClass {
   static Logger logger = Logger.getLogger(MyClass.class);
   public static void main (String[] args) {
 logger.error (MyClass error);
 logger.info (MyClass info);
 logger.debug (MyClass debug);
 OtherClass.doThings();
   }
 }
 
 --
 
 package com.other;
 import org.apache.log4j.Logger;
 
 public class OtherClass {
   static Logger logger = Logger.getLogger(OtherClass.class);
   public static void doThings () {
 logger.error (OtherClass error);
 logger.info (OtherClass info);
 logger.debug (OtherClass debug);
   }
 }
 
 --
 
 ?xml version=1.0 encoding=UTF-8 ?
 !DOCTYPE log4j:configuration SYSTEM log4j.dtd
 log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/;
  debug=true
  appender name=Log1 class=org.apache.log4j.ConsoleAppender
   layout class=org.apache.log4j.PatternLayout/
  /appender
 
  logger name=com.pkg.MyClass additivity=true
   level value=DEBUG /
  /logger
 
  root
   level value=INFO /
   appender-ref ref=Log1 /
  /root
 /log4j:configuration
 
 -- results in --
 
 MyClass error
 MyClass info
 MyClass debug
 OtherClass error
 OtherClass info
 
 
 
 
 
 
 
 

-- 
View this message in context: 
http://old.nabble.com/class-specific-logging-level-tp33974515p33992013.html
Sent from the Log4j - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

User-based logger level

2012-06-11 Thread yong . li 
Dear all,

We're about to implement a logging strategy that for different users 
different effective logger level are used. In particular, we are doing 
EJB, and we have already pushed user info onto MDC to implement this 
strategy. 

By default, the system will run using the following example logger levels 
for all users:
root = INFO
com.my.ejb1=WARNING
com.my.ejb2=INFO // different ejbs may have different default levels
...

When a system setting is enabled at runtime, we want to change 
com.my.ejb1=DEBUG, but only for a few selected users. That is, if user A 
invokes ejb1, all ejb1 log messages with level = DEBUG will be logged, 
while if another user B invokes ejb1, it uses the default setting, and 
only messages with level = WARNING will be logged. (it also honors the 
logger hierarchy, that is if we want to change the level for a package, 
all ejbs in that package behave in the same way)

We will do this on our production systems, so performance is critical.

What would be a good way to achieve this?

Kind Regards,

Yong

Re: User-based logger level

2012-06-11 Thread Jacob Kjome 


It's possible that Log4j2 supports this out of the box, but for Log4j1, the 
obvious way is to call logger.log() methods that accept an explicit 
Level/Priority [1].  Set a ThreadLocal with the Level to use and pass that 
Level to log() method.


[1] 
http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#log%28org.apache.log4j.Priority,%20java.lang.Object%29



Jake

On Mon, 11 Jun 2012 17:55:10 +0800
 yong...@agfa.com wrote:

Dear all,

We're about to implement a logging strategy that for different users 
different effective logger level are used. In particular, we are doing 
EJB, and we have already pushed user info onto MDC to implement this 
strategy. 

By default, the system will run using the following example logger levels 
for all users:

root = INFO
com.my.ejb1=WARNING
com.my.ejb2=INFO // different ejbs may have different default levels
...

When a system setting is enabled at runtime, we want to change 
com.my.ejb1=DEBUG, but only for a few selected users. That is, if user A 
invokes ejb1, all ejb1 log messages with level = DEBUG will be logged, 
while if another user B invokes ejb1, it uses the default setting, and 
only messages with level = WARNING will be logged. (it also honors the 
logger hierarchy, that is if we want to change the level for a package, 
all ejbs in that package behave in the same way)


We will do this on our production systems, so performance is critical.

What would be a good way to achieve this?

Kind Regards,

Yong



-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: User-based logger level

2012-06-11 Thread ceki 


Yours is a text-book requirement:

 http://logback.qos.ch/reasonsToSwitch.html#filters

See the docs on MDCFilter at [1].

[1]  http://logback.qos.ch/manual/filters.html#TurboFilter

--
Ceki
http://twitter.com/#!/ceki

On 11.06.2012 11:55, yong...@agfa.com wrote:

Dear all,

We're about to implement a logging strategy that for different users
different effective logger level are used. In particular, we are doing
EJB, and we have already pushed user info onto MDC to implement this
strategy.

By default, the system will run using the following example logger levels
for all users:
root = INFO
com.my.ejb1=WARNING
com.my.ejb2=INFO // different ejbs may have different default levels
...

When a system setting is enabled at runtime, we want to change
com.my.ejb1=DEBUG, but only for a few selected users. That is, if user A
invokes ejb1, all ejb1 log messages with level= DEBUG will be logged,
while if another user B invokes ejb1, it uses the default setting, and
only messages with level= WARNING will be logged. (it also honors the
logger hierarchy, that is if we want to change the level for a package,
all ejbs in that package behave in the same way)

We will do this on our production systems, so performance is critical.

What would be a good way to achieve this?

Kind Regards,

Yong




-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Re: User-based logger level

2012-06-11 Thread Christian Grobmeier 
In log4j 2.x there are tons of filters which might help here:
http://loggingtest.apache.org/log4j/2.x/manual/filters.html
(temporary domain)

Cheers
Christian

On Mon, Jun 11, 2012 at 5:28 PM, Jacob Kjome h...@visi.com wrote:

 It's possible that Log4j2 supports this out of the box, but for Log4j1, the
 obvious way is to call logger.log() methods that accept an explicit
 Level/Priority [1].  Set a ThreadLocal with the Level to use and pass that
 Level to log() method.

 [1]
 http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Category.html#log%28org.apache.log4j.Priority,%20java.lang.Object%29


 Jake


 On Mon, 11 Jun 2012 17:55:10 +0800
  yong...@agfa.com wrote:

 Dear all,

 We're about to implement a logging strategy that for different users
 different effective logger level are used. In particular, we are doing EJB,
 and we have already pushed user info onto MDC to implement this strategy.
 By default, the system will run using the following example logger levels
 for all users:
 root = INFO
 com.my.ejb1=WARNING
 com.my.ejb2=INFO // different ejbs may have different default levels
 ...

 When a system setting is enabled at runtime, we want to change
 com.my.ejb1=DEBUG, but only for a few selected users. That is, if user A
 invokes ejb1, all ejb1 log messages with level = DEBUG will be logged,
 while if another user B invokes ejb1, it uses the default setting, and only
 messages with level = WARNING will be logged. (it also honors the logger
 hierarchy, that is if we want to change the level for a package, all ejbs in
 that package behave in the same way)

 We will do this on our production systems, so performance is critical.

 What would be a good way to achieve this?

 Kind Regards,

 Yong



 -
 To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-user-h...@logging.apache.org




-- 
http://www.grobmeier.de
https://www.timeandbill.de

-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

File rolling in log4j extras

2012-06-11 Thread aanjaneya shukla 
Hi all,
I am using log4j extras for archiving the log files by fixed window rolling
policy. But the log files inside the archiving do not change their names
after rolling over though outer achieve is rolling fine. It is like:
mylog.1.log.zip has mylog.1.log and mylog.2.log.zip also has mylog.1.log.
Am I missing something here?
Thanks,
Aanjaneya

Re: User-based logger level

2012-06-11 Thread Ralph Goers 
In Log4j 2 the DynamicThresholdFilter can be specified a) globally (equivalent 
to Logback's TurboFilter) b) on a Logger c) in the Appender Reference in a 
Logger and d) on an Appender.  For your use case you could specify the 
DynamicThresholdFilter on each Logger and you would get the effect you are 
describing.  See http://loggingtest.apache.org/log4j/2.x/manual/filters.html. 
In the examples you will find an example of the four types on at least one of 
the documented Filters.

Ralph

On Jun 11, 2012, at 7:59 PM, yong...@agfa.com wrote:

 Thanks for all the nice replies. It's a good starting point for me. 
 
 We may need a bit more than out-of-the-box MDCFilter or 
 DynamicThresholdFilter, in that for different ejbs different users get the 
 DEBUG level. For example, for ejb1, user A gets DEBUG while user B gets 
 WARNING; for ejb2, user B gets DEBUG and user A get WARNING. My 
 understanding is that, for MDCFilter/DynamicThresholdFilter a user always 
 gets the same effective level for all loggers
 
 Of course, we can extend those filters to consider also the logger name. 
 However, we are a bit afraid of its performance overhead. The problem is 
 that, we cannot easily put logger names in a Map as what 
 DynamicThresholdFilter does, because the logger name can be a package name 
 (so we need to check if this name is a prefix of the fully qualified class 
 name of an EJB).
 
 Any good ideas? Am I missing something obvious?
 
 Kind Regards,
 
 Yong
 
 ceki c...@qos.ch wrote on 06/11/2012 11:59:32 PM:
 
 From: ceki c...@qos.ch
 To: Log4J Users List log4j-user@logging.apache.org
 Date: 06/12/2012 12:00 AM
 Subject: Re: User-based logger level
 
 
 Yours is a text-book requirement:
 
  http://logback.qos.ch/reasonsToSwitch.html#filters
 
 See the docs on MDCFilter at [1].
 
 [1]  http://logback.qos.ch/manual/filters.html#TurboFilter
 
 -- 
 Ceki
 http://twitter.com/#!/ceki
 
 On 11.06.2012 11:55, yong...@agfa.com wrote:
 Dear all,
 
 We're about to implement a logging strategy that for different users
 different effective logger level are used. In particular, we are doing
 EJB, and we have already pushed user info onto MDC to implement this
 strategy.
 
 By default, the system will run using the following example logger 
 levels
 for all users:
 root = INFO
 com.my.ejb1=WARNING
 com.my.ejb2=INFO // different ejbs may have different default levels
 ...
 
 When a system setting is enabled at runtime, we want to change
 com.my.ejb1=DEBUG, but only for a few selected users. That is, if user 
 A
 invokes ejb1, all ejb1 log messages with level= DEBUG will be logged,
 while if another user B invokes ejb1, it uses the default setting, and
 only messages with level= WARNING will be logged. (it also honors the
 logger hierarchy, that is if we want to change the level for a 
 package,
 all ejbs in that package behave in the same way)
 
 We will do this on our production systems, so performance is critical.
 
 What would be a good way to achieve this?
 
 Kind Regards,
 
 Yong
 
 
 
 -
 To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
 For additional commands, e-mail: log4j-user-h...@logging.apache.org