date:20150826

This is my main issue.  If someone, Remko maybe?, has a solution using 
composite and threshold please let me know as so far I have been unable to make 
it work using those.  My next step would be to write my own LevelRangeFilter.

Thanks,
Nick

 From: nic...@msn.com
 To: log4j-user@logging.apache.org
 Subject: RE: range filter?
 Date: Wed, 26 Aug 2015 10:41:27 -0400

 Thanks for clarifying.

 My effort to try to get the composite + threshold filter working such that I 
 can filter a single level so far has failed.  Here is my code:

 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;
 import org.apache.logging.log4j.Level;

 public class HelloWorld
 { 
 static Logger log = LogManager.getLogger(HelloWorld.class.getName());

 public static void main(String[] args)
 { 
   System.out.println(Hello, World);
   log.info(hello this is an INFO  message);
   log.warn(hello this is a WARN message);
   log.debug(hello this is a DEBUG message);
   Level level = Level.getLevel(INFOM1);
   if (level == null)
  System.out.println(Didn't find level INFOM1);
   else
 log.log(level, hello this is an INFOM1 message);
   level = Level.getLevel(INFOP1);
   if (level == null)
 System.out.println(Didn't find level INFOP1);
   else
 log.log(level, hello this is an INFOP1 message);
 }
 }

 Here is my configuration file:

 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
 /Configuration

 NOTE: The custom levels are not being found by the code as I'm seeing my 
 messages to stdout that it couldn't find INFOM1 and INFOP1.

 Any suggestion on how to get filtering of a single level working with the 
 composite filter + threshold filter?

 Thanks,
 Nick

  Subject: Re: range filter?
  From: ralph.go...@dslextreme.com
  Date: Wed, 26 Aug 2015 07:05:35 -0700
  To: log4j-user@logging.apache.org

  I apologize, you are correct. The level values do decrease.

  Regardless, your point about wanting to filter on essentially a single 
  integer value makes sense.

  Ralph

   On Aug 26, 2015, at 6:12 AM, Nicholas Duane nic...@msn.com wrote:

   Hmmm, I thought for log4j the threshold was less than or equal to the 
   level.  For instance, if the threshold is INFO then INFO and less than, 
   eg more critical like WARN ERROR and FATAL would match.  It's opposite in 
   log4net.  Regardless, this is the issue I wanted to point out.  The 
   stackoverflow article doesn't filter only INFO level, it seems it filters 
   INFO and anything between INFO and WARN but not including WARN.

   If I want just a single level then I would like a way to specify that 
   without me having to potentially go back and edit the configuration if 
   someone decides to specify a custom level via configuration or code.  The 
   LevelRangeFilter provides an easy mechanism for me to do this by 
   specifying the same level for min and max.  I guess you're suggesting I 
   could accomplish this via the composite filter and the threshold filter, 
   however, I would have to define a custom level that is one less than or 
   one more than the level I'm looking to capture so that I ensure I'm only 
   getting that one level.  I will try this out, but it would be nice to 
   have something like the LevelRangeFilter.

   Thanks,
   Nick

   Subject: Re: range filter?
   From: ralph.go...@dslextreme.com
   Date: Tue, 25 Aug 2015 22:08:01 -0700
   To: log4j-user@logging.apache.org

   No. If the custom level was 1 greater than INFO, then yes. In that case 
   you would specify your custom level instead of WARN as the level on the 
   first ThresholdFilter.

   Ralph

   On Aug 25, 2015, at 9:39 PM, Nicholas Duane nic...@msn.com wrote:

   What if someone defined a custom level one less than INFO?  Wouldn't 
   that end up in the log also?
   Thanks,Nick

    Original message 
   From: Ralph Goers ralph.go...@dslextreme.com
   Date: 08/25/2015  10:28 PM  (GMT-07:00)
   To: Log4J Users List log4j-user@logging.apache.org
   Subject: Re: range filter?

   I just did.

   Ralph

   On Aug 25, 2015, at 9:12 PM, Nicholas Duane nic...@msn.com wrote:

   That's exactly the use case I'm looking for.  I'll have to study it 
   some more.  Can you give me an example which filters out everything 
   but INFO?

Re: custom levels via configuration

On Wed, Aug 26, 2015 at 11:46 AM, Gary Gregory garydgreg...@gmail.com
wrote:

 This:

 Logger name=HelloWorld level=ALL

 is only going to match:

 static Logger log = LogManager.getLogger(HelloWorld.class.getName());

 if the class in unpackaged, which it looks it is based on this paste but I
 want to double check that you did not omit anything from the example.

 Are you using the latest version (2.3)?.

 I just added this test the other day to Git master:

 org.apache.logging.log4j.core.CustomLevelsTest

 And it shows that we can configure custom levels from a file and see them
 in code.

 So I am puzzled here.

 You could try the latest from Git master as well but I do not recall any
 fixes in this area.

 I wonder if the Appenders are processed by the configuration _before_ the
 custom levels...


My above suspicion was unfounded, see my new
test org.apache.logging.log4j.core.CustomLevelsWithFiltersTest and feel
free to provide a patch to test your desired behavior. This might be a tall
order if you are a true Java newbie ;-)

Gary


 Gary


 On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com wrote:




 On to my next problem.  I'm trying to define a custom level in
 configuration.  Not sure if it's working or not.  However, when I attempt
 to get the level for that custom level I get back null, which I wasn't
 expecting.  Here is the log4j2.xml config file:

 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
 /Configuration

 Here is my code:

 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;
 import org.apache.logging.log4j.Level;

 public class HelloWorld
 {
 static Logger log = LogManager.getLogger(HelloWorld.class.getName());

 public static void main(String[] args)
 {
   System.out.println(Hello, World);
   log.info(hello this is an INFO  message);
   log.warn(hello this is a WARN message);
   log.debug(hello this is a DEBUG message);
   Level level = Level.getLevel(INFOM1);
   if (level == null)
 System.out.println(Didn't find level INFOM1);
   else
 log.log(level, hello this is an INFOM1 message);
   level = Level.getLevel(INFOP1);
   if (level == null)
 System.out.println(Didn't find level INFOP1);
   else
 log.log(level, hello this is an INFOP1 message);
 }
 }

 Any ideas?  I obviously don't want to use Level.forName() as that will
 create the level if it doesn't exist and I want to ensure I'm pulling the
 value from the configuration.

 Thanks,
 Nick






 --
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory




-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: custom levels via configuration

We've never released a version 2.0-1.fc21 so it must be a Fedora build,
presumably based on 2.0 or some fork of it.

You need to test with version 2.3 or a 2.4-SNAPSHOT. I'll leave you to
Google how to install 2.3 on Fedora ;-)

Gary

On Wed, Aug 26, 2015 at 12:14 PM, Nicholas Duane nic...@msn.com wrote:

 First off let me admit that I'm a noob at both Linux and java, and log4j
 for that matter.

 I don't know how to package anything so my class that you see is a simple
 java class which I compiled using javac.  I then run it using 'java
 HelloWorld'.  I'm running fedora 21.  When I do a 'yum list log4j' it says
 I have 2.0-1.fc21.

 Thanks,
 Nick

  Date: Wed, 26 Aug 2015 11:46:51 -0700
  Subject: Re: custom levels via configuration
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  This:
 
  Logger name=HelloWorld level=ALL
 
  is only going to match:
 
  static Logger log = LogManager.getLogger(HelloWorld.class.getName());
 
  if the class in unpackaged, which it looks it is based on this paste but
 I
  want to double check that you did not omit anything from the example.
 
  Are you using the latest version (2.3)?.
 
  I just added this test the other day to Git master:
 
  org.apache.logging.log4j.core.CustomLevelsTest
 
  And it shows that we can configure custom levels from a file and see them
  in code.
 
  So I am puzzled here.
 
  You could try the latest from Git master as well but I do not recall any
  fixes in this area.
 
  I wonder if the Appenders are processed by the configuration _before_ the
  custom levels...
 
  Gary
 
 
  On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com wrote:
 
  
  
  
   On to my next problem.  I'm trying to define a custom level in
   configuration.  Not sure if it's working or not.  However, when I
 attempt
   to get the level for that custom level I get back null, which I wasn't
   expecting.  Here is the log4j2.xml config file:
  
   ?xml version=1.0 encoding=UTF-8?
   Configuration status=trace verbose=true
 CustomLevels
   CustomLevel name=INFOM1 intLevel=399/
   CustomLevel name=INFOP1 intLevel=401/
 /CustomLevels
 Appenders
   File name=info fileName=info.log
 PatternLayout
   Pattern%d %p %c{1.} [%t] %m%n/Pattern
 /PatternLayout
 Filters
   ThresholdFilter level=INFOM1 onMatch=DENY
 onMismatch=NEUTRAL/
   ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
 /Filters
   /File
 /Appenders
 Loggers
   Logger name=HelloWorld level=ALL
 AppenderRef ref=info/
   /Logger
   Root
   /Root
 /Loggers
   /Configuration
  
   Here is my code:
  
   import org.apache.logging.log4j.LogManager;
   import org.apache.logging.log4j.Logger;
   import org.apache.logging.log4j.Level;
  
   public class HelloWorld
   {
   static Logger log =
 LogManager.getLogger(HelloWorld.class.getName());
  
   public static void main(String[] args)
   {
 System.out.println(Hello, World);
 log.info(hello this is an INFO  message);
 log.warn(hello this is a WARN message);
 log.debug(hello this is a DEBUG message);
 Level level = Level.getLevel(INFOM1);
 if (level == null)
   System.out.println(Didn't find level INFOM1);
 else
   log.log(level, hello this is an INFOM1 message);
 level = Level.getLevel(INFOP1);
 if (level == null)
   System.out.println(Didn't find level INFOP1);
 else
   log.log(level, hello this is an INFOP1 message);
   }
   }
  
   Any ideas?  I obviously don't want to use Level.forName() as that will
   create the level if it doesn't exist and I want to ensure I'm pulling
 the
   value from the configuration.
  
   Thanks,
   Nick
  
  
 
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory





-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: custom levels via configuration

This:

Logger name=HelloWorld level=ALL

is only going to match:

static Logger log = LogManager.getLogger(HelloWorld.class.getName());

if the class in unpackaged, which it looks it is based on this paste but I
want to double check that you did not omit anything from the example.

Are you using the latest version (2.3)?.

I just added this test the other day to Git master:

org.apache.logging.log4j.core.CustomLevelsTest

And it shows that we can configure custom levels from a file and see them
in code.

So I am puzzled here.

You could try the latest from Git master as well but I do not recall any
fixes in this area.

I wonder if the Appenders are processed by the configuration _before_ the
custom levels...

Gary


On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com wrote:




 On to my next problem.  I'm trying to define a custom level in
 configuration.  Not sure if it's working or not.  However, when I attempt
 to get the level for that custom level I get back null, which I wasn't
 expecting.  Here is the log4j2.xml config file:

 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
 /Configuration

 Here is my code:

 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;
 import org.apache.logging.log4j.Level;

 public class HelloWorld
 {
 static Logger log = LogManager.getLogger(HelloWorld.class.getName());

 public static void main(String[] args)
 {
   System.out.println(Hello, World);
   log.info(hello this is an INFO  message);
   log.warn(hello this is a WARN message);
   log.debug(hello this is a DEBUG message);
   Level level = Level.getLevel(INFOM1);
   if (level == null)
 System.out.println(Didn't find level INFOM1);
   else
 log.log(level, hello this is an INFOM1 message);
   level = Level.getLevel(INFOP1);
   if (level == null)
 System.out.println(Didn't find level INFOP1);
   else
 log.log(level, hello this is an INFOP1 message);
 }
 }

 Any ideas?  I obviously don't want to use Level.forName() as that will
 create the level if it doesn't exist and I want to ensure I'm pulling the
 value from the configuration.

 Thanks,
 Nick






-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/
JUnit in Action, Second Edition http://www.manning.com/tahchiev/
Spring Batch in Action http://www.manning.com/templier/
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

custom levels via configuration




On to my next problem.  I'm trying to define a custom level in configuration.  
Not sure if it's working or not.  However, when I attempt to get the level for 
that custom level I get back null, which I wasn't expecting.  Here is the 
log4j2.xml config file:

?xml version=1.0 encoding=UTF-8?
Configuration status=trace verbose=true
  CustomLevels
CustomLevel name=INFOM1 intLevel=399/
CustomLevel name=INFOP1 intLevel=401/
  /CustomLevels
  Appenders
File name=info fileName=info.log
  PatternLayout
Pattern%d %p %c{1.} [%t] %m%n/Pattern
  /PatternLayout
  Filters
ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
  /Filters
/File
  /Appenders
  Loggers
Logger name=HelloWorld level=ALL
  AppenderRef ref=info/
/Logger
Root
/Root
  /Loggers
/Configuration

Here is my code:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.Level;

public class HelloWorld
{ 
static Logger log = LogManager.getLogger(HelloWorld.class.getName());

public static void main(String[] args)
{ 
  System.out.println(Hello, World);
  log.info(hello this is an INFO  message);
  log.warn(hello this is a WARN message);
  log.debug(hello this is a DEBUG message);
  Level level = Level.getLevel(INFOM1);
  if (level == null)
System.out.println(Didn't find level INFOM1);
  else
log.log(level, hello this is an INFOM1 message);
  level = Level.getLevel(INFOP1);
  if (level == null)
System.out.println(Didn't find level INFOP1);
  else
log.log(level, hello this is an INFOP1 message);
}
}

Any ideas?  I obviously don't want to use Level.forName() as that will create 
the level if it doesn't exist and I want to ensure I'm pulling the value from 
the configuration.

Thanks,
Nick

RE: custom levels via configuration

First off let me admit that I'm a noob at both Linux and java, and log4j for 
that matter.
 
I don't know how to package anything so my class that you see is a simple java 
class which I compiled using javac.  I then run it using 'java HelloWorld'.  
I'm running fedora 21.  When I do a 'yum list log4j' it says I have 2.0-1.fc21.
 
Thanks,
Nick
 
 Date: Wed, 26 Aug 2015 11:46:51 -0700
 Subject: Re: custom levels via configuration
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 This:
 
 Logger name=HelloWorld level=ALL
 
 is only going to match:
 
 static Logger log = LogManager.getLogger(HelloWorld.class.getName());
 
 if the class in unpackaged, which it looks it is based on this paste but I
 want to double check that you did not omit anything from the example.
 
 Are you using the latest version (2.3)?.
 
 I just added this test the other day to Git master:
 
 org.apache.logging.log4j.core.CustomLevelsTest
 
 And it shows that we can configure custom levels from a file and see them
 in code.
 
 So I am puzzled here.
 
 You could try the latest from Git master as well but I do not recall any
 fixes in this area.
 
 I wonder if the Appenders are processed by the configuration _before_ the
 custom levels...
 
 Gary
 
 
 On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com wrote:
 
 
 
 
  On to my next problem.  I'm trying to define a custom level in
  configuration.  Not sure if it's working or not.  However, when I attempt
  to get the level for that custom level I get back null, which I wasn't
  expecting.  Here is the log4j2.xml config file:
 
  ?xml version=1.0 encoding=UTF-8?
  Configuration status=trace verbose=true
CustomLevels
  CustomLevel name=INFOM1 intLevel=399/
  CustomLevel name=INFOP1 intLevel=401/
/CustomLevels
Appenders
  File name=info fileName=info.log
PatternLayout
  Pattern%d %p %c{1.} [%t] %m%n/Pattern
/PatternLayout
Filters
  ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
  ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
/Filters
  /File
/Appenders
Loggers
  Logger name=HelloWorld level=ALL
AppenderRef ref=info/
  /Logger
  Root
  /Root
/Loggers
  /Configuration
 
  Here is my code:
 
  import org.apache.logging.log4j.LogManager;
  import org.apache.logging.log4j.Logger;
  import org.apache.logging.log4j.Level;
 
  public class HelloWorld
  {
  static Logger log = LogManager.getLogger(HelloWorld.class.getName());
 
  public static void main(String[] args)
  {
System.out.println(Hello, World);
log.info(hello this is an INFO  message);
log.warn(hello this is a WARN message);
log.debug(hello this is a DEBUG message);
Level level = Level.getLevel(INFOM1);
if (level == null)
  System.out.println(Didn't find level INFOM1);
else
  log.log(level, hello this is an INFOM1 message);
level = Level.getLevel(INFOP1);
if (level == null)
  System.out.println(Didn't find level INFOP1);
else
  log.log(level, hello this is an INFOP1 message);
  }
  }
 
  Any ideas?  I obviously don't want to use Level.forName() as that will
  create the level if it doesn't exist and I want to ensure I'm pulling the
  value from the configuration.
 
  Thanks,
  Nick
 
 
 
 
 
 
 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: redefining existing levels?

On Wed, Aug 26, 2015 at 9:42 AM, Nicholas Duane nic...@msn.com wrote:

 No, I don't know what monitorInterval is.


Please see
https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

Gary


 Right now in log4net, which is where I'm redefining OFF, we have the
 log4net configuration in the application configuration file.  So it for
 instance it's a web application, touching the log4net configuration will
 restart the application domain.

 Thanks,
 Nick

  Date: Wed, 26 Aug 2015 09:32:15 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane nic...@msn.com wrote:
 
   Maybe what I'm trying to do is not that useful.  However, I'm guessing
 the
   person mucking around with things would probably feel uncomfortable
   deleting entries in the config.  If they are familiar with log4j they
 might
   feel comfortable setting the level if they think they should be turning
   things off.
  
 
  Does this mean you use Log4j with the monitorInterval Confuguration
  attribute? Or can this user also restart the application by hand for the
  new logging configuration to take effect?
 
  Gary
 
  
   Basically, we have what we'll call always on or 24x7 logging.
 This is
   about always having INFO and more critical turned on.  I'm just
 looking for
   ways to help enforce that.
  
   Thanks,
   Nick
  
Date: Wed, 26 Aug 2015 09:24:07 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
   
On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com
 wrote:
   
 I guess the main use case we're trying to solve is someone, maybe
 some
 admin or maybe a developer asking the admin, thinking they should
 turn
 logging off and thus sets the level to OFF.  We always want INFO
 and
   more
 critical levels to be on no matter what.

   
But if a user gets in a config file and sets the root level to off,
 how
   can
you stop him or her from removing your filters and custom levels?
   
Gary
   

 Thanks,
 Nick

  Subject: Re: redefining existing levels?
  To: log4j-user@logging.apache.org
  From: x...@dds.nl
  Date: Wed, 26 Aug 2015 17:55:23 +0200
 
  I think it is still unclear what you mean by below. Normally I
   would
  consider trace to be at the low end and fatal to be at the
 high
   end,
  but I don't think there is a low and high in Log4J. When you say
   below
  I take it you mean DEBUG and TRACE, but the only thing that makes
   sense
  to me is to keep INFO, ERROR and FATAL on.
 
  Regards, Bart.
 
 
 
  Op 26-8-2015 om 3:46 schreef Nicholas Duane:
   Yes and no.  The user might know how to turn on/off logging,
 but
   they
 might not understand what the enterprise is wanting to do.  We
 would
   like
 to make it hard, if not impossible, to turn off logging of INFO and
   below
 (or above for .NET) events.  So even if something thinks they
 should
   turn
 off logging and sets the level to OFF we still want INFO and
 below
   to be
 logged.
  
   Thanks,
   Nick
  
   Subject: Re: redefining existing levels?
   From: remko.po...@gmail.com
   Date: Wed, 26 Aug 2015 09:25:09 +0900
   To: log4j-user@logging.apache.org
  
   Could you explain a bit more about your use case before we
 zoom
   in on
 a specific solution?
  
   I'd like to understand better what you mean by [if someone
 sets
   the
 level to OFF]?
   What is the scenario? Someone logs into the server and
 modifies
   the
 configuration and makes a mistake? Or is this a client distributed
 to
   your
 users' PCs and they may modify the configuration?
  
   It sounds like you are trying to protect against human error;
 is
   that
 the case?
  
   Sent from my iPhone
  
   On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com
 wrote:
  
   No.  Redefining existing levels is to help ensure we have
 24x7
 logging always on.  So even if someone sets the level to OFF we
   still get
 INFO and above.  Basically we'll have levels higher (or lower
 based on
   what
 platform we're talking about) than INFO OFF by default and only
 turn
   them
 on when needed.
  
   Thanks,
   Nick
  
   Date: Wed, 26 Aug 2015 08:33:34 +0900
   Subject: Re: redefining existing levels?
   From: remko.po...@gmail.com
   To: log4j-user@logging.apache.org
  
   Is redefining levels a way to work around the issue you had
 with
 the range
   check?
   I've replied to your range check question with a link to an
   example
 config.
  
   On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
 garydgreg...@gmail.com
   wrote:
  
   Well, let's all work

Re: range filter?

On Wed, Aug 26, 2015 at 10:52 AM, Nicholas Duane nic...@msn.com wrote:

 This is my main issue.  If someone, Remko maybe?, has a solution using
 composite and threshold please let me know as so far I have been unable to
 make it work using those.  My next step would be to write my own
 LevelRangeFilter.


I think a LevelRangeFilter is a good idea anyway, so Log4j should provide
one. Writing one is easy, it's docs will take longer to write well.

Gary


 Thanks,
 Nick

  From: nic...@msn.com
  To: log4j-user@logging.apache.org
  Subject: RE: range filter?
  Date: Wed, 26 Aug 2015 10:41:27 -0400
 
  Thanks for clarifying.
 
  My effort to try to get the composite + threshold filter working such
 that I can filter a single level so far has failed.  Here is my code:
 
  import org.apache.logging.log4j.LogManager;
  import org.apache.logging.log4j.Logger;
  import org.apache.logging.log4j.Level;
 
  public class HelloWorld
  {
  static Logger log = LogManager.getLogger(HelloWorld.class.getName());
 
  public static void main(String[] args)
  {
System.out.println(Hello, World);
log.info(hello this is an INFO  message);
log.warn(hello this is a WARN message);
log.debug(hello this is a DEBUG message);
Level level = Level.getLevel(INFOM1);
if (level == null)
   System.out.println(Didn't find level INFOM1);
else
  log.log(level, hello this is an INFOM1 message);
level = Level.getLevel(INFOP1);
if (level == null)
  System.out.println(Didn't find level INFOP1);
else
  log.log(level, hello this is an INFOP1 message);
  }
  }
 
  Here is my configuration file:
 
  ?xml version=1.0 encoding=UTF-8?
  Configuration status=trace verbose=true
CustomLevels
  CustomLevel name=INFOM1 intLevel=399/
  CustomLevel name=INFOP1 intLevel=401/
/CustomLevels
Appenders
  File name=info fileName=info.log
PatternLayout
  Pattern%d %p %c{1.} [%t] %m%n/Pattern
/PatternLayout
Filters
  ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
  ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
/Filters
  /File
/Appenders
Loggers
  Logger name=HelloWorld level=ALL
AppenderRef ref=info/
  /Logger
  Root
  /Root
/Loggers
  /Configuration
 
  NOTE: The custom levels are not being found by the code as I'm seeing my
 messages to stdout that it couldn't find INFOM1 and INFOP1.
 
  Any suggestion on how to get filtering of a single level working with
 the composite filter + threshold filter?
 
  Thanks,
  Nick
 
   Subject: Re: range filter?
   From: ralph.go...@dslextreme.com
   Date: Wed, 26 Aug 2015 07:05:35 -0700
   To: log4j-user@logging.apache.org
  
   I apologize, you are correct. The level values do decrease.
  
   Regardless, your point about wanting to filter on essentially a single
 integer value makes sense.
  
   Ralph
  
On Aug 26, 2015, at 6:12 AM, Nicholas Duane nic...@msn.com wrote:
   
Hmmm, I thought for log4j the threshold was less than or equal to
 the level.  For instance, if the threshold is INFO then INFO and less than,
 eg more critical like WARN ERROR and FATAL would match.  It's opposite in
 log4net.  Regardless, this is the issue I wanted to point out.  The
 stackoverflow article doesn't filter only INFO level, it seems it filters
 INFO and anything between INFO and WARN but not including WARN.
   
If I want just a single level then I would like a way to specify
 that without me having to potentially go back and edit the configuration if
 someone decides to specify a custom level via configuration or code.  The
 LevelRangeFilter provides an easy mechanism for me to do this by specifying
 the same level for min and max.  I guess you're suggesting I could
 accomplish this via the composite filter and the threshold filter, however,
 I would have to define a custom level that is one less than or one more
 than the level I'm looking to capture so that I ensure I'm only getting
 that one level.  I will try this out, but it would be nice to have
 something like the LevelRangeFilter.
   
Thanks,
Nick
   
Subject: Re: range filter?
From: ralph.go...@dslextreme.com
Date: Tue, 25 Aug 2015 22:08:01 -0700
To: log4j-user@logging.apache.org
   
No. If the custom level was 1 greater than INFO, then yes. In that
 case you would specify your custom level instead of WARN as the level on
 the first ThresholdFilter.
   
Ralph
   
On Aug 25, 2015, at 9:39 PM, Nicholas Duane nic...@msn.com
 wrote:
   
What if someone defined a custom level one less than INFO?
 Wouldn't that end up in the log also?
Thanks,Nick
   
 Original message 
From: Ralph Goers ralph.go...@dslextreme.com
Date: 08/25/2015  10:28 PM  (GMT-07:00)
To: Log4J Users List log4j-user@logging.apache.org
Subject: Re: range filter?
   
I just

RE: custom levels via configuration

Yes I am a true noob to java and linux and log4j.

What is gitmaster?  I assume related to github somehow?  How can I see the test 
you created?  Is there a link you can provide?

Thanks,
Nick

 Date: Wed, 26 Aug 2015 12:34:45 -0700
 Subject: Re: custom levels via configuration
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org

 On Wed, Aug 26, 2015 at 11:46 AM, Gary Gregory garydgreg...@gmail.com
 wrote:

  This:

  Logger name=HelloWorld level=ALL

  is only going to match:

  static Logger log = LogManager.getLogger(HelloWorld.class.getName());

  if the class in unpackaged, which it looks it is based on this paste but I
  want to double check that you did not omit anything from the example.

  Are you using the latest version (2.3)?.

  I just added this test the other day to Git master:

  org.apache.logging.log4j.core.CustomLevelsTest

  And it shows that we can configure custom levels from a file and see them
  in code.

  So I am puzzled here.

  You could try the latest from Git master as well but I do not recall any
  fixes in this area.

  I wonder if the Appenders are processed by the configuration _before_ the
  custom levels...

 My above suspicion was unfounded, see my new
 test org.apache.logging.log4j.core.CustomLevelsWithFiltersTest and feel
 free to provide a patch to test your desired behavior. This might be a tall
 order if you are a true Java newbie ;-)

 Gary

  Gary

  On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com wrote:

  On to my next problem.  I'm trying to define a custom level in
  configuration.  Not sure if it's working or not.  However, when I attempt
  to get the level for that custom level I get back null, which I wasn't
  expecting.  Here is the log4j2.xml config file:

  ?xml version=1.0 encoding=UTF-8?
  Configuration status=trace verbose=true
CustomLevels
  CustomLevel name=INFOM1 intLevel=399/
  CustomLevel name=INFOP1 intLevel=401/
/CustomLevels
Appenders
  File name=info fileName=info.log
PatternLayout
  Pattern%d %p %c{1.} [%t] %m%n/Pattern
/PatternLayout
Filters
  ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
  ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
/Filters
  /File
/Appenders
Loggers
  Logger name=HelloWorld level=ALL
AppenderRef ref=info/
  /Logger
  Root
  /Root
/Loggers
  /Configuration

  Here is my code:

  import org.apache.logging.log4j.LogManager;
  import org.apache.logging.log4j.Logger;
  import org.apache.logging.log4j.Level;

  public class HelloWorld
  {
  static Logger log = LogManager.getLogger(HelloWorld.class.getName());

  public static void main(String[] args)
  {
System.out.println(Hello, World);
log.info(hello this is an INFO  message);
log.warn(hello this is a WARN message);
log.debug(hello this is a DEBUG message);
Level level = Level.getLevel(INFOM1);
if (level == null)
  System.out.println(Didn't find level INFOM1);
else
  log.log(level, hello this is an INFOM1 message);
level = Level.getLevel(INFOP1);
if (level == null)
  System.out.println(Didn't find level INFOP1);
else
  log.log(level, hello this is an INFOP1 message);
  }
  }

  Any ideas?  I obviously don't want to use Level.forName() as that will
  create the level if it doesn't exist and I want to ensure I'm pulling the
  value from the configuration.

  Thanks,
  Nick

  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory

 -- 
 E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
 Java Persistence with Hibernate, Second Edition
 http://www.manning.com/bauer3/
 JUnit in Action, Second Edition http://www.manning.com/tahchiev/
 Spring Batch in Action http://www.manning.com/templier/
 Blog: http://garygregory.wordpress.com
 Home: http://garygregory.com/
 Tweet! http://twitter.com/GaryGregory

Re: redefining existing levels?

On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane nic...@msn.com wrote:

 Maybe what I'm trying to do is not that useful.  However, I'm guessing the
 person mucking around with things would probably feel uncomfortable
 deleting entries in the config.  If they are familiar with log4j they might
 feel comfortable setting the level if they think they should be turning
 things off.


Does this mean you use Log4j with the monitorInterval Confuguration
attribute? Or can this user also restart the application by hand for the
new logging configuration to take effect?

Gary


 Basically, we have what we'll call always on or 24x7 logging.  This is
 about always having INFO and more critical turned on.  I'm just looking for
 ways to help enforce that.

 Thanks,
 Nick

  Date: Wed, 26 Aug 2015 09:24:07 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:
 
   I guess the main use case we're trying to solve is someone, maybe some
   admin or maybe a developer asking the admin, thinking they should turn
   logging off and thus sets the level to OFF.  We always want INFO and
 more
   critical levels to be on no matter what.
  
 
  But if a user gets in a config file and sets the root level to off, how
 can
  you stop him or her from removing your filters and custom levels?
 
  Gary
 
  
   Thanks,
   Nick
  
Subject: Re: redefining existing levels?
To: log4j-user@logging.apache.org
From: x...@dds.nl
Date: Wed, 26 Aug 2015 17:55:23 +0200
   
I think it is still unclear what you mean by below. Normally I
 would
consider trace to be at the low end and fatal to be at the high
 end,
but I don't think there is a low and high in Log4J. When you say
 below
I take it you mean DEBUG and TRACE, but the only thing that makes
 sense
to me is to keep INFO, ERROR and FATAL on.
   
Regards, Bart.
   
   
   
Op 26-8-2015 om 3:46 schreef Nicholas Duane:
 Yes and no.  The user might know how to turn on/off logging, but
 they
   might not understand what the enterprise is wanting to do.  We would
 like
   to make it hard, if not impossible, to turn off logging of INFO and
 below
   (or above for .NET) events.  So even if something thinks they should
 turn
   off logging and sets the level to OFF we still want INFO and below
 to be
   logged.

 Thanks,
 Nick

 Subject: Re: redefining existing levels?
 From: remko.po...@gmail.com
 Date: Wed, 26 Aug 2015 09:25:09 +0900
 To: log4j-user@logging.apache.org

 Could you explain a bit more about your use case before we zoom
 in on
   a specific solution?

 I'd like to understand better what you mean by [if someone sets
 the
   level to OFF]?
 What is the scenario? Someone logs into the server and modifies
 the
   configuration and makes a mistake? Or is this a client distributed to
 your
   users' PCs and they may modify the configuration?

 It sounds like you are trying to protect against human error; is
 that
   the case?

 Sent from my iPhone

 On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

 No.  Redefining existing levels is to help ensure we have 24x7
   logging always on.  So even if someone sets the level to OFF we
 still get
   INFO and above.  Basically we'll have levels higher (or lower based on
 what
   platform we're talking about) than INFO OFF by default and only turn
 them
   on when needed.

 Thanks,
 Nick

 Date: Wed, 26 Aug 2015 08:33:34 +0900
 Subject: Re: redefining existing levels?
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org

 Is redefining levels a way to work around the issue you had with
   the range
 check?
 I've replied to your range check question with a link to an
 example
   config.

 On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
   garydgreg...@gmail.com
 wrote:

 Well, let's all work together to get you up and running.
 Hopefully
   we'll
 get other devs to keep chiming in.


 Gary

 On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane 
 nic...@msn.com
   wrote:

 I will get to that.  However, I assume that works as that's
   documented
 pretty well.  So I'm looking at the other things which may or
 may
   not
 work
 as I have to find out what blocking issues we're going to run
   into.
 Redefining existing levels is one.  I sent the other email
   regarding
 range
 level filter as we also need that to work.  It works in
 .NET.  So
   far
 it's
 looking like I'll need to write my own filter for log4j2 in
 order
   to get
 range level filtering working.

 Thanks,
 Nick

 Date: Tue, 25 Aug 2015 15:54:08 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To:

Re: redefining existing levels?

Can’t you just put a comment in the config file that states the minimum logging 
level is info and that it is not to be changed under any circumstances?

Ralph

 On Aug 26, 2015, at 9:27 AM, Nicholas Duane nic...@msn.com wrote:
 
 Maybe what I'm trying to do is not that useful.  However, I'm guessing the 
 person mucking around with things would probably feel uncomfortable deleting 
 entries in the config.  If they are familiar with log4j they might feel 
 comfortable setting the level if they think they should be turning things off.
 
 Basically, we have what we'll call always on or 24x7 logging.  This is 
 about always having INFO and more critical turned on.  I'm just looking for 
 ways to help enforce that.
 
 Thanks,
 Nick
 
 Date: Wed, 26 Aug 2015 09:24:07 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:
 
 I guess the main use case we're trying to solve is someone, maybe some
 admin or maybe a developer asking the admin, thinking they should turn
 logging off and thus sets the level to OFF.  We always want INFO and more
 critical levels to be on no matter what.
 
 
 But if a user gets in a config file and sets the root level to off, how can
 you stop him or her from removing your filters and custom levels?
 
 Gary
 
 
 Thanks,
 Nick
 
 Subject: Re: redefining existing levels?
 To: log4j-user@logging.apache.org
 From: x...@dds.nl
 Date: Wed, 26 Aug 2015 17:55:23 +0200
 
 I think it is still unclear what you mean by below. Normally I would
 consider trace to be at the low end and fatal to be at the high end,
 but I don't think there is a low and high in Log4J. When you say below
 I take it you mean DEBUG and TRACE, but the only thing that makes sense
 to me is to keep INFO, ERROR and FATAL on.
 
 Regards, Bart.
 
 
 
 Op 26-8-2015 om 3:46 schreef Nicholas Duane:
 Yes and no.  The user might know how to turn on/off logging, but they
 might not understand what the enterprise is wanting to do.  We would like
 to make it hard, if not impossible, to turn off logging of INFO and below
 (or above for .NET) events.  So even if something thinks they should turn
 off logging and sets the level to OFF we still want INFO and below to be
 logged.
 
 Thanks,
 Nick
 
 Subject: Re: redefining existing levels?
 From: remko.po...@gmail.com
 Date: Wed, 26 Aug 2015 09:25:09 +0900
 To: log4j-user@logging.apache.org
 
 Could you explain a bit more about your use case before we zoom in on
 a specific solution?
 
 I'd like to understand better what you mean by [if someone sets the
 level to OFF]?
 What is the scenario? Someone logs into the server and modifies the
 configuration and makes a mistake? Or is this a client distributed to your
 users' PCs and they may modify the configuration?
 
 It sounds like you are trying to protect against human error; is that
 the case?
 
 Sent from my iPhone
 
 On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:
 
 No.  Redefining existing levels is to help ensure we have 24x7
 logging always on.  So even if someone sets the level to OFF we still get
 INFO and above.  Basically we'll have levels higher (or lower based on what
 platform we're talking about) than INFO OFF by default and only turn them
 on when needed.
 
 Thanks,
 Nick
 
 Date: Wed, 26 Aug 2015 08:33:34 +0900
 Subject: Re: redefining existing levels?
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org
 
 Is redefining levels a way to work around the issue you had with
 the range
 check?
 I've replied to your range check question with a link to an example
 config.
 
 On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
 garydgreg...@gmail.com
 wrote:
 
 Well, let's all work together to get you up and running. Hopefully
 we'll
 get other devs to keep chiming in.
 
 
 Gary
 
 On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
 wrote:
 
 I will get to that.  However, I assume that works as that's
 documented
 pretty well.  So I'm looking at the other things which may or may
 not
 work
 as I have to find out what blocking issues we're going to run
 into.
 Redefining existing levels is one.  I sent the other email
 regarding
 range
 level filter as we also need that to work.  It works in .NET.  So
 far
 it's
 looking like I'll need to write my own filter for log4j2 in order
 to get
 range level filtering working.
 
 Thanks,
 Nick
 
 Date: Tue, 25 Aug 2015 15:54:08 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 Ah, well, let's start with the documented stuff we know should
 work ;-)
 
 Gary
 
 On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com
 wrote:
 Thanks.  I assumed my 'BUSINESS' level is working using the
 CustomLevel,
 though I haven't tried it yet as I was trying to validate
 redefining
 existing level.
 
 Thanks,
 Nick
 
 Date: Tue, 25 Aug 2015 14:32:01 -0700
 Subject: Re:

Re: redefining existing levels?

On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:

I guess the main use case we're trying to solve is someone, maybe some
admin or maybe a developer asking the admin, thinking they should turn
logging off and thus sets the level to OFF. We always want INFO and more
critical levels to be on no matter what.

But if a user gets in a config file and sets the root level to off, how can
you stop him or her from removing your filters and custom levels?

Gary

Thanks,
Nick

Subject: Re: redefining existing levels?
To: log4j-user@logging.apache.org
From: x...@dds.nl
Date: Wed, 26 Aug 2015 17:55:23 +0200

I think it is still unclear what you mean by below. Normally I would
consider trace to be at the low end and fatal to be at the high end,
but I don't think there is a low and high in Log4J. When you say below
I take it you mean DEBUG and TRACE, but the only thing that makes sense
to me is to keep INFO, ERROR and FATAL on.

Regards, Bart.

Op 26-8-2015 om 3:46 schreef Nicholas Duane:
Yes and no. The user might know how to turn on/off logging, but they
might not understand what the enterprise is wanting to do. We would like
to make it hard, if not impossible, to turn off logging of INFO and below
(or above for .NET) events. So even if something thinks they should turn
off logging and sets the level to OFF we still want INFO and below to be
logged.

Thanks,
Nick

Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on
a specific solution?

I'd like to understand better what you mean by [if someone sets the
level to OFF]?
What is the scenario? Someone logs into the server and modifies the
configuration and makes a mistake? Or is this a client distributed to your
users' PCs and they may modify the configuration?

It sounds like you are trying to protect against human error; is that
the case?

Sent from my iPhone

On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

No. Redefining existing levels is to help ensure we have 24x7
logging always on. So even if someone sets the level to OFF we still get
INFO and above. Basically we'll have levels higher (or lower based on what
platform we're talking about) than INFO OFF by default and only turn them
on when needed.

Thanks,
Nick

Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with
the range
check?
I've replied to your range check question with a link to an example
config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory
garydgreg...@gmail.com
wrote:

Well, let's all work together to get you up and running. Hopefully
we'll
get other devs to keep chiming in.

Gary

On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
wrote:

I will get to that. However, I assume that works as that's
documented
pretty well. So I'm looking at the other things which may or may
not
work
as I have to find out what blocking issues we're going to run
into.
Redefining existing levels is one. I sent the other email
regarding
range
level filter as we also need that to work. It works in .NET. So
far
it's
looking like I'll need to write my own filter for log4j2 in order
to get
range level filtering working.

Thanks,
Nick

Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should
work ;-)

Gary

On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com
wrote:
Thanks. I assumed my 'BUSINESS' level is working using the
CustomLevel,
though I haven't tried it yet as I was trying to validate
redefining
existing level.

Thanks,
Nick

Date: Tue, 25 Aug 2015 14:32:01 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Nick,

Your BUSINESS level should be configurable per

https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration
I can't look into the rest ATM.

Gary

On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane
nic...@msn.com
wrote:
I guess I should have mentioned, though it's probably obvious,
that I'm
only interested in a configuration based solution. I'm not
looking
for a
code solution.

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Tue, 25 Aug 2015 16:05:47 -0400

Thanks

RE: redefining existing levels?

I should have add:

ways to enforce that via configuration.  We don't want to do it via code and 
we don't want to have to rely on some of our code being run at startup.

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Wed, 26 Aug 2015 12:27:16 -0400

Maybe what I'm trying to do is not that useful.  However, I'm guessing the 
person mucking around with things would probably feel uncomfortable deleting 
entries in the config.  If they are familiar with log4j they might feel 
comfortable setting the level if they think they should be turning things off.

Basically, we have what we'll call always on or 24x7 logging.  This is 
about always having INFO and more critical turned on.  I'm just looking for 
ways to help enforce that.

Thanks,
Nick

 Date: Wed, 26 Aug 2015 09:24:07 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org

 On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:

  I guess the main use case we're trying to solve is someone, maybe some
  admin or maybe a developer asking the admin, thinking they should turn
  logging off and thus sets the level to OFF.  We always want INFO and more
  critical levels to be on no matter what.

 But if a user gets in a config file and sets the root level to off, how can
 you stop him or her from removing your filters and custom levels?

 Gary

  Thanks,
  Nick

   Subject: Re: redefining existing levels?
   To: log4j-user@logging.apache.org
   From: x...@dds.nl
   Date: Wed, 26 Aug 2015 17:55:23 +0200

   I think it is still unclear what you mean by below. Normally I would
   consider trace to be at the low end and fatal to be at the high end,
   but I don't think there is a low and high in Log4J. When you say below
   I take it you mean DEBUG and TRACE, but the only thing that makes sense
   to me is to keep INFO, ERROR and FATAL on.

   Regards, Bart.

   Op 26-8-2015 om 3:46 schreef Nicholas Duane:
Yes and no.  The user might know how to turn on/off logging, but they
  might not understand what the enterprise is wanting to do.  We would like
  to make it hard, if not impossible, to turn off logging of INFO and below
  (or above for .NET) events.  So even if something thinks they should turn
  off logging and sets the level to OFF we still want INFO and below to be
  logged.

Thanks,
Nick

Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on
  a specific solution?

I'd like to understand better what you mean by [if someone sets the
  level to OFF]?
What is the scenario? Someone logs into the server and modifies the
  configuration and makes a mistake? Or is this a client distributed to your
  users' PCs and they may modify the configuration?

It sounds like you are trying to protect against human error; is that
  the case?

Sent from my iPhone

On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

No.  Redefining existing levels is to help ensure we have 24x7
  logging always on.  So even if someone sets the level to OFF we still get
  INFO and above.  Basically we'll have levels higher (or lower based on what
  platform we're talking about) than INFO OFF by default and only turn them
  on when needed.

Thanks,
Nick

Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with
  the range
check?
I've replied to your range check question with a link to an example
  config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
  garydgreg...@gmail.com
wrote:

Well, let's all work together to get you up and running. Hopefully
  we'll
get other devs to keep chiming in.

Gary

On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
  wrote:

I will get to that.  However, I assume that works as that's
  documented
pretty well.  So I'm looking at the other things which may or may
  not
work
as I have to find out what blocking issues we're going to run
  into.
Redefining existing levels is one.  I sent the other email
  regarding
range
level filter as we also need that to work.  It works in .NET.  So
  far
it's
looking like I'll need to write my own filter for log4j2 in order
  to get
range level filtering working.

Thanks,
Nick

Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should
  work ;-)

Re: redefining existing levels?

On Wed, Aug 26, 2015 at 9:31 AM, Ralph Goers ralph.go...@dslextreme.com
wrote:

 Can’t you just put a comment in the config file that states the minimum
 logging level is info and that it is not to be changed under any
 circumstances?


That seems to obvious! :-)

Another interesting but complex alternative would be to use a custom XML
Schema to validate the XML configuration file. If the validation fails,
we'd need to make sure we do not process the file any further. XML Schemas
are not easy to write though but can be automatically generated by some
tools.


Gary


 Ralph

  On Aug 26, 2015, at 9:27 AM, Nicholas Duane nic...@msn.com wrote:
 
  Maybe what I'm trying to do is not that useful.  However, I'm guessing
 the person mucking around with things would probably feel uncomfortable
 deleting entries in the config.  If they are familiar with log4j they might
 feel comfortable setting the level if they think they should be turning
 things off.
 
  Basically, we have what we'll call always on or 24x7 logging.  This
 is about always having INFO and more critical turned on.  I'm just looking
 for ways to help enforce that.
 
  Thanks,
  Nick
 
  Date: Wed, 26 Aug 2015 09:24:07 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:
 
  I guess the main use case we're trying to solve is someone, maybe some
  admin or maybe a developer asking the admin, thinking they should turn
  logging off and thus sets the level to OFF.  We always want INFO and
 more
  critical levels to be on no matter what.
 
 
  But if a user gets in a config file and sets the root level to off, how
 can
  you stop him or her from removing your filters and custom levels?
 
  Gary
 
 
  Thanks,
  Nick
 
  Subject: Re: redefining existing levels?
  To: log4j-user@logging.apache.org
  From: x...@dds.nl
  Date: Wed, 26 Aug 2015 17:55:23 +0200
 
  I think it is still unclear what you mean by below. Normally I would
  consider trace to be at the low end and fatal to be at the high
 end,
  but I don't think there is a low and high in Log4J. When you say
 below
  I take it you mean DEBUG and TRACE, but the only thing that makes
 sense
  to me is to keep INFO, ERROR and FATAL on.
 
  Regards, Bart.
 
 
 
  Op 26-8-2015 om 3:46 schreef Nicholas Duane:
  Yes and no.  The user might know how to turn on/off logging, but they
  might not understand what the enterprise is wanting to do.  We would
 like
  to make it hard, if not impossible, to turn off logging of INFO and
 below
  (or above for .NET) events.  So even if something thinks they should
 turn
  off logging and sets the level to OFF we still want INFO and below
 to be
  logged.
 
  Thanks,
  Nick
 
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  Date: Wed, 26 Aug 2015 09:25:09 +0900
  To: log4j-user@logging.apache.org
 
  Could you explain a bit more about your use case before we zoom in
 on
  a specific solution?
 
  I'd like to understand better what you mean by [if someone sets the
  level to OFF]?
  What is the scenario? Someone logs into the server and modifies the
  configuration and makes a mistake? Or is this a client distributed to
 your
  users' PCs and they may modify the configuration?
 
  It sounds like you are trying to protect against human error; is
 that
  the case?
 
  Sent from my iPhone
 
  On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:
 
  No.  Redefining existing levels is to help ensure we have 24x7
  logging always on.  So even if someone sets the level to OFF we
 still get
  INFO and above.  Basically we'll have levels higher (or lower based on
 what
  platform we're talking about) than INFO OFF by default and only turn
 them
  on when needed.
 
  Thanks,
  Nick
 
  Date: Wed, 26 Aug 2015 08:33:34 +0900
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
 
  Is redefining levels a way to work around the issue you had with
  the range
  check?
  I've replied to your range check question with a link to an
 example
  config.
 
  On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
  garydgreg...@gmail.com
  wrote:
 
  Well, let's all work together to get you up and running.
 Hopefully
  we'll
  get other devs to keep chiming in.
 
 
  Gary
 
  On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
 
  wrote:
 
  I will get to that.  However, I assume that works as that's
  documented
  pretty well.  So I'm looking at the other things which may or
 may
  not
  work
  as I have to find out what blocking issues we're going to run
  into.
  Redefining existing levels is one.  I sent the other email
  regarding
  range
  level filter as we also need that to work.  It works in .NET.
 So
  far
  it's
  looking like I'll need to write my own filter for log4j2 in
 order
  to get
  range level filtering working.
 
  Thanks,
  Nick
 
  Date: Tue, 25

Re: redefining existing levels?

2015-08-26 Thread Xen

I think it is still unclear what you mean by below. Normally I would 
consider trace to be at the low end and fatal to be at the high end, 
but I don't think there is a low and high in Log4J. When you say below 
I take it you mean DEBUG and TRACE, but the only thing that makes sense 
to me is to keep INFO, ERROR and FATAL on.


Regards, Bart.



Op 26-8-2015 om 3:46 schreef Nicholas Duane:

Yes and no.  The user might know how to turn on/off logging, but they might not 
understand what the enterprise is wanting to do.  We would like to make it hard, if not 
impossible, to turn off logging of INFO and below (or above for .NET) events.  So even if 
something thinks they should turn off logging and sets the level to OFF we 
still want INFO and below to be logged.
  
Thanks,

Nick
  

Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on a 
specific solution?

I'd like to understand better what you mean by [if someone sets the level to 
OFF]?
What is the scenario? Someone logs into the server and modifies the 
configuration and makes a mistake? Or is this a client distributed to your 
users' PCs and they may modify the configuration?

It sounds like you are trying to protect against human error; is that the case?

Sent from my iPhone


On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

No.  Redefining existing levels is to help ensure we have 24x7 logging always on.  So 
even if someone sets the level to OFF we still get INFO and above.  Basically we'll 
have levels higher (or lower based on what platform we're talking about) than INFO OFF by default 
and only turn them on when needed.

Thanks,
Nick


Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with the range
check?
I've replied to your range check question with a link to an example config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory garydgreg...@gmail.com
wrote:


Well, let's all work together to get you up and running. Hopefully we'll
get other devs to keep chiming in.


Gary


On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com wrote:

I will get to that.  However, I assume that works as that's documented
pretty well.  So I'm looking at the other things which may or may not

work

as I have to find out what blocking issues we're going to run into.
Redefining existing levels is one.  I sent the other email regarding

range

level filter as we also need that to work.  It works in .NET.  So far

it's

looking like I'll need to write my own filter for log4j2 in order to get
range level filtering working.

Thanks,
Nick


Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should work ;-)

Gary

On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com

wrote:

Thanks.  I assumed my 'BUSINESS' level is working using the

CustomLevel,

though I haven't tried it yet as I was trying to validate redefining
existing level.

Thanks,
Nick


Date: Tue, 25 Aug 2015 14:32:01 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Nick,

Your BUSINESS level should be configurable per

https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration

I can't look into the rest ATM.

Gary

On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane nic...@msn.com

wrote:

I guess I should have mentioned, though it's probably obvious,

that I'm

only interested in a configuration based solution.  I'm not

looking

for a

code solution.

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Tue, 25 Aug 2015 16:05:47 -0400




Thanks for the reply.  I've seen that documentation and it

appears

to

be

geared toward defining (NEW) custom levels.  It doesn't mention

anything

about redefining existing log4j2 levels.  I also tried it and so

far

in my

testing it doesn't seem to work.  Below is a snippet of my

config.  By

the

way, you'll see that I am currently trying the CustomLevel and

level.

At first I had just tried CustomLevel but it didn't appear to

work

so I

thought I would put the same elements I have in my .NET config

which

work.

Unfortunately it still doesn't work.

.
.
.
level
   name value=OFF/
   value value=500/
/level
CustomLevels
   CustomLevel name=OFF intLevel=500/
/CustomLevels
.
.
.
Loggers
   Logger name=HelloWorld level=OFF
  AppenderRef ref=debug/
   /Logger
   Root
   /Root
/Loggers

I then set my logger level to OFF and didn't see any debug

events

show

up.  If I set the level to DEBUG they show up in the log.  The

docs

Re: redefining existing levels?

Well, I suppose we could add a minimum logging level system property and if
someone tries to set the level lower than that then the minimum level gets used
instead. But I’m not really crazy about that as it could cause all kinds of
“unexpected” consequences when processing the configuration.

It seems to me that the real issue is that people have access to your
production machines who probably shouldn’t.

Ralph

On Aug 26, 2015, at 9:24 AM, Gary Gregory garydgreg...@gmail.com wrote:

On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com
mailto:nic...@msn.com wrote:

But if a user gets in a config file and sets the root level to off, how can
you stop him or her from removing your filters and custom levels?

Gary

Thanks,
Nick

Subject: Re: redefining existing levels?
To: log4j-user@logging.apache.org
From: x...@dds.nl
Date: Wed, 26 Aug 2015 17:55:23 +0200

Regards, Bart.

Thanks,
Nick

Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on
a specific solution?

It sounds like you are trying to protect against human error; is that
the case?

Sent from my iPhone

On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

Thanks,
Nick

Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with
the range
check?
I've replied to your range check question with a link to an example
config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory
garydgreg...@gmail.com
wrote:

Well, let's all work together to get you up and running. Hopefully
we'll
get other devs to keep chiming in.

Gary

On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
wrote:

Thanks,
Nick

Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should
work ;-)

Gary

Thanks,
Nick

Date: Tue, 25 Aug 2015 14:32:01 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Nick,

Your BUSINESS level should be configurable per

https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration
I can't look into the rest ATM.

Gary

On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane
nic...@msn.com
wrote:
I guess I

Re: redefining existing levels?

2015-08-26 Thread Xen


Op 26-8-2015 om 5:43 schreef Gary Gregory:

On Tue, Aug 25, 2015 at 7:59 PM, Remko Popma remko.po...@gmail.com wrote:


How are users currently able to set the log level to OFF? Do they modify
the config?


Right, isn't the only way to enforce this is to override the config file
programatically?

Gary


And are you not the one who allows your users this functionality? Or do 
they get to set a dedicated config script? Can't your user actions 
simply be filtered or disallowed, or not even presented?.


Or are your users programmers?.



Sent from my iPhone


On 2015/08/26, at 11:35, Nicholas Duane nic...@msn.com wrote:

It just dawned on me that my solution of redefining OFF to the INFO

level only addresses the case of someone setting the level to OFF.  Someone
could set the level to ERROR.

As I mentioned, what I'm trying to do is enforce, via configuration

only, not being able to turn of logging of INFO and below levels.

Thanks,Nick

 Original message 
From: Nicholas Duane nic...@msn.com
Date: 08/25/2015  7:46 PM  (GMT-07:00)
To: Log4J Users List log4j-user@logging.apache.org
Subject: RE: redefining existing levels?

Yes and no.  The user might know how to turn on/off logging, but they

might not understand what the enterprise is wanting to do.  We would like
to make it hard, if not impossible, to turn off logging of INFO and below
(or above for .NET) events.  So even if something thinks they should turn
off logging and sets the level to OFF we still want INFO and below to be
logged.

Thanks,
Nick


Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on a

specific solution?

I'd like to understand better what you mean by [if someone sets the

level to OFF]?

