On Mon, Mar 24, 2014 at 5:22 PM, Ralph Goers <[email protected]>wrote:
> I should also point out that if you convert Log4j 1.2 isGreaterOrEqual to
> Level.isGreaterOrEqual in Log4j 2 you are going to get the exact opposite
> of what you want. I have no idea why at this point, but the level values
> in Log4j 2 increase in the opposite order of Log4j 1, so the equivalent
> method in Log4j 2 to isGreaterOrEqual is Level.isAtLeastAsSpecificAs.
>
> Again, this is one of the reasons why the Greater and Less than methods
> should be dumped. The actual enum value shouldn’t matter.
>
Just document this:
version 1:
public final static int OFF_INT = Integer.MAX_VALUE;
public final static int FATAL_INT = 50000;
public final static int ERROR_INT = 40000;
public final static int WARN_INT = 30000;
public final static int INFO_INT = 20000;
public final static int DEBUG_INT = 10000;
//public final static int FINE_INT = DEBUG_INT;
public final static int ALL_INT = Integer.MIN_VALUE;
version 2:
/**
* No events will be logged.
*/
OFF(0),
/**
* A severe error that will prevent the application from continuing.
*/
FATAL(100),
/**
* An error in the application, possibly recoverable.
*/
ERROR(200),
/**
* An event that might possible lead to an error.
*/
WARN(300),
/**
* An event for informational purposes.
*/
INFO(400),
/**
* A general debugging event.
*/
DEBUG(500),
/**
* A fine-grained debug message, typically capturing the flow through
the application.
*/
TRACE(600),
/**
* All events should be logged.
*/
ALL(Integer.MAX_VALUE);
I'll fix isGreater... for now and ponder...
Gary
>
> Ralph
>
>
>
> On Mar 24, 2014, at 2:12 PM, Ralph Goers <[email protected]>
> wrote:
>
> This is one of the things that irks me about the level hierarchy (nothing
> to be done about that though).
>
> In a Filter it isn’t obvious whether a level has a higher or lower integer
> value without looking at the enum values. This is why the method is named
> isAtLeastAsSpecificAs since it is clearer that Debug is at least as
> specific as Warn.
>
> On the other hand, for efficiency Logger just does return intLevel >=
> Level.intLevel.
>
> From what I can tell the lessOrEqual methods (in my code I don’t see any
> isLessOrEqual methods) are not used anywhere within Log4j so I would prefer
> dumping these methods.
>
> Ralph
>
> On Mar 24, 2014, at 1:16 PM, Gary Gregory <[email protected]> wrote:
>
> In the Level class we have:
>
> org.apache.logging.log4j.Level.isAtLeastAsSpecificAs(int)
> org.apache.logging.log4j.Level.isAtLeastAsSpecificAs(Level)
>
> Which is implemented the same as way:
>
> org.apache.logging.log4j.Level.isLessOrEqual(int)
> org.apache.logging.log4j.Level.isLessOrEqual(Level)
>
> For compatibility with 1.2 (the server I am porting to v2 does not
> compile), I added:
>
> org.apache.logging.log4j.Level.isGreaterOrEqual(Level)
>
> and to match the above I also added:
>
> org.apache.logging.log4j.Level.isGreaterOrEqual(int)
>
> What to do about the duplication?
>
> Internally we use isAtLeastAsSpecificAs().
>
> I am inclined to dump isAtLeastAsSpecificAs in favor of isLessOrEqual.
>
> Thoughts?
>
> Gary
>
> --
> E-Mail: [email protected] | [email protected]
> 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: [email protected] | [email protected]
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