What is the scenario? Someone logs into the server and modifies the

configuration and makes a mistake? Or is this a client distributed to your
users' PCs and they may modify the configuration?

It sounds like you are trying to protect against human error; is that

the case?

Sent from my iPhone


On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

No.  Redefining existing levels is to help ensure we have 24x7

logging always on.  So even if someone sets the level to OFF we still get
INFO and above.  Basically we'll have levels higher (or lower based on what
platform we're talking about) than INFO OFF by default and only turn them
on when needed.

Thanks,
Nick


Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with the

range

check?
I've replied to your range check question with a link to an example

config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory garydgreg...@gmail.com
wrote:


Well, let's all work together to get you up and running. Hopefully

we'll

get other devs to keep chiming in.


Gary


On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com

wrote:

I will get to that.  However, I assume that works as that's

documented

pretty well.  So I'm looking at the other things which may or may

not

work

as I have to find out what blocking issues we're going to run into.
Redefining existing levels is one.  I sent the other email regarding

range

level filter as we also need that to work.  It works in .NET.  So

far

it's

looking like I'll need to write my own filter for log4j2 in order

to get

range level filtering working.

Thanks,
Nick


Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should

work ;-)

Gary

On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com

wrote:

Thanks.  I assumed my 'BUSINESS' level is working using the

CustomLevel,

though I haven't tried it yet as I was trying to validate

redefining

existing level.

Thanks,
Nick


Date: Tue, 25 Aug 2015 14:32:01 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Nick,

Your BUSINESS level should be configurable per

https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration

I can't look into the rest ATM.

Gary

On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane nic...@msn.com

wrote:

I guess I should have mentioned, though it's probably obvious,

that I'm

only interested in a configuration based solution.  I'm not

looking

for a

code solution.

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Tue, 25 Aug 2015 16:05:47 -0400




Thanks for the reply.  I've seen that documentation and it

appears

to

be

geared toward defining (NEW) custom levels.  It doesn't mention

anything

about redefining existing

RE: redefining existing levels?

I guess the main use case we're trying to solve is someone, maybe some admin or
maybe a developer asking the admin, thinking they should turn logging off and
thus sets the level to OFF. We always want INFO and more critical levels to
be on no matter what.

Thanks,
Nick

Subject: Re: redefining existing levels?
To: log4j-user@logging.apache.org
From: x...@dds.nl
Date: Wed, 26 Aug 2015 17:55:23 +0200

Regards, Bart.

Op 26-8-2015 om 3:46 schreef Nicholas Duane:
Yes and no. The user might know how to turn on/off logging, but they might
not understand what the enterprise is wanting to do. We would like to make
it hard, if not impossible, to turn off logging of INFO and below (or above
for .NET) events. So even if something thinks they should turn off logging
and sets the level to OFF we still want INFO and below to be logged.

Thanks,
Nick

Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org

Could you explain a bit more about your use case before we zoom in on a
specific solution?

I'd like to understand better what you mean by [if someone sets the level
to OFF]?
What is the scenario? Someone logs into the server and modifies the
configuration and makes a mistake? Or is this a client distributed to your
users' PCs and they may modify the configuration?

It sounds like you are trying to protect against human error; is that the
case?

Sent from my iPhone

On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

No. Redefining existing levels is to help ensure we have 24x7 logging
always on. So even if someone sets the level to OFF we still get INFO
and above. Basically we'll have levels higher (or lower based on what
platform we're talking about) than INFO OFF by default and only turn them
on when needed.

Thanks,
Nick

Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org

Is redefining levels a way to work around the issue you had with the
range
check?
I've replied to your range check question with a link to an example
config.

On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory garydgreg...@gmail.com
wrote:

Well, let's all work together to get you up and running. Hopefully we'll
get other devs to keep chiming in.

Gary

On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com wrote:

I will get to that. However, I assume that works as that's documented
pretty well. So I'm looking at the other things which may or may not
work
as I have to find out what blocking issues we're going to run into.
Redefining existing levels is one. I sent the other email regarding
range
level filter as we also need that to work. It works in .NET. So far
it's
looking like I'll need to write my own filter for log4j2 in order to
get
range level filtering working.

Thanks,
Nick

Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Ah, well, let's start with the documented stuff we know should work
;-)

Gary

Thanks,
Nick

Date: Tue, 25 Aug 2015 14:32:01 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org

Nick,

Your BUSINESS level should be configurable per
https://logging.apache.org/log4j/2.x/manual/customloglevels.html#DefiningLevelsInConfiguration
I can't look into the rest ATM.

Gary

On Tue, Aug 25, 2015 at 2:16 PM, Nicholas Duane nic...@msn.com
wrote:
I guess I should have mentioned, though it's probably obvious,
that I'm
only interested in a configuration based solution. I'm not
looking
for a
code solution.

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: redefining existing levels?
Date: Tue, 25 Aug 2015 16:05:47 -0400

Thanks for the reply. I've seen that documentation and it
appears
to
be
geared toward defining (NEW) custom levels. It doesn't mention
anything
about redefining existing log4j2 levels. I also tried it and so
far
in my
testing it doesn't seem to work. Below is a snippet of my
config. By
the

RE: redefining existing levels?

Maybe what I'm trying to do is not that useful.  However, I'm guessing the 
person mucking around with things would probably feel uncomfortable deleting 
entries in the config.  If they are familiar with log4j they might feel 
comfortable setting the level if they think they should be turning things off.
 
Basically, we have what we'll call always on or 24x7 logging.  This is 
about always having INFO and more critical turned on.  I'm just looking for 
ways to help enforce that.
 
Thanks,
Nick
 
 Date: Wed, 26 Aug 2015 09:24:07 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:
 
  I guess the main use case we're trying to solve is someone, maybe some
  admin or maybe a developer asking the admin, thinking they should turn
  logging off and thus sets the level to OFF.  We always want INFO and more
  critical levels to be on no matter what.
 
 
 But if a user gets in a config file and sets the root level to off, how can
 you stop him or her from removing your filters and custom levels?
 
 Gary
 
 
  Thanks,
  Nick
 
   Subject: Re: redefining existing levels?
   To: log4j-user@logging.apache.org
   From: x...@dds.nl
   Date: Wed, 26 Aug 2015 17:55:23 +0200
  
   I think it is still unclear what you mean by below. Normally I would
   consider trace to be at the low end and fatal to be at the high end,
   but I don't think there is a low and high in Log4J. When you say below
   I take it you mean DEBUG and TRACE, but the only thing that makes sense
   to me is to keep INFO, ERROR and FATAL on.
  
   Regards, Bart.
  
  
  
   Op 26-8-2015 om 3:46 schreef Nicholas Duane:
Yes and no.  The user might know how to turn on/off logging, but they
  might not understand what the enterprise is wanting to do.  We would like
  to make it hard, if not impossible, to turn off logging of INFO and below
  (or above for .NET) events.  So even if something thinks they should turn
  off logging and sets the level to OFF we still want INFO and below to be
  logged.
   
Thanks,
Nick
   
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org
   
Could you explain a bit more about your use case before we zoom in on
  a specific solution?
   
I'd like to understand better what you mean by [if someone sets the
  level to OFF]?
What is the scenario? Someone logs into the server and modifies the
  configuration and makes a mistake? Or is this a client distributed to your
  users' PCs and they may modify the configuration?
   
It sounds like you are trying to protect against human error; is that
  the case?
   
Sent from my iPhone
   
On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:
   
No.  Redefining existing levels is to help ensure we have 24x7
  logging always on.  So even if someone sets the level to OFF we still get
  INFO and above.  Basically we'll have levels higher (or lower based on what
  platform we're talking about) than INFO OFF by default and only turn them
  on when needed.
   
Thanks,
Nick
   
Date: Wed, 26 Aug 2015 08:33:34 +0900
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
To: log4j-user@logging.apache.org
   
Is redefining levels a way to work around the issue you had with
  the range
check?
I've replied to your range check question with a link to an example
  config.
   
On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
  garydgreg...@gmail.com
wrote:
   
Well, let's all work together to get you up and running. Hopefully
  we'll
get other devs to keep chiming in.
   
   
Gary
   
On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
  wrote:
   
I will get to that.  However, I assume that works as that's
  documented
pretty well.  So I'm looking at the other things which may or may
  not
work
as I have to find out what blocking issues we're going to run
  into.
Redefining existing levels is one.  I sent the other email
  regarding
range
level filter as we also need that to work.  It works in .NET.  So
  far
it's
looking like I'll need to write my own filter for log4j2 in order
  to get
range level filtering working.
   
Thanks,
Nick
   
Date: Tue, 25 Aug 2015 15:54:08 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
   
Ah, well, let's start with the documented stuff we know should
  work ;-)
   
Gary
   
On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com
wrote:
Thanks.  I assumed my 'BUSINESS' level is working using the
CustomLevel,
though I haven't tried it yet as I was trying to validate
  redefining
existing level.
   
Thanks,
Nick
   
Date: Tue, 25 Aug 2015

RE: redefining existing levels?

No, I don't know what monitorInterval is.  Right now in log4net, which is 
where I'm redefining OFF, we have the log4net configuration in the application 
configuration file.  So it for instance it's a web application, touching the 
log4net configuration will restart the application domain.

Thanks,
Nick

 Date: Wed, 26 Aug 2015 09:32:15 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org

 On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane nic...@msn.com wrote:

  Maybe what I'm trying to do is not that useful.  However, I'm guessing the
  person mucking around with things would probably feel uncomfortable
  deleting entries in the config.  If they are familiar with log4j they might
  feel comfortable setting the level if they think they should be turning
  things off.

 Does this mean you use Log4j with the monitorInterval Confuguration
 attribute? Or can this user also restart the application by hand for the
 new logging configuration to take effect?

 Gary

  Basically, we have what we'll call always on or 24x7 logging.  This is
  about always having INFO and more critical turned on.  I'm just looking for
  ways to help enforce that.

  Thanks,
  Nick

   Date: Wed, 26 Aug 2015 09:24:07 -0700
   Subject: Re: redefining existing levels?
   From: garydgreg...@gmail.com
   To: log4j-user@logging.apache.org

   On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:

I guess the main use case we're trying to solve is someone, maybe some
admin or maybe a developer asking the admin, thinking they should turn
logging off and thus sets the level to OFF.  We always want INFO and
  more
critical levels to be on no matter what.

   But if a user gets in a config file and sets the root level to off, how
  can
   you stop him or her from removing your filters and custom levels?

   Gary

Thanks,
Nick

 Subject: Re: redefining existing levels?
 To: log4j-user@logging.apache.org
 From: x...@dds.nl
 Date: Wed, 26 Aug 2015 17:55:23 +0200

 I think it is still unclear what you mean by below. Normally I
  would
 consider trace to be at the low end and fatal to be at the high
  end,
 but I don't think there is a low and high in Log4J. When you say
  below
 I take it you mean DEBUG and TRACE, but the only thing that makes
  sense
 to me is to keep INFO, ERROR and FATAL on.

 Regards, Bart.

 Op 26-8-2015 om 3:46 schreef Nicholas Duane:
  Yes and no.  The user might know how to turn on/off logging, but
  they
might not understand what the enterprise is wanting to do.  We would
  like
to make it hard, if not impossible, to turn off logging of INFO and
  below
(or above for .NET) events.  So even if something thinks they should
  turn
off logging and sets the level to OFF we still want INFO and below
  to be
logged.

  Thanks,
  Nick

  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  Date: Wed, 26 Aug 2015 09:25:09 +0900
  To: log4j-user@logging.apache.org

  Could you explain a bit more about your use case before we zoom
  in on
a specific solution?

  I'd like to understand better what you mean by [if someone sets
  the
level to OFF]?
  What is the scenario? Someone logs into the server and modifies
  the
configuration and makes a mistake? Or is this a client distributed to
  your
users' PCs and they may modify the configuration?

  It sounds like you are trying to protect against human error; is
  that
the case?

  Sent from my iPhone

  On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:

  No.  Redefining existing levels is to help ensure we have 24x7
logging always on.  So even if someone sets the level to OFF we
  still get
INFO and above.  Basically we'll have levels higher (or lower based on
  what
platform we're talking about) than INFO OFF by default and only turn
  them
on when needed.

  Thanks,
  Nick

  Date: Wed, 26 Aug 2015 08:33:34 +0900
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org

  Is redefining levels a way to work around the issue you had with
the range
  check?
  I've replied to your range check question with a link to an
  example
config.

  On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
garydgreg...@gmail.com
  wrote:

  Well, let's all work together to get you up and running.
  Hopefully
we'll
  get other devs to keep chiming in.

  Gary

  On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane 
  nic...@msn.com
wrote:

  I will get to that.  However, I assume that works as that's
documented
  pretty well.  So I'm looking at the

RE: redefining existing levels?

I'm one of the developers in the framework team.  We're working on a logging 
framework.  Let's say the enterprise direction is to always capture INFO and 
more critical.  If someone, who happens to have access to the server(s), does 
something they think they should do but in fact they shouldn't be doing, like 
turning logging to OFF, we would like INFO and more critical levels to still 
be flowing.
 
Thanks,
Nick
 
 Subject: Re: redefining existing levels?
 To: log4j-user@logging.apache.org
 From: x...@dds.nl
 Date: Wed, 26 Aug 2015 17:56:10 +0200
 
 Op 26-8-2015 om 5:43 schreef Gary Gregory:
  On Tue, Aug 25, 2015 at 7:59 PM, Remko Popma remko.po...@gmail.com wrote:
 
  How are users currently able to set the log level to OFF? Do they modify
  the config?
 
  Right, isn't the only way to enforce this is to override the config file
  programatically?
 
  Gary
 
 And are you not the one who allows your users this functionality? Or do 
 they get to set a dedicated config script? Can't your user actions 
 simply be filtered or disallowed, or not even presented?.
 
 Or are your users programmers?.
 
 
  Sent from my iPhone
 
  On 2015/08/26, at 11:35, Nicholas Duane nic...@msn.com wrote:
 
  It just dawned on me that my solution of redefining OFF to the INFO
  level only addresses the case of someone setting the level to OFF.  Someone
  could set the level to ERROR.
  As I mentioned, what I'm trying to do is enforce, via configuration
  only, not being able to turn of logging of INFO and below levels.
  Thanks,Nick
 
   Original message 
  From: Nicholas Duane nic...@msn.com
  Date: 08/25/2015  7:46 PM  (GMT-07:00)
  To: Log4J Users List log4j-user@logging.apache.org
  Subject: RE: redefining existing levels?
 
  Yes and no.  The user might know how to turn on/off logging, but they
  might not understand what the enterprise is wanting to do.  We would like
  to make it hard, if not impossible, to turn off logging of INFO and below
  (or above for .NET) events.  So even if something thinks they should turn
  off logging and sets the level to OFF we still want INFO and below to be
  logged.
  Thanks,
  Nick
 
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  Date: Wed, 26 Aug 2015 09:25:09 +0900
  To: log4j-user@logging.apache.org
 
  Could you explain a bit more about your use case before we zoom in on a
  specific solution?
  I'd like to understand better what you mean by [if someone sets the
  level to OFF]?
  What is the scenario? Someone logs into the server and modifies the
  configuration and makes a mistake? Or is this a client distributed to your
  users' PCs and they may modify the configuration?
  It sounds like you are trying to protect against human error; is that
  the case?
  Sent from my iPhone
 
  On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:
 
  No.  Redefining existing levels is to help ensure we have 24x7
  logging always on.  So even if someone sets the level to OFF we still get
  INFO and above.  Basically we'll have levels higher (or lower based on what
  platform we're talking about) than INFO OFF by default and only turn them
  on when needed.
  Thanks,
  Nick
 
  Date: Wed, 26 Aug 2015 08:33:34 +0900
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
 
  Is redefining levels a way to work around the issue you had with the
  range
  check?
  I've replied to your range check question with a link to an example
  config.
  On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory garydgreg...@gmail.com
  wrote:
 
  Well, let's all work together to get you up and running. Hopefully
  we'll
  get other devs to keep chiming in.
 
 
  Gary
 
  On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
  wrote:
  I will get to that.  However, I assume that works as that's
  documented
  pretty well.  So I'm looking at the other things which may or may
  not
  work
  as I have to find out what blocking issues we're going to run into.
  Redefining existing levels is one.  I sent the other email regarding
  range
  level filter as we also need that to work.  It works in .NET.  So
  far
  it's
  looking like I'll need to write my own filter for log4j2 in order
  to get
  range level filtering working.
 
  Thanks,
  Nick
 
  Date: Tue, 25 Aug 2015 15:54:08 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  Ah, well, let's start with the documented stuff we know should
  work ;-)
  Gary
 
  On Tue, Aug 25, 2015 at 3:19 PM, Nicholas Duane nic...@msn.com
  wrote:
  Thanks.  I assumed my 'BUSINESS' level is working using the
  CustomLevel,
  though I haven't tried it yet as I was trying to validate
  redefining
  existing level.
 
  Thanks,
  Nick
 
  Date: Tue, 25 Aug 2015 14:32:01 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  Nick,
 
  Your BUSINESS

RE: redefining existing levels?

Yeah, that should do it.  Again, it might be the case that I'm trying to solve 
something that doesn't need to be solved.  Since it seemed there was an extra 
hole I could close, suspenders and belt so to speak, using log4net and 
redefining OFF to the value of INFO, I was wondering whether the same thing 
could be done with log4j.
 
Thanks,
Nick
 
 Subject: Re: redefining existing levels?
 From: ralph.go...@dslextreme.com
 Date: Wed, 26 Aug 2015 09:31:19 -0700
 To: log4j-user@logging.apache.org
 
 Can’t you just put a comment in the config file that states the minimum 
 logging level is info and that it is not to be changed under any 
 circumstances?
 
 Ralph
 
  On Aug 26, 2015, at 9:27 AM, Nicholas Duane nic...@msn.com wrote:
  
  Maybe what I'm trying to do is not that useful.  However, I'm guessing the 
  person mucking around with things would probably feel uncomfortable 
  deleting entries in the config.  If they are familiar with log4j they might 
  feel comfortable setting the level if they think they should be turning 
  things off.
  
  Basically, we have what we'll call always on or 24x7 logging.  This is 
  about always having INFO and more critical turned on.  I'm just looking for 
  ways to help enforce that.
  
  Thanks,
  Nick
  
  Date: Wed, 26 Aug 2015 09:24:07 -0700
  Subject: Re: redefining existing levels?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
  
  On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com wrote:
  
  I guess the main use case we're trying to solve is someone, maybe some
  admin or maybe a developer asking the admin, thinking they should turn
  logging off and thus sets the level to OFF.  We always want INFO and 
  more
  critical levels to be on no matter what.
  
  
  But if a user gets in a config file and sets the root level to off, how can
  you stop him or her from removing your filters and custom levels?
  
  Gary
  
  
  Thanks,
  Nick
  
  Subject: Re: redefining existing levels?
  To: log4j-user@logging.apache.org
  From: x...@dds.nl
  Date: Wed, 26 Aug 2015 17:55:23 +0200
  
  I think it is still unclear what you mean by below. Normally I would
  consider trace to be at the low end and fatal to be at the high end,
  but I don't think there is a low and high in Log4J. When you say below
  I take it you mean DEBUG and TRACE, but the only thing that makes sense
  to me is to keep INFO, ERROR and FATAL on.
  
  Regards, Bart.
  
  
  
  Op 26-8-2015 om 3:46 schreef Nicholas Duane:
  Yes and no.  The user might know how to turn on/off logging, but they
  might not understand what the enterprise is wanting to do.  We would like
  to make it hard, if not impossible, to turn off logging of INFO and below
  (or above for .NET) events.  So even if something thinks they should turn
  off logging and sets the level to OFF we still want INFO and below to be
  logged.
  
  Thanks,
  Nick
  
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  Date: Wed, 26 Aug 2015 09:25:09 +0900
  To: log4j-user@logging.apache.org
  
  Could you explain a bit more about your use case before we zoom in on
  a specific solution?
  
  I'd like to understand better what you mean by [if someone sets the
  level to OFF]?
  What is the scenario? Someone logs into the server and modifies the
  configuration and makes a mistake? Or is this a client distributed to your
  users' PCs and they may modify the configuration?
  
  It sounds like you are trying to protect against human error; is that
  the case?
  
  Sent from my iPhone
  
  On 2015/08/26, at 8:37, Nicholas Duane nic...@msn.com wrote:
  
  No.  Redefining existing levels is to help ensure we have 24x7
  logging always on.  So even if someone sets the level to OFF we still 
  get
  INFO and above.  Basically we'll have levels higher (or lower based on 
  what
  platform we're talking about) than INFO OFF by default and only turn them
  on when needed.
  
  Thanks,
  Nick
  
  Date: Wed, 26 Aug 2015 08:33:34 +0900
  Subject: Re: redefining existing levels?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
  
  Is redefining levels a way to work around the issue you had with
  the range
  check?
  I've replied to your range check question with a link to an example
  config.
  
  On Wed, Aug 26, 2015 at 8:02 AM, Gary Gregory 
  garydgreg...@gmail.com
  wrote:
  
  Well, let's all work together to get you up and running. Hopefully
  we'll
  get other devs to keep chiming in.
  
  
  Gary
  
  On Tue, Aug 25, 2015 at 3:58 PM, Nicholas Duane nic...@msn.com
  wrote:
  
  I will get to that.  However, I assume that works as that's
  documented
  pretty well.  So I'm looking at the other things which may or may
  not
  work
  as I have to find out what blocking issues we're going to run
  into.
  Redefining existing levels is one.  I sent the other email
  regarding
  range
  level filter as we also need that to work.  It works in .NET.  So
  far
  it's
  looking like I'll

Re: custom levels via configuration

Start reading here:

- Main site: https://logging.apache.org/log4j/2.x/
- Source code: https://logging.apache.org/log4j/2.x/source-repository.html
- This ML

Git is the source control system we use.

Git master refers to the main branch of development with Git.

Gary


On Wed, Aug 26, 2015 at 12:54 PM, Nicholas Duane nic...@msn.com wrote:

 Yes I am a true noob to java and linux and log4j.

 What is gitmaster?  I assume related to github somehow?  How can I see the
 test you created?  Is there a link you can provide?

 Thanks,
 Nick

  Date: Wed, 26 Aug 2015 12:34:45 -0700
  Subject: Re: custom levels via configuration
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  On Wed, Aug 26, 2015 at 11:46 AM, Gary Gregory garydgreg...@gmail.com
  wrote:
 
   This:
  
   Logger name=HelloWorld level=ALL
  
   is only going to match:
  
   static Logger log = LogManager.getLogger(HelloWorld.class.getName());
  
   if the class in unpackaged, which it looks it is based on this paste
 but I
   want to double check that you did not omit anything from the example.
  
   Are you using the latest version (2.3)?.
  
   I just added this test the other day to Git master:
  
   org.apache.logging.log4j.core.CustomLevelsTest
  
   And it shows that we can configure custom levels from a file and see
 them
   in code.
  
   So I am puzzled here.
  
   You could try the latest from Git master as well but I do not recall
 any
   fixes in this area.
  
   I wonder if the Appenders are processed by the configuration _before_
 the
   custom levels...
  
 
  My above suspicion was unfounded, see my new
  test org.apache.logging.log4j.core.CustomLevelsWithFiltersTest and feel
  free to provide a patch to test your desired behavior. This might be a
 tall
  order if you are a true Java newbie ;-)
 
  Gary
 
  
   Gary
  
  
   On Wed, Aug 26, 2015 at 11:19 AM, Nicholas Duane nic...@msn.com
 wrote:
  
  
  
  
   On to my next problem.  I'm trying to define a custom level in
   configuration.  Not sure if it's working or not.  However, when I
 attempt
   to get the level for that custom level I get back null, which I wasn't
   expecting.  Here is the log4j2.xml config file:
  
   ?xml version=1.0 encoding=UTF-8?
   Configuration status=trace verbose=true
 CustomLevels
   CustomLevel name=INFOM1 intLevel=399/
   CustomLevel name=INFOP1 intLevel=401/
 /CustomLevels
 Appenders
   File name=info fileName=info.log
 PatternLayout
   Pattern%d %p %c{1.} [%t] %m%n/Pattern
 /PatternLayout
 Filters
   ThresholdFilter level=INFOM1 onMatch=DENY
 onMismatch=NEUTRAL/
   ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
 /Filters
   /File
 /Appenders
 Loggers
   Logger name=HelloWorld level=ALL
 AppenderRef ref=info/
   /Logger
   Root
   /Root
 /Loggers
   /Configuration
  
   Here is my code:
  
   import org.apache.logging.log4j.LogManager;
   import org.apache.logging.log4j.Logger;
   import org.apache.logging.log4j.Level;
  
   public class HelloWorld
   {
   static Logger log =
 LogManager.getLogger(HelloWorld.class.getName());
  
   public static void main(String[] args)
   {
 System.out.println(Hello, World);
 log.info(hello this is an INFO  message);
 log.warn(hello this is a WARN message);
 log.debug(hello this is a DEBUG message);
 Level level = Level.getLevel(INFOM1);
 if (level == null)
   System.out.println(Didn't find level INFOM1);
 else
   log.log(level, hello this is an INFOM1 message);
 level = Level.getLevel(INFOP1);
 if (level == null)
   System.out.println(Didn't find level INFOP1);
 else
   log.log(level, hello this is an INFOP1 message);
   }
   }
  
   Any ideas?  I obviously don't want to use Level.forName() as that will
   create the level if it doesn't exist and I want to ensure I'm pulling
 the
   value from the configuration.
  
   Thanks,
   Nick
  
  
  
  
  
  
   --
   E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
   Java Persistence with Hibernate, Second Edition
   http://www.manning.com/bauer3/
   JUnit in Action, Second Edition http://www.manning.com/tahchiev/
   Spring Batch in Action http://www.manning.com/templier/
   Blog: http://garygregory.wordpress.com
   Home: http://garygregory.com/
   Tweet! http://twitter.com/GaryGregory
  
 
 
 
  --
  E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
  Java Persistence with Hibernate, Second Edition
  http://www.manning.com/bauer3/
  JUnit in Action, Second Edition http://www.manning.com/tahchiev/
  Spring Batch in Action http://www.manning.com/templier/
  Blog: http://garygregory.wordpress.com
  Home: http://garygregory.com/
  Tweet! http://twitter.com/GaryGregory





-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
http://www.manning.com/bauer3/

Re: custom levels via configuration

The current version of Log4j has more internal logging than past ones, but
maybe not in this area.

If Yum or whatever installer Fedora likes best does not do what you want,
you can download the 2.3 jars from the Log4j site and put them in your
classpath.

Gary

On Wed, Aug 26, 2015 at 2:34 PM, Nicholas Duane nic...@msn.com wrote:

 While I work on figuring out how to get a newer version of log4j2
 installed I'm wondering whether there is some additional investigation I
 can do with the version I have.  For instance, I was hoping with the level
 of logging I have enabled, that log4j would be indicating some issue it had
 with the custom level.  However, I don't see such an issue.  The only thing
 I see is an issue with the custom level, which I'm guessing is when I'm
 using it in the filter.  I've attached the warning in the log below.

 Is there some additional logging I can turn on such that log4j will
 produce more info which might indicate why my custom levels aren't
 working?  Here is my current log4j2 configuration.

 log4j2.xml:

 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
 /Configuration

 snippet of console output:

 2015-08-26 14:26:21,070 WARN Error while converting string [INFOM1] to
 type [class org.apache.logging.log4j.Level]. Using default value [null].
 java.lang.IllegalArgumentException: Unknown level constant [INFOM1].
 at org.apache.logging.log4j.Level.valueOf(Level.java:281)
 at
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:240)
 at
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:237)
 at
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters.convert(TypeConverters.java:343)
 at
 org.apache.logging.log4j.core.config.plugins.visitors.AbstractPluginVisitor.convert(AbstractPluginVisitor.java:130)
 at
 org.apache.logging.log4j.core.config.plugins.visitors.PluginAttributeVisitor.visit(PluginAttributeVisitor.java:44)
 at
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.generateParameters(PluginBuilder.java:233)
 at
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:131)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:748)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:683)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:349)
 at
 org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:150)
 at
 org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:358)
 at
 org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:416)
 at
 org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:146)
 at
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:75)
 at
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:37)
 at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:473)
 at HelloWorld.clinit(HelloWorld.java:7)

 Thanks,
 Nick

  Date: Wed, 26 Aug 2015 12:36:40 -0700
  Subject: Re: custom levels via configuration
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
 
  We've never released a version 2.0-1.fc21 so it must be a Fedora build,
  presumably based on 2.0 or some fork of it.
 
  You need to test with version 2.3 or a 2.4-SNAPSHOT. I'll leave you to
  Google how to install 2.3 on Fedora ;-)
 
  Gary
 
  On Wed, Aug 26, 2015 at 12:14 PM, Nicholas Duane nic...@msn.com wrote:
 
   First off let me admit that I'm a noob at both Linux and java, and
 log4j
   for that matter.
  
   I don't know how to package anything so my class that you see is a
 simple
   java class which I compiled using javac.  I then run it using 'java

RE: range filter?

Thanks for clarifying.

My effort to try to get the composite + threshold filter working such that I 
can filter a single level so far has failed.  Here is my code:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.Level;

public class HelloWorld
{ 
static Logger log = LogManager.getLogger(HelloWorld.class.getName());

public static void main(String[] args)
{ 
  System.out.println(Hello, World);
  log.info(hello this is an INFO  message);
  log.warn(hello this is a WARN message);
  log.debug(hello this is a DEBUG message);
  Level level = Level.getLevel(INFOM1);
  if (level == null)
 System.out.println(Didn't find level INFOM1);
  else
log.log(level, hello this is an INFOM1 message);
  level = Level.getLevel(INFOP1);
  if (level == null)
System.out.println(Didn't find level INFOP1);
  else
log.log(level, hello this is an INFOP1 message);
}
}

Here is my configuration file:

?xml version=1.0 encoding=UTF-8?
Configuration status=trace verbose=true
  CustomLevels
CustomLevel name=INFOM1 intLevel=399/
CustomLevel name=INFOP1 intLevel=401/
  /CustomLevels
  Appenders
File name=info fileName=info.log
  PatternLayout
Pattern%d %p %c{1.} [%t] %m%n/Pattern
  /PatternLayout
  Filters
ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
  /Filters
/File
  /Appenders
  Loggers
Logger name=HelloWorld level=ALL
  AppenderRef ref=info/
/Logger
Root
/Root
  /Loggers
/Configuration

NOTE: The custom levels are not being found by the code as I'm seeing my 
messages to stdout that it couldn't find INFOM1 and INFOP1.

Any suggestion on how to get filtering of a single level working with the 
composite filter + threshold filter?

Thanks,
Nick

 Subject: Re: range filter?
 From: ralph.go...@dslextreme.com
 Date: Wed, 26 Aug 2015 07:05:35 -0700
 To: log4j-user@logging.apache.org
 
 I apologize, you are correct. The level values do decrease.
 
 Regardless, your point about wanting to filter on essentially a single 
 integer value makes sense.
 
 Ralph
 
  On Aug 26, 2015, at 6:12 AM, Nicholas Duane nic...@msn.com wrote:
  
  Hmmm, I thought for log4j the threshold was less than or equal to the 
  level.  For instance, if the threshold is INFO then INFO and less than, eg 
  more critical like WARN ERROR and FATAL would match.  It's opposite in 
  log4net.  Regardless, this is the issue I wanted to point out.  The 
  stackoverflow article doesn't filter only INFO level, it seems it filters 
  INFO and anything between INFO and WARN but not including WARN.
  
  If I want just a single level then I would like a way to specify that 
  without me having to potentially go back and edit the configuration if 
  someone decides to specify a custom level via configuration or code.  The 
  LevelRangeFilter provides an easy mechanism for me to do this by specifying 
  the same level for min and max.  I guess you're suggesting I could 
  accomplish this via the composite filter and the threshold filter, however, 
  I would have to define a custom level that is one less than or one more 
  than the level I'm looking to capture so that I ensure I'm only getting 
  that one level.  I will try this out, but it would be nice to have 
  something like the LevelRangeFilter.
  
  Thanks,
  Nick
  
  Subject: Re: range filter?
  From: ralph.go...@dslextreme.com
  Date: Tue, 25 Aug 2015 22:08:01 -0700
  To: log4j-user@logging.apache.org
  
  No. If the custom level was 1 greater than INFO, then yes. In that case 
  you would specify your custom level instead of WARN as the level on the 
  first ThresholdFilter.
  
  Ralph
  
  On Aug 25, 2015, at 9:39 PM, Nicholas Duane nic...@msn.com wrote:
  
  What if someone defined a custom level one less than INFO?  Wouldn't that 
  end up in the log also?
  Thanks,Nick
  
   Original message 
  From: Ralph Goers ralph.go...@dslextreme.com
  Date: 08/25/2015  10:28 PM  (GMT-07:00)
  To: Log4J Users List log4j-user@logging.apache.org
  Subject: Re: range filter?
  
  I just did.
  
  Ralph
  
  On Aug 25, 2015, at 9:12 PM, Nicholas Duane nic...@msn.com wrote:
  
  That's exactly the use case I'm looking for.  I'll have to study it some 
  more.  Can you give me an example which filters out everything but INFO?
  Thanks,Nick
  
   Original message 
  From: Remko Popma remko.po...@gmail.com
  Date: 08/25/2015  9:06 PM  (GMT-07:00)
  To: Log4J Users List log4j-user@logging.apache.org
  Subject: Re: range filter?
  
  
  The StackOverflow link was an answer to the question how to send _only_ 
  INFO level events to an appender.
  
  
  
  I thought it would illustrate how filters combinations could be used to 
  achieve the original request: I might want all DEBUG, TRACE and VERBOSE 
  events going to one

RE: range filter?

Hmmm, I thought for log4j the threshold was less than or equal to the level.  
For instance, if the threshold is INFO then INFO and less than, eg more 
critical like WARN ERROR and FATAL would match.  It's opposite in log4net.  
Regardless, this is the issue I wanted to point out.  The stackoverflow article 
doesn't filter only INFO level, it seems it filters INFO and anything between 
INFO and WARN but not including WARN.
 
If I want just a single level then I would like a way to specify that without 
me having to potentially go back and edit the configuration if someone decides 
to specify a custom level via configuration or code.  The LevelRangeFilter 
provides an easy mechanism for me to do this by specifying the same level for 
min and max.  I guess you're suggesting I could accomplish this via the 
composite filter and the threshold filter, however, I would have to define a 
custom level that is one less than or one more than the level I'm looking to 
capture so that I ensure I'm only getting that one level.  I will try this out, 
but it would be nice to have something like the LevelRangeFilter.
 
Thanks,
Nick
 
 Subject: Re: range filter?
 From: ralph.go...@dslextreme.com
 Date: Tue, 25 Aug 2015 22:08:01 -0700
 To: log4j-user@logging.apache.org
 
 No. If the custom level was 1 greater than INFO, then yes. In that case you 
 would specify your custom level instead of WARN as the level on the first 
 ThresholdFilter.
 
 Ralph
 
  On Aug 25, 2015, at 9:39 PM, Nicholas Duane nic...@msn.com wrote:
  
  What if someone defined a custom level one less than INFO?  Wouldn't that 
  end up in the log also?
  Thanks,Nick
  
   Original message 
  From: Ralph Goers ralph.go...@dslextreme.com
  Date: 08/25/2015  10:28 PM  (GMT-07:00)
  To: Log4J Users List log4j-user@logging.apache.org
  Subject: Re: range filter?
  
  I just did.
  
  Ralph
  
  On Aug 25, 2015, at 9:12 PM, Nicholas Duane nic...@msn.com wrote:
  
  That's exactly the use case I'm looking for.  I'll have to study it some 
  more.  Can you give me an example which filters out everything but INFO?
  Thanks,Nick
  
   Original message 
  From: Remko Popma remko.po...@gmail.com
  Date: 08/25/2015  9:06 PM  (GMT-07:00)
  To: Log4J Users List log4j-user@logging.apache.org
  Subject: Re: range filter?
  
  
  The StackOverflow link was an answer to the question how to send _only_ 
  INFO level events to an appender.
  
  
  
  I thought it would illustrate how filters combinations could be used to 
  achieve the original request: I might want all DEBUG, TRACE and VERBOSE 
  events going to one appender.  All INFO, ERROR and WARN events going to 
  another appender. All BUSINESS events (my custom) level, going to yet 
  another appender.
  
  
  
  Seemed to me to be a similar use case to the SO question.
  
  
  
  Sent from my iPhone
  
  
  
  On 2015/08/26, at 11:44, Ralph Goers ralph.go...@dslextreme.com wrote:
  
  
  
  I am not sure why Remko advised you to do it this way.  The first filter 
  will deny Warn, error and fatal making the next two filters redundant. 
  The third filter will accept events at level info and deny trace and 
  debug.  So the end result is the only events that will get logged will be 
  those at INFO level.
  
  
  
  The composite filter really just wraps other filters and returns whatever 
  result they generate. For example, if the first filter returns accept or 
  deny then that value will be returned as the result without consulting 
  any other filters. If the result is neutral then the second filter will 
  be used to see if the event passes that.
  
  
  
  Ralph
  
  
  
  
  
  On Aug 25, 2015, at 7:09 PM, Nicholas Duane nic...@msn.com wrote:
  
  
  
  Maybe.  However, I'm having a hard time following what the configuration 
  is saying and thus have no idea what I would need to put in the 
  configuration.  Here is a snippet from that post:
  
  
  
   !-- Now deny warn, error and fatal messages --
  
  
  
  ThresholdFilter level=warn  onMatch=DENY   
  onMismatch=NEUTRAL/
  
  
  
   ThresholdFilter level=error onMatch=DENY   
  onMismatch=NEUTRAL/
  
   ThresholdFilter level=fatal onMatch=DENY   
  onMismatch=NEUTRAL/
  
  
  
!-- This filter accepts info, warn, error, fatal and denies 
  debug/trace --
  
  
  
ThresholdFilter level=info  onMatch=ACCEPT 
  onMismatch=DENY/
  
  
  
  
  
  The top three seem as if they would deny warn, error and fatal, yet the 
  third says it accepts info, warn, error and fatal.  And while I 
  understand those in isolation, I think, I have no idea how the filters 
  composite would handle this.  Why are the first three needed?  How does 
  the CompositeFilter work?  Does it try to match on each filter in the 
  list of stop as soon as it gets a DENY?
  
  
  
  What if I wanted to setup a filter which just accepted WARN?  And on top 
  of that ensure that if anyone

Re: range filter?

I apologize, you are correct. The level values do decrease.

Regardless, your point about wanting to filter on essentially a single integer 
value makes sense.

Ralph

 On Aug 26, 2015, at 6:12 AM, Nicholas Duane nic...@msn.com wrote:
 
 Hmmm, I thought for log4j the threshold was less than or equal to the level.  
 For instance, if the threshold is INFO then INFO and less than, eg more 
 critical like WARN ERROR and FATAL would match.  It's opposite in log4net.  
 Regardless, this is the issue I wanted to point out.  The stackoverflow 
 article doesn't filter only INFO level, it seems it filters INFO and anything 
 between INFO and WARN but not including WARN.
 
 If I want just a single level then I would like a way to specify that without 
 me having to potentially go back and edit the configuration if someone 
 decides to specify a custom level via configuration or code.  The 
 LevelRangeFilter provides an easy mechanism for me to do this by specifying 
 the same level for min and max.  I guess you're suggesting I could accomplish 
 this via the composite filter and the threshold filter, however, I would have 
 to define a custom level that is one less than or one more than the level I'm 
 looking to capture so that I ensure I'm only getting that one level.  I will 
 try this out, but it would be nice to have something like the 
 LevelRangeFilter.
 
 Thanks,
 Nick
 
 Subject: Re: range filter?
 From: ralph.go...@dslextreme.com
 Date: Tue, 25 Aug 2015 22:08:01 -0700
 To: log4j-user@logging.apache.org
 
 No. If the custom level was 1 greater than INFO, then yes. In that case you 
 would specify your custom level instead of WARN as the level on the first 
 ThresholdFilter.
 
 Ralph
 
 On Aug 25, 2015, at 9:39 PM, Nicholas Duane nic...@msn.com wrote:
 
 What if someone defined a custom level one less than INFO?  Wouldn't that 
 end up in the log also?
 Thanks,Nick
 
  Original message 
 From: Ralph Goers ralph.go...@dslextreme.com
 Date: 08/25/2015  10:28 PM  (GMT-07:00)
 To: Log4J Users List log4j-user@logging.apache.org
 Subject: Re: range filter?
 
 I just did.
 
 Ralph
 
 On Aug 25, 2015, at 9:12 PM, Nicholas Duane nic...@msn.com wrote:
 
 That's exactly the use case I'm looking for.  I'll have to study it some 
 more.  Can you give me an example which filters out everything but INFO?
 Thanks,Nick
 
  Original message 
 From: Remko Popma remko.po...@gmail.com
 Date: 08/25/2015  9:06 PM  (GMT-07:00)
 To: Log4J Users List log4j-user@logging.apache.org
 Subject: Re: range filter?
 
 
 The StackOverflow link was an answer to the question how to send _only_ 
 INFO level events to an appender.
 
 
 
 I thought it would illustrate how filters combinations could be used to 
 achieve the original request: I might want all DEBUG, TRACE and VERBOSE 
 events going to one appender.  All INFO, ERROR and WARN events going to 
 another appender. All BUSINESS events (my custom) level, going to yet 
 another appender.
 
 
 
 Seemed to me to be a similar use case to the SO question.
 
 
 
 Sent from my iPhone
 
 
 
 On 2015/08/26, at 11:44, Ralph Goers ralph.go...@dslextreme.com wrote:
 
 
 
 I am not sure why Remko advised you to do it this way.  The first filter 
 will deny Warn, error and fatal making the next two filters redundant. 
 The third filter will accept events at level info and deny trace and 
 debug.  So the end result is the only events that will get logged will be 
 those at INFO level.
 
 
 
 The composite filter really just wraps other filters and returns whatever 
 result they generate. For example, if the first filter returns accept or 
 deny then that value will be returned as the result without consulting 
 any other filters. If the result is neutral then the second filter will 
 be used to see if the event passes that.
 
 
 
 Ralph
 
 
 
 
 
 On Aug 25, 2015, at 7:09 PM, Nicholas Duane nic...@msn.com wrote:
 
 
 
 Maybe.  However, I'm having a hard time following what the configuration 
 is saying and thus have no idea what I would need to put in the 
 configuration.  Here is a snippet from that post:
 
 
 
 !-- Now deny warn, error and fatal messages --
 
 
 
ThresholdFilter level=warn  onMatch=DENY   
 onMismatch=NEUTRAL/
 
 
 
 ThresholdFilter level=error onMatch=DENY   
 onMismatch=NEUTRAL/
 
 ThresholdFilter level=fatal onMatch=DENY   
 onMismatch=NEUTRAL/
 
 
 
  !-- This filter accepts info, warn, error, fatal and denies 
 debug/trace --
 
 
 
  ThresholdFilter level=info  onMatch=ACCEPT 
 onMismatch=DENY/
 
 
 
 
 
 The top three seem as if they would deny warn, error and fatal, yet the 
 third says it accepts info, warn, error and fatal.  And while I 
 understand those in isolation, I think, I have no idea how the filters 
 composite would handle this.  Why are the first three needed?  How does 
 the CompositeFilter work?  Does it try to match on each filter in the 
 list of stop as soon as it gets

Re: redefining existing levels?

2015-08-26 Thread Remko Popma

I am glad I asked these questions.
In my opinion, you cannot protect people from messing up your configuration
by providing them with some configuration, for the simple reason that they
can modify your changes.

I am also with Ralph in that I am not a fan of a minimum log level that
would ignore what the user configured. That is just confusing.

If you really want to take away the option for your users to modify the
logging configuration, your only option may be to programmatically
configure Log4j. There is work in progress
https://issues.apache.org/jira/browse/LOG4J2-952 for this. Of course the
knife cuts both ways: this also means that if you need to support them, you
cannot ask them to increase the log level to TRACE to help you diagnose the
issue... My advice would be to trust that your users are smart enough not
to mess it up. :-)


On Thu, Aug 27, 2015 at 1:44 AM, Gary Gregory garydgreg...@gmail.com
wrote:

 On Wed, Aug 26, 2015 at 9:42 AM, Nicholas Duane nic...@msn.com wrote:

  No, I don't know what monitorInterval is.


 Please see

 https://logging.apache.org/log4j/2.x/manual/configuration.html#AutomaticReconfiguration

 Gary


  Right now in log4net, which is where I'm redefining OFF, we have the
  log4net configuration in the application configuration file.  So it for
  instance it's a web application, touching the log4net configuration will
  restart the application domain.
 
  Thanks,
  Nick
 
   Date: Wed, 26 Aug 2015 09:32:15 -0700
   Subject: Re: redefining existing levels?
   From: garydgreg...@gmail.com
   To: log4j-user@logging.apache.org
  
   On Wed, Aug 26, 2015 at 9:27 AM, Nicholas Duane nic...@msn.com
 wrote:
  
Maybe what I'm trying to do is not that useful.  However, I'm
 guessing
  the
person mucking around with things would probably feel uncomfortable
deleting entries in the config.  If they are familiar with log4j they
  might
feel comfortable setting the level if they think they should be
 turning
things off.
   
  
   Does this mean you use Log4j with the monitorInterval Confuguration
   attribute? Or can this user also restart the application by hand for
 the
   new logging configuration to take effect?
  
   Gary
  
   
Basically, we have what we'll call always on or 24x7 logging.
  This is
about always having INFO and more critical turned on.  I'm just
  looking for
ways to help enforce that.
   
Thanks,
Nick
   
 Date: Wed, 26 Aug 2015 09:24:07 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org

 On Wed, Aug 26, 2015 at 9:19 AM, Nicholas Duane nic...@msn.com
  wrote:

  I guess the main use case we're trying to solve is someone, maybe
  some
  admin or maybe a developer asking the admin, thinking they should
  turn
  logging off and thus sets the level to OFF.  We always want
 INFO
  and
more
  critical levels to be on no matter what.
 

 But if a user gets in a config file and sets the root level to off,
  how
can
 you stop him or her from removing your filters and custom levels?

 Gary

 
  Thanks,
  Nick
 
   Subject: Re: redefining existing levels?
   To: log4j-user@logging.apache.org
   From: x...@dds.nl
   Date: Wed, 26 Aug 2015 17:55:23 +0200
  
   I think it is still unclear what you mean by below. Normally
 I
would
   consider trace to be at the low end and fatal to be at the
  high
end,
   but I don't think there is a low and high in Log4J. When you
 say
below
   I take it you mean DEBUG and TRACE, but the only thing that
 makes
sense
   to me is to keep INFO, ERROR and FATAL on.
  
   Regards, Bart.
  
  
  
   Op 26-8-2015 om 3:46 schreef Nicholas Duane:
Yes and no.  The user might know how to turn on/off logging,
  but
they
  might not understand what the enterprise is wanting to do.  We
  would
like
  to make it hard, if not impossible, to turn off logging of INFO
 and
below
  (or above for .NET) events.  So even if something thinks they
  should
turn
  off logging and sets the level to OFF we still want INFO and
  below
to be
  logged.
   
Thanks,
Nick
   
Subject: Re: redefining existing levels?
From: remko.po...@gmail.com
Date: Wed, 26 Aug 2015 09:25:09 +0900
To: log4j-user@logging.apache.org
   
Could you explain a bit more about your use case before we
  zoom
in on
  a specific solution?
   
I'd like to understand better what you mean by [if someone
  sets
the
  level to OFF]?
What is the scenario? Someone logs into the server and
  modifies
the
  configuration and makes a mistake? Or is this a client
 distributed
  to
your
  users' PCs and they may modify the configuration?
   
It sounds like you are

Re: custom levels via configuration

2015-08-26 Thread Remko Popma

Nick,

What was the output of this program? Were both INFOM1 and INFOP1 not found,
or was INFOM1 found (because it is used in the ThresholdFilter), but not
INFOP1?

Remko

On Thu, Aug 27, 2015 at 3:19 AM, Nicholas Duane nic...@msn.com wrote:




 On to my next problem.  I'm trying to define a custom level in
 configuration.  Not sure if it's working or not.  However, when I attempt
 to get the level for that custom level I get back null, which I wasn't
 expecting.  Here is the log4j2.xml config file:

 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
 /Configuration

 Here is my code:

 import org.apache.logging.log4j.LogManager;
 import org.apache.logging.log4j.Logger;
 import org.apache.logging.log4j.Level;

 public class HelloWorld
 {
 static Logger log = LogManager.getLogger(HelloWorld.class.getName());

 public static void main(String[] args)
 {
   System.out.println(Hello, World);
   log.info(hello this is an INFO  message);
   log.warn(hello this is a WARN message);
   log.debug(hello this is a DEBUG message);
   Level level = Level.getLevel(INFOM1);
   if (level == null)
 System.out.println(Didn't find level INFOM1);
   else
 log.log(level, hello this is an INFOM1 message);
   level = Level.getLevel(INFOP1);
   if (level == null)
 System.out.println(Didn't find level INFOP1);
   else
 log.log(level, hello this is an INFOP1 message);
 }
 }

 Any ideas?  I obviously don't want to use Level.forName() as that will
 create the level if it doesn't exist and I want to ensure I'm pulling the
 value from the configuration.

 Thanks,
 Nick

RE: custom levels via configuration

Both were not found from my HelloClass.  And I had sent out some log4j logging 
in where there was a warning which I assume was related to me using INFOM1 in 
the threshold filter.

Thanks,
Nick

 Date: Thu, 27 Aug 2015 08:20:20 +0900
 Subject: Re: custom levels via configuration
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org

 Nick,

 What was the output of this program? Were both INFOM1 and INFOP1 not found,
 or was INFOM1 found (because it is used in the ThresholdFilter), but not
 INFOP1?

 Remko

 On Thu, Aug 27, 2015 at 3:19 AM, Nicholas Duane nic...@msn.com wrote:

  On to my next problem.  I'm trying to define a custom level in
  configuration.  Not sure if it's working or not.  However, when I attempt
  to get the level for that custom level I get back null, which I wasn't
  expecting.  Here is the log4j2.xml config file:

  ?xml version=1.0 encoding=UTF-8?
  Configuration status=trace verbose=true
CustomLevels
  CustomLevel name=INFOM1 intLevel=399/
  CustomLevel name=INFOP1 intLevel=401/
/CustomLevels
Appenders
  File name=info fileName=info.log
PatternLayout
  Pattern%d %p %c{1.} [%t] %m%n/Pattern
/PatternLayout
Filters
  ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
  ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
/Filters
  /File
/Appenders
Loggers
  Logger name=HelloWorld level=ALL
AppenderRef ref=info/
  /Logger
  Root
  /Root
/Loggers
  /Configuration

  Here is my code:

  import org.apache.logging.log4j.LogManager;
  import org.apache.logging.log4j.Logger;
  import org.apache.logging.log4j.Level;

  public class HelloWorld
  {
  static Logger log = LogManager.getLogger(HelloWorld.class.getName());

  public static void main(String[] args)
  {
System.out.println(Hello, World);
log.info(hello this is an INFO  message);
log.warn(hello this is a WARN message);
log.debug(hello this is a DEBUG message);
Level level = Level.getLevel(INFOM1);
if (level == null)
  System.out.println(Didn't find level INFOM1);
else
  log.log(level, hello this is an INFOM1 message);
level = Level.getLevel(INFOP1);
if (level == null)
  System.out.println(Didn't find level INFOP1);
else
  log.log(level, hello this is an INFOP1 message);
  }
  }

  Any ideas?  I obviously don't want to use Level.forName() as that will
  create the level if it doesn't exist and I want to ensure I'm pulling the
  value from the configuration.

  Thanks,
  Nick

Re: custom levels via configuration

2015-08-26 Thread Remko Popma

I don't have time to investigate now, but it looks like our support for
CustomLevels is not implemented in ThresholdFilter yet.

If you use a custom level in your logger config it should work. For example:
loggers
  root level=INFOP1
appenderref ref=file level=INFOM1 /
...

Remko



On Thu, Aug 27, 2015 at 8:22 AM, Nicholas Duane nic...@msn.com wrote:

 Both were not found from my HelloClass.  And I had sent out some log4j
 logging in where there was a warning which I assume was related to me using
 INFOM1 in the threshold filter.

 Thanks,
 Nick

  Date: Thu, 27 Aug 2015 08:20:20 +0900
  Subject: Re: custom levels via configuration
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
 
  Nick,
 
  What was the output of this program? Were both INFOM1 and INFOP1 not
 found,
  or was INFOM1 found (because it is used in the ThresholdFilter), but not
  INFOP1?
 
  Remko
 
  On Thu, Aug 27, 2015 at 3:19 AM, Nicholas Duane nic...@msn.com wrote:
 
  
  
  
   On to my next problem.  I'm trying to define a custom level in
   configuration.  Not sure if it's working or not.  However, when I
 attempt
   to get the level for that custom level I get back null, which I wasn't
   expecting.  Here is the log4j2.xml config file:
  
   ?xml version=1.0 encoding=UTF-8?
   Configuration status=trace verbose=true
 CustomLevels
   CustomLevel name=INFOM1 intLevel=399/
   CustomLevel name=INFOP1 intLevel=401/
 /CustomLevels
 Appenders
   File name=info fileName=info.log
 PatternLayout
   Pattern%d %p %c{1.} [%t] %m%n/Pattern
 /PatternLayout
 Filters
   ThresholdFilter level=INFOM1 onMatch=DENY
 onMismatch=NEUTRAL/
   ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
 /Filters
   /File
 /Appenders
 Loggers
   Logger name=HelloWorld level=ALL
 AppenderRef ref=info/
   /Logger
   Root
   /Root
 /Loggers
   /Configuration
  
   Here is my code:
  
   import org.apache.logging.log4j.LogManager;
   import org.apache.logging.log4j.Logger;
   import org.apache.logging.log4j.Level;
  
   public class HelloWorld
   {
   static Logger log =
 LogManager.getLogger(HelloWorld.class.getName());
  
   public static void main(String[] args)
   {
 System.out.println(Hello, World);
 log.info(hello this is an INFO  message);
 log.warn(hello this is a WARN message);
 log.debug(hello this is a DEBUG message);
 Level level = Level.getLevel(INFOM1);
 if (level == null)
   System.out.println(Didn't find level INFOM1);
 else
   log.log(level, hello this is an INFOM1 message);
 level = Level.getLevel(INFOP1);
 if (level == null)
   System.out.println(Didn't find level INFOP1);
 else
   log.log(level, hello this is an INFOP1 message);
   }
   }
  
   Any ideas?  I obviously don't want to use Level.forName() as that will
   create the level if it doesn't exist and I want to ensure I'm pulling
 the
   value from the configuration.
  
   Thanks,
   Nick

RE: custom levels via configuration

That would certainly be a possible explanation.  I'm working on figuring out 
how to upgrade to log4j 2.3.  Hopefully that will solve my custom levels issue.

Thanks,
Nick

 Subject: Re: custom levels via configuration
 From: ralph.go...@dslextreme.com
 Date: Wed, 26 Aug 2015 17:05:02 -0700
 To: log4j-user@logging.apache.org

 Custom log levels weren’t added to Log4j 2 until version 2.1, so if the 
 version you are using is older than that it is no surprise that it isn’t 
 working.

 Ralph

  On Aug 26, 2015, at 2:34 PM, Nicholas Duane nic...@msn.com wrote:

  While I work on figuring out how to get a newer version of log4j2 installed 
  I'm wondering whether there is some additional investigation I can do with 
  the version I have.  For instance, I was hoping with the level of logging I 
  have enabled, that log4j would be indicating some issue it had with the 
  custom level.  However, I don't see such an issue.  The only thing I see is 
  an issue with the custom level, which I'm guessing is when I'm using it in 
  the filter.  I've attached the warning in the log below.

  Is there some additional logging I can turn on such that log4j will produce 
  more info which might indicate why my custom levels aren't working?  Here 
  is my current log4j2 configuration.

  log4j2.xml:

  ?xml version=1.0 encoding=UTF-8?
  Configuration status=trace verbose=true
   CustomLevels
 CustomLevel name=INFOM1 intLevel=399/
 CustomLevel name=INFOP1 intLevel=401/
   /CustomLevels
   Appenders
 File name=info fileName=info.log
   PatternLayout
 Pattern%d %p %c{1.} [%t] %m%n/Pattern
   /PatternLayout
   Filters
 ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
 ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
   /Filters
 /File
   /Appenders
   Loggers
 Logger name=HelloWorld level=ALL
   AppenderRef ref=info/
 /Logger
 Root
 /Root
   /Loggers
  /Configuration

  snippet of console output:

  2015-08-26 14:26:21,070 WARN Error while converting string [INFOM1] to type 
  [class org.apache.logging.log4j.Level]. Using default value [null]. 
  java.lang.IllegalArgumentException: Unknown level constant [INFOM1].
 at org.apache.logging.log4j.Level.valueOf(Level.java:281)
 at 
  org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:240)
 at 
  org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:237)
 at 
  org.apache.logging.log4j.core.config.plugins.util.TypeConverters.convert(TypeConverters.java:343)
 at 
  org.apache.logging.log4j.core.config.plugins.visitors.AbstractPluginVisitor.convert(AbstractPluginVisitor.java:130)
 at 
  org.apache.logging.log4j.core.config.plugins.visitors.PluginAttributeVisitor.visit(PluginAttributeVisitor.java:44)
 at 
  org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.generateParameters(PluginBuilder.java:233)
 at 
  org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:131)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:748)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:683)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:349)
 at 
  org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:150)
 at 
  org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:358)
 at 
  org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:416)
 at 
  org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:146)
 at 
  org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:75)
 at 
  org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:37)
 at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:473)
 at HelloWorld.clinit(HelloWorld.java:7)

  Thanks,
  Nick

  Date: Wed, 26 Aug 2015 12:36:40 -0700
  Subject: Re: custom levels via configuration
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org

  We've never released a version 2.0-1.fc21 so it must be a Fedora build,
  presumably based on 2.0 or some fork of it.

  You need to test with version 2.3 or a 2.4-SNAPSHOT. I'll leave you to
  Google how to install 2.3 on Fedora ;-)

  Gary

RE: custom levels via configuration

It seems my custom levels aren't working as I'm getting null from 
Level.getLevel() when passing those custom level names.

Thanks,
Nick

 Date: Thu, 27 Aug 2015 08:34:43 +0900
 Subject: Re: custom levels via configuration
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org

 I don't have time to investigate now, but it looks like our support for
 CustomLevels is not implemented in ThresholdFilter yet.

 If you use a custom level in your logger config it should work. For example:
 loggers
   root level=INFOP1
 appenderref ref=file level=INFOM1 /
 ...

 Remko

 On Thu, Aug 27, 2015 at 8:22 AM, Nicholas Duane nic...@msn.com wrote:

  Both were not found from my HelloClass.  And I had sent out some log4j
  logging in where there was a warning which I assume was related to me using
  INFOM1 in the threshold filter.

  Thanks,
  Nick

   Date: Thu, 27 Aug 2015 08:20:20 +0900
   Subject: Re: custom levels via configuration
   From: remko.po...@gmail.com
   To: log4j-user@logging.apache.org

   Nick,

   What was the output of this program? Were both INFOM1 and INFOP1 not
  found,
   or was INFOM1 found (because it is used in the ThresholdFilter), but not
   INFOP1?

   Remko

   On Thu, Aug 27, 2015 at 3:19 AM, Nicholas Duane nic...@msn.com wrote:

On to my next problem.  I'm trying to define a custom level in
configuration.  Not sure if it's working or not.  However, when I
  attempt
to get the level for that custom level I get back null, which I wasn't
expecting.  Here is the log4j2.xml config file:

?xml version=1.0 encoding=UTF-8?
Configuration status=trace verbose=true
  CustomLevels
CustomLevel name=INFOM1 intLevel=399/
CustomLevel name=INFOP1 intLevel=401/
  /CustomLevels
  Appenders
File name=info fileName=info.log
  PatternLayout
Pattern%d %p %c{1.} [%t] %m%n/Pattern
  /PatternLayout
  Filters
ThresholdFilter level=INFOM1 onMatch=DENY
  onMismatch=NEUTRAL/
ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
  /Filters
/File
  /Appenders
  Loggers
Logger name=HelloWorld level=ALL
  AppenderRef ref=info/
/Logger
Root
/Root
  /Loggers
/Configuration

Here is my code:

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import org.apache.logging.log4j.Level;

public class HelloWorld
{
static Logger log =
  LogManager.getLogger(HelloWorld.class.getName());

public static void main(String[] args)
{
  System.out.println(Hello, World);
  log.info(hello this is an INFO  message);
  log.warn(hello this is a WARN message);
  log.debug(hello this is a DEBUG message);
  Level level = Level.getLevel(INFOM1);
  if (level == null)
System.out.println(Didn't find level INFOM1);
  else
log.log(level, hello this is an INFOM1 message);
  level = Level.getLevel(INFOP1);
  if (level == null)
System.out.println(Didn't find level INFOP1);
  else
log.log(level, hello this is an INFOP1 message);
}
}

Any ideas?  I obviously don't want to use Level.forName() as that will
create the level if it doesn't exist and I want to ensure I'm pulling
  the
value from the configuration.

Thanks,
Nick

Re: custom levels via configuration

Custom log levels weren’t added to Log4j 2 until version 2.1, so if the version 
you are using is older than that it is no surprise that it isn’t working.

Ralph

 On Aug 26, 2015, at 2:34 PM, Nicholas Duane nic...@msn.com wrote:
 
 While I work on figuring out how to get a newer version of log4j2 installed 
 I'm wondering whether there is some additional investigation I can do with 
 the version I have.  For instance, I was hoping with the level of logging I 
 have enabled, that log4j would be indicating some issue it had with the 
 custom level.  However, I don't see such an issue.  The only thing I see is 
 an issue with the custom level, which I'm guessing is when I'm using it in 
 the filter.  I've attached the warning in the log below.
 
 Is there some additional logging I can turn on such that log4j will produce 
 more info which might indicate why my custom levels aren't working?  Here is 
 my current log4j2 configuration.
 
 log4j2.xml:
 
 ?xml version=1.0 encoding=UTF-8?
 Configuration status=trace verbose=true
  CustomLevels
CustomLevel name=INFOM1 intLevel=399/
CustomLevel name=INFOP1 intLevel=401/
  /CustomLevels
  Appenders
File name=info fileName=info.log
  PatternLayout
Pattern%d %p %c{1.} [%t] %m%n/Pattern
  /PatternLayout
  Filters
ThresholdFilter level=INFOM1 onMatch=DENY onMismatch=NEUTRAL/
ThresholdFilter level=INFO onMatch=ACCEPT onMismatch=DENY/
  /Filters
/File
  /Appenders
  Loggers
Logger name=HelloWorld level=ALL
  AppenderRef ref=info/
/Logger
Root
/Root
  /Loggers
 /Configuration
 
 snippet of console output:
 
 2015-08-26 14:26:21,070 WARN Error while converting string [INFOM1] to type 
 [class org.apache.logging.log4j.Level]. Using default value [null]. 
 java.lang.IllegalArgumentException: Unknown level constant [INFOM1].
at org.apache.logging.log4j.Level.valueOf(Level.java:281)
at 
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:240)
at 
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters$LevelConverter.convert(TypeConverters.java:237)
at 
 org.apache.logging.log4j.core.config.plugins.util.TypeConverters.convert(TypeConverters.java:343)
at 
 org.apache.logging.log4j.core.config.plugins.visitors.AbstractPluginVisitor.convert(AbstractPluginVisitor.java:130)
at 
 org.apache.logging.log4j.core.config.plugins.visitors.PluginAttributeVisitor.visit(PluginAttributeVisitor.java:44)
at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.generateParameters(PluginBuilder.java:233)
at 
 org.apache.logging.log4j.core.config.plugins.util.PluginBuilder.build(PluginBuilder.java:131)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createPluginObject(AbstractConfiguration.java:748)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:683)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.createConfiguration(AbstractConfiguration.java:675)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.doConfigure(AbstractConfiguration.java:349)
at 
 org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:150)
at 
 org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:358)
at 
 org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:416)
at 
 org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:146)
at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:75)
at 
 org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:37)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:473)
at HelloWorld.clinit(HelloWorld.java:7)
 
 Thanks,
 Nick
 
 Date: Wed, 26 Aug 2015 12:36:40 -0700
 Subject: Re: custom levels via configuration
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 We've never released a version 2.0-1.fc21 so it must be a Fedora build,
 presumably based on 2.0 or some fork of it.
 
 You need to test with version 2.3 or a 2.4-SNAPSHOT. I'll leave you to
 Google how to install 2.3 on Fedora ;-)
 
 Gary
 
 On Wed, Aug 26, 2015 at 12:14 PM, Nicholas Duane nic...@msn.com wrote:
 
 First off let me admit that I'm a noob at both Linux and java, and log4j
 for that matter.
 
 I don't know how to package anything so my class that you see is a simple
 java class which I compiled using javac.  I then run it using 'java
 HelloWorld'.  I'm running fedora 21.  When I do a 'yum list log4j' it says
 I have 2.0-1.fc21.
 
 Thanks,
 Nick
 
 Date: Wed, 26 Aug

RE: custom levels via configuration