Re: looking for source

[Nicholas Duane]

Great, that explains it.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Sunday, November 6, 2016 8:14 PM
To: Log4J Users List
Subject: Re: looking for source

Because most people want the exception printed PatternLayout includes the 
ExtendedThrowableConverter by default as the last parameter unless you specify 
%noex. The exception is normally not formatted by the Message.

Ralph

> On Nov 6, 2016, at 4:22 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> My configuration simply has %msg in the pattern layout to output the message. 
>  However, that seems to be outputting the message along with some serialized 
> representation of the exception.  I was looking at the message pattern 
> converter at:
>
>
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java
[https://avatars1.githubusercontent.com/u/47359?v=3=400]<https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java>

apache/logging-log4j2<https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java>
github.com
logging-log4j2 - Mirror of Apache Logging Log4J2


>
>
> which I assume is what formats the string for the %msg pattern.  Is that 
> correct?  I don't see in the code where it's getting the exception info, but 
> I guess it might already be in the Message object.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers <ralph.go...@dslextreme.com>
> Sent: Sunday, November 6, 2016 1:38 AM
> To: Log4J Users List
> Subject: Re: looking for source
>
> If you look at PatternLayout you will see a few choices for how the Exception 
> gets formatted. %ex uses printStackTrace to format the Exception, however 
> that is not the default. We extend the stack trace to also include the source 
> of each class (i.e. the jar or class directory) and its version, if it can be 
> determined. Other Layouts may, or may not, format the Exception depending on 
> what they are attempting to do.
>
> To take this further, there are many components that make up the log event - 
> the level, Marker, message (with or without parameters), time, ThreadContext 
> values, logger name, class name, method name, line number and the exception. 
> Each of these are discrete values that the Layout can format (or not) as it 
> chooses.
>
> Ralph
>
>> On Nov 5, 2016, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
>>
>> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
>> and how?  I guess I was hoping that the logging framework, eg. log4j, 
>> handled combining the message and the exception such that no matter what 
>> appender/layout you used you'd get consistent results.  Sounds like that's 
>> not the case.  So are you saying I need to combine the message and the 
>> exception myself within our appender/layout?
>>
>>
>> From the code I included below you can see we're doing:
>>
>>
>> String message = logEvent.getMessage().getFormattedMessage();
>>
>>
>> to get the event's message.  Are you saying we should be doing something 
>> like this:
>>
>>
>> StringWriter sw = new StringWriter();
>> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
>> String exceptionAsString = sw.toString();
>> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
>> exceptionAsString;
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Remko Popma <remko.po...@gmail.com <mailto:remko.po...@gmail.com>>
>> Sent: Saturday, November 5, 2016 9:16 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>>
>> The point is that in a custom layout/appender you should get the throwable 
>> from the LogEvent, not from the Message. That is the design that all Layouts 
>> and Appenders follow and should follow.
>>
>> The Message object passed to the Layout may no longer have the Throwable.
>>
>> Sent from my iPhone
>>
>>> On 6 Nov 2016, at 10:01, Nicholas Duane <nic...@msn.com> wrote:
>>>
>>> Thanks for the info.  Unfortunately I'm not following.  If someone can 
>>> point me to the source in question I will certainly look it over.  My 
>>> sample outputs the message (%msg) and when the method logger.error(String 
>>> message, Throwable t) is called it seems some code is combining the 
>>&g

Re: looking for source

[Nicholas Duane]

My configuration simply has %msg in the pattern layout to output the message.  
However, that seems to be outputting the message along with some serialized 
representation of the exception.  I was looking at the message pattern 
converter at:


https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern/MessagePatternConverter.java


which I assume is what formats the string for the %msg pattern.  Is that 
correct?  I don't see in the code where it's getting the exception info, but I 
guess it might already be in the Message object.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Sunday, November 6, 2016 1:38 AM
To: Log4J Users List
Subject: Re: looking for source

If you look at PatternLayout you will see a few choices for how the Exception 
gets formatted. %ex uses printStackTrace to format the Exception, however that 
is not the default. We extend the stack trace to also include the source of 
each class (i.e. the jar or class directory) and its version, if it can be 
determined. Other Layouts may, or may not, format the Exception depending on 
what they are attempting to do.

To take this further, there are many components that make up the log event - 
the level, Marker, message (with or without parameters), time, ThreadContext 
values, logger name, class name, method name, line number and the exception. 
Each of these are discrete values that the Layout can format (or not) as it 
chooses.

Ralph

> On Nov 5, 2016, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
> and how?  I guess I was hoping that the logging framework, eg. log4j, handled 
> combining the message and the exception such that no matter what 
> appender/layout you used you'd get consistent results.  Sounds like that's 
> not the case.  So are you saying I need to combine the message and the 
> exception myself within our appender/layout?
>
>
> From the code I included below you can see we're doing:
>
>
> String message = logEvent.getMessage().getFormattedMessage();
>
>
> to get the event's message.  Are you saying we should be doing something like 
> this:
>
>
> StringWriter sw = new StringWriter();
> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
> String exceptionAsString = sw.toString();
> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
> exceptionAsString;
>
>
> Thanks,
>
> Nick
>
> 
> From: Remko Popma <remko.po...@gmail.com <mailto:remko.po...@gmail.com>>
> Sent: Saturday, November 5, 2016 9:16 PM
> To: Log4J Users List
> Subject: Re: looking for source
>
> The point is that in a custom layout/appender you should get the throwable 
> from the LogEvent, not from the Message. That is the design that all Layouts 
> and Appenders follow and should follow.
>
> The Message object passed to the Layout may no longer have the Throwable.
>
> Sent from my iPhone
>
>> On 6 Nov 2016, at 10:01, Nicholas Duane <nic...@msn.com> wrote:
>>
>> Thanks for the info.  Unfortunately I'm not following.  If someone can point 
>> me to the source in question I will certainly look it over.  My sample 
>> outputs the message (%msg) and when the method logger.error(String message, 
>> Throwable t) is called it seems some code is combining the supplied string 
>> message with the exception message and stack trace.  Just wondering what 
>> code is doing that as I'm told someone using our appender/layout is not 
>> seeing the exception.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Remko Popma <remko.po...@gmail.com>
>> Sent: Friday, November 4, 2016 9:58 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>>
>> The Throwable is initially captured in the Message (usually 
>> ParameterizedMessage or its garbage-free equivalent), but is later 
>> transferred to the LogEvent.
>>
>> By the time the LogEvent reaches the Layout, the Message instance may be a 
>> different Object than the one that originally held the Throwable.
>>
>> The Layout should get the Throwable from the LogEvent, not from the Message.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>>> On 5 Nov 2016, at 7:50,Nicholas Duane <nic...@msn.com> wrote:
>>>
>>> Thanks for the replies.  Let me ask a more pointed question now as 
>>> rummaging through the source will probably take me hours.  I'm curious 
>>> about the overloads with the throwable, for instance:
>>>
>&

Re: looking for source

[Nicholas Duane]

Thanks, I'll check out the link you provided.


I guess since log4j2 exposes:


logger.error(String message);


and


logger.error(String message, Throwable t);


As well as a bunch of others, I wasn't sure if it was the logging framework 
that did the work of composing a single message out of the parameters to the 
call.  Otherwise you'll get different behavior using different appender/layout, 
as we're seeing with our appender/layout.


Thanks,

Nick


From: Remko Popma <remko.po...@gmail.com>
Sent: Saturday, November 5, 2016 10:03 PM
To: Log4J Users List
Subject: Re: looking for source

Nick,

If you want to combine the formatted message string and the stack trace into a 
single string in your layout then yes, that is one way to do that.

For reference, take a look at the MessagePatternConverter and 
ThrowablePatternConverter (used by Log4j's PatternLayout): 
https://github.com/apache/logging-log4j2/tree/master/log4j-core/src/main/java/org/apache/logging/log4j/core/pattern

Conceptually the Message and the Throwable are separate parts of the LogEvent. 
I think what may have caused some confusion is that initially 
ParameterizedMessage captures message parameters and the Throwable in a single 
vararg array, but please consider that an implementation detail.

Sent from my iPhone

> On 6 Nov 2016, at 10:33, Nicholas Duane <nic...@msn.com> wrote:
>
> Thanks.  I have no problem doing that.  Just wondering what needs to be done 
> and how?  I guess I was hoping that the logging framework, eg. log4j, handled 
> combining the message and the exception such that no matter what 
> appender/layout you used you'd get consistent results.  Sounds like that's 
> not the case.  So are you saying I need to combine the message and the 
> exception myself within our appender/layout?
>
>
> From the code I included below you can see we're doing:
>
>
> String message = logEvent.getMessage().getFormattedMessage();
>
>
> to get the event's message.  Are you saying we should be doing something like 
> this:
>
>
> StringWriter sw = new StringWriter();
> logEvent.getThrown().printStackTrace(new PrintWriter(sw));
> String exceptionAsString = sw.toString();
> String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
> exceptionAsString;
>
>
> Thanks,
>
> Nick
>
> 
> From: Remko Popma <remko.po...@gmail.com>
> Sent: Saturday, November 5, 2016 9:16 PM
> To: Log4J Users List
> Subject: Re: looking for source
>
> The point is that in a custom layout/appender you should get the throwable 
> from the LogEvent, not from the Message. That is the design that all Layouts 
> and Appenders follow and should follow.
>
> The Message object passed to the Layout may no longer have the Throwable.
>
> Sent from my iPhone
>
>> On 6 Nov 2016, at 10:01, Nicholas Duane <nic...@msn.com> wrote:
>>
>> Thanks for the info.  Unfortunately I'm not following.  If someone can point 
>> me to the source in question I will certainly look it over.  My sample 
>> outputs the message (%msg) and when the method logger.error(String message, 
>> Throwable t) is called it seems some code is combining the supplied string 
>> message with the exception message and stack trace.  Just wondering what 
>> code is doing that as I'm told someone using our appender/layout is not 
>> seeing the exception.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Remko Popma <remko.po...@gmail.com>
>> Sent: Friday, November 4, 2016 9:58 PM
>> To: Log4J Users List
>> Subject: Re: looking for source
>>
>> The Throwable is initially captured in the Message (usually 
>> ParameterizedMessage or its garbage-free equivalent), but is later 
>> transferred to the LogEvent.
>>
>> By the time the LogEvent reaches the Layout, the Message instance may be a 
>> different Object than the one that originally held the Throwable.
>>
>> The Layout should get the Throwable from the LogEvent, not from the Message.
>>
>> Remko
>>
>> Sent from my iPhone
>>
>>> On 5 Nov 2016, at 7:50,Nicholas Duane <nic...@msn.com> wrote:
>>>
>>> Thanks for the replies.  Let me ask a more pointed question now as 
>>> rummaging through the source will probably take me hours.  I'm curious 
>>> about the overloads with the throwable, for instance:
>>>
>>>
>>> logger.error("some message", );
>>>
>>>
>>> What's the expected behavior?  Meaning, what is the logging framework going 
>>> to do with the message and the exception?  I know the m

Re: looking for source

[Nicholas Duane]

Thanks.  I have no problem doing that.  Just wondering what needs to be done 
and how?  I guess I was hoping that the logging framework, eg. log4j, handled 
combining the message and the exception such that no matter what 
appender/layout you used you'd get consistent results.  Sounds like that's not 
the case.  So are you saying I need to combine the message and the exception 
myself within our appender/layout?


>From the code I included below you can see we're doing:


String message = logEvent.getMessage().getFormattedMessage();


to get the event's message.  Are you saying we should be doing something like 
this:


StringWriter sw = new StringWriter();
logEvent.getThrown().printStackTrace(new PrintWriter(sw));
String exceptionAsString = sw.toString();
String message = logEvent.getMessage().getFormattedMessage() + "\n" + 
exceptionAsString;


Thanks,

Nick


From: Remko Popma <remko.po...@gmail.com>
Sent: Saturday, November 5, 2016 9:16 PM
To: Log4J Users List
Subject: Re: looking for source

The point is that in a custom layout/appender you should get the throwable from 
the LogEvent, not from the Message. That is the design that all Layouts and 
Appenders follow and should follow.

The Message object passed to the Layout may no longer have the Throwable.

Sent from my iPhone

> On 6 Nov 2016, at 10:01, Nicholas Duane <nic...@msn.com> wrote:
>
> Thanks for the info.  Unfortunately I'm not following.  If someone can point 
> me to the source in question I will certainly look it over.  My sample 
> outputs the message (%msg) and when the method logger.error(String message, 
> Throwable t) is called it seems some code is combining the supplied string 
> message with the exception message and stack trace.  Just wondering what code 
> is doing that as I'm told someone using our appender/layout is not seeing the 
> exception.
>
>
> Thanks,
>
> Nick
>
> 
> From: Remko Popma <remko.po...@gmail.com>
> Sent: Friday, November 4, 2016 9:58 PM
> To: Log4J Users List
> Subject: Re: looking for source
>
> The Throwable is initially captured in the Message (usually 
> ParameterizedMessage or its garbage-free equivalent), but is later 
> transferred to the LogEvent.
>
> By the time the LogEvent reaches the Layout, the Message instance may be a 
> different Object than the one that originally held the Throwable.
>
> The Layout should get the Throwable from the LogEvent, not from the Message.
>
> Remko
>
> Sent from my iPhone
>
>> On 5 Nov 2016, at 7:50,Nicholas Duane <nic...@msn.com> wrote:
>>
>> Thanks for the replies.  Let me ask a more pointed question now as rummaging 
>> through the source will probably take me hours.  I'm curious about the 
>> overloads with the throwable, for instance:
>>
>>
>> logger.error("some message", );
>>
>>
>> What's the expected behavior?  Meaning, what is the logging framework going 
>> to do with the message and the exception?  I know the message is usually 
>> output via the message property in the pattern layout.  But what happens 
>> with the throwable?  Is there some code responsible for constructing a 
>> message which combines the supplied message with the throwable exception 
>> message and callstack?
>>
>>
>> I wrote the following simple java sample:
>>
>>
>> import org.apache.logging.log4j.Logger;
>> import org.apache.logging.log4j.LogManager;
>>
>> public class Test
>> {
>>   private static final Logger logger = LogManager.getLogger(Test.class);
>>
>>   public static void main(String[] args)
>>   {
>>logger.info("entered main");
>>   try
>>   {
>>   throw(new IllegalArgumentException("bad argument"));
>>   }
>>   catch(Throwable t)
>>   {
>>   logger.error("caught exception", t);
>>   }
>>   logger.info("exiting main");
>>   }
>> }
>>
>>
>> Here is the log4j2.xml file:
>>
>>
>> 
>> 
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>>   
>> 
>>
>>
>> Here is the output to the console when I run the sample:
>>
>>
>> [nick@thinkpad log4j]$ java Test
>> 16:37:57.681 [main] INFO  Test - entered main
>> 16:37:57.683 [main] ERROR Test - caught exception
>> java.lang.IllegalArgumentException: bad argument
>>   at Test.main(Test.java:13) [log4j/:?]
>> 16:37:57.689 [main] INFO  Test - exiting main
>>
>>
>> S

Re: looking for source

[Nicholas Duane]

Thanks for the info.  Unfortunately I'm not following.  If someone can point me 
to the source in question I will certainly look it over.  My sample outputs the 
message (%msg) and when the method logger.error(String message, Throwable t) is 
called it seems some code is combining the supplied string message with the 
exception message and stack trace.  Just wondering what code is doing that as 
I'm told someone using our appender/layout is not seeing the exception.


Thanks,

Nick


From: Remko Popma <remko.po...@gmail.com>
Sent: Friday, November 4, 2016 9:58 PM
To: Log4J Users List
Subject: Re: looking for source

The Throwable is initially captured in the Message (usually 
ParameterizedMessage or its garbage-free equivalent), but is later transferred 
to the LogEvent.

By the time the LogEvent reaches the Layout, the Message instance may be a 
different Object than the one that originally held the Throwable.

The Layout should get the Throwable from the LogEvent, not from the Message.

Remko

Sent from my iPhone

> On 5 Nov 2016, at 7:50,Nicholas Duane <nic...@msn.com> wrote:
>
> Thanks for the replies.  Let me ask a more pointed question now as rummaging 
> through the source will probably take me hours.  I'm curious about the 
> overloads with the throwable, for instance:
>
>
> logger.error("some message", );
>
>
> What's the expected behavior?  Meaning, what is the logging framework going 
> to do with the message and the exception?  I know the message is usually 
> output via the message property in the pattern layout.  But what happens with 
> the throwable?  Is there some code responsible for constructing a message 
> which combines the supplied message with the throwable exception message and 
> callstack?
>
>
> I wrote the following simple java sample:
>
>
> import org.apache.logging.log4j.Logger;
> import org.apache.logging.log4j.LogManager;
>
> public class Test
> {
>private static final Logger logger = LogManager.getLogger(Test.class);
>
>public static void main(String[] args)
>{
> logger.info("entered main");
>try
>{
>throw(new IllegalArgumentException("bad argument"));
>}
>catch(Throwable t)
>{
>logger.error("caught exception", t);
>}
>logger.info("exiting main");
>}
> }
>
>
> Here is the log4j2.xml file:
>
>
> 
> 
>
>
>
>
>
>
>
>
>
>
> 
>
>
> Here is the output to the console when I run the sample:
>
>
> [nick@thinkpad log4j]$ java Test
> 16:37:57.681 [main] INFO  Test - entered main
> 16:37:57.683 [main] ERROR Test - caught exception
> java.lang.IllegalArgumentException: bad argument
>at Test.main(Test.java:13) [log4j/:?]
> 16:37:57.689 [main] INFO  Test - exiting main
>
>
> So there does seem to be some code which is combining the message with the 
> exception.  Just wondering where that happens.  Now onto my specific problem. 
>  We've got someone saying that when they use the error() method which takes a 
> string message and an throwable the exception information is not making it to 
> our central repository.  We have written our own appender and our own layout. 
>  Here is a snippet from our appender:
>
>
> String serializedEvent = (String) getLayout().toSerializable(logEvent);
>
> Here is a snippet from our layout:
>
>
> String message = logEvent.getMessage().getFormattedMessage();
>
>
> It seems the message above does not include any exception info.  What are we 
> doing wrong?
>
>
> Thanks,
>
> Nick
>
> 
> From: Remko Popma <remko.po...@gmail.com>
> Sent: Friday, November 4, 2016 10:42 AM
> To: Log4J Users List
> Subject: Re: looking for source
>
> Sure. Start in AbstractLogger in the API module: 
> https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java
[https://avatars1.githubusercontent.com/u/47359?v=3=400]<https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java>

apache/logging-log4j2<https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java>
github.com
logging-log4j2 - Mirror of Apache Logging Log4J2


>
> and at some point you probably also want to look at the concrete subclass 
> Logger in the core module: 
> https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/Logger.java
[https:

Re: looking for source

[Nicholas Duane]

Thanks for the replies.  Let me ask a more pointed question now as rummaging 
through the source will probably take me hours.  I'm curious about the 
overloads with the throwable, for instance:


logger.error("some message", );


What's the expected behavior?  Meaning, what is the logging framework going to 
do with the message and the exception?  I know the message is usually output 
via the message property in the pattern layout.  But what happens with the 
throwable?  Is there some code responsible for constructing a message which 
combines the supplied message with the throwable exception message and 
callstack?


I wrote the following simple java sample:


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

public class Test
{
private static final Logger logger = LogManager.getLogger(Test.class);

public static void main(String[] args)
{
 logger.info("entered main");
try
{
throw(new IllegalArgumentException("bad argument"));
}
catch(Throwable t)
{
logger.error("caught exception", t);
}
logger.info("exiting main");
}
}


Here is the log4j2.xml file:

















Here is the output to the console when I run the sample:


[nick@thinkpad log4j]$ java Test
16:37:57.681 [main] INFO  Test - entered main
16:37:57.683 [main] ERROR Test - caught exception
java.lang.IllegalArgumentException: bad argument
at Test.main(Test.java:13) [log4j/:?]
16:37:57.689 [main] INFO  Test - exiting main


So there does seem to be some code which is combining the message with the 
exception.  Just wondering where that happens.  Now onto my specific problem.  
We've got someone saying that when they use the error() method which takes a 
string message and an throwable the exception information is not making it to 
our central repository.  We have written our own appender and our own layout.  
Here is a snippet from our appender:


String serializedEvent = (String) getLayout().toSerializable(logEvent);

Here is a snippet from our layout:


String message = logEvent.getMessage().getFormattedMessage();


It seems the message above does not include any exception info.  What are we 
doing wrong?


Thanks,

Nick


From: Remko Popma <remko.po...@gmail.com>
Sent: Friday, November 4, 2016 10:42 AM
To: Log4J Users List
Subject: Re: looking for source

Sure. Start in AbstractLogger in the API module: 
https://github.com/apache/logging-log4j2/blob/master/log4j-api/src/main/java/org/apache/logging/log4j/spi/AbstractLogger.java

and at some point you probably also want to look at the concrete subclass 
Logger in the core module: 
https://github.com/apache/logging-log4j2/blob/master/log4j-core/src/main/java/org/apache/logging/log4j/core/Logger.java

Hope this helps to get you started.

It may be easier to use an IDE and check out the whole project 
(https://logging.apache.org/log4j/2.x/source-repository.html).
Log4j - Source Repository - Apache Log4j 
2<https://logging.apache.org/log4j/2.x/source-repository.html>
logging.apache.org
Access from Behind a Firewall. Refer to the documentation of the SCM used for 
more information about access behind a firewall.



Enjoy!
Remko

Sent from my iPhone

> On 4 Nov 2016, at 23:29, Nicholas Duane <nic...@msn.com> wrote:
>
> I'm not that familiar with java and java conventions, package names, etc.  
> I'm trying to find the source for log4j2's implementation of 
> logger.error(String, Throwable);.  Can someone point me to that?  I was 
> looking around here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=tree;hb=refs/heads/master
>
>
> But couldn't seem to find what I was looking for.
>
>
> Thanks,
>
> Nick

Re: porting log4j2 to .NET

[Nicholas Duane]

I could possible offer some assistance if the effort would be along the lines 
of porting log4j2 to .NET.  As I mentioned, I had suggested this on the log4net 
mailing list and while they were not totally against it there seemed some 
concern, rightly so, on the overall effort and possibly not being backwards 
compatible.  I wouldn't be interested in helping move log4net along in a 
different direction than log4j2 as I think that's the wrong decision.


Thanks,

Nick


From: Matt Sicker <boa...@gmail.com>
Sent: Wednesday, October 19, 2016 9:59 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

That would be great. From what I recall, the two main log4net developers
are pretty busy with other things now and can only provide some maintenance
work on log4net. We have tweeted and blogged about this in the recent past
looking for some new developers. I personally haven't used C# since
college, and the .net framework has changed a lot since then, so I don't
feel competent enough to spearhead a log4net2 or anything like that myself.

On 19 October 2016 at 02:45, Mikael Ståldal <mikael.stal...@magine.com>
wrote:

> It seems to me that a (conceptually) simple and constructive way forward
> would be to improve or redo (depending on the current state of it) Log4Net
> to be on par with with Log4j 2.x in terms of architecture and features
> (such as support for markers).
>
> Log4j is currently the most advanced and comprehensive logging framework,
> so let's model the others after it.
>
> On Wed, Oct 19, 2016 at 3:36 AM, Nicholas Duane <nic...@msn.com> wrote:
>
> > But I'm not suggesting a code base that will run everywhere.  As I said,
> > I'm not talking about a single source code base.  What I'm suggesting is
> a
> > single design/architecture which is then implemented across a set of
> > runtimes/OS's.  As opposed to what seems to be the case now where log4j
> is
> > its own team with it's own design and log4net, I guess, was originally a
> > port of log4j but might be moving in its own direction.
> >
> >
> > I suggested the same to the log4net team.  And while it could be the case
> > that I could help with the log4net effort, I would not be interested in
> it
> > going off in its own direction as I see a big benefit in having similar
> > logging frameworks across Java and .NET.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Ralph Goers <ralph.go...@dslextreme.com>
> > Sent: Tuesday, October 18, 2016 8:08 PM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > I feel lost because I don’t understand the concept of a code base that
> > will run everywhere in any language. The run everywhere part is called
> > “Java”. The run in any language part doesn’t exist as far as I know, let
> > alone when combined with “run everywhere”. So I don’t know where that
> part
> > of the discussion is coming from.
> >
> > It would be possible to create implementations of the Log4j design in
> > multiple languages, but we would need many more committers with skills in
> > those various languages to do it.  To be sure, I would love to see that
> > happen, but it isn’t possible with the set of committers who actively
> > contribute to the logging project today. If you are volunteering to kick
> > that off we won’t get in your way.
> >
> > Ralph
> >
> >
> >
> > > On Oct 18, 2016, at 1:53 PM, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > > Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area
> > where the implementation will cause variations, in the config for
> > instance.  And with respect to asynchronous appenders, that might even
> be a
> > feature missing in some implementations if support for it would be too
> > difficult.
> > >
> > >
> > > By the way, thanks to everyone for putting up with my questions as I
> try
> > to work though the issues I have with our implementation.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Ralph Goers <ralph.go...@dslextreme.com <mailto:ralph.goers@
> > dslextreme.com>>
> > > Sent: Tuesday, October 18, 2016 4:25 PM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > I’ve gotten completely lost in this conversation.
> > >
> > > The design certainly doesn’t need to know about the language, but
> > certain design features have to be implemen

Re: approach for defining loggers

[Nicholas Duane]

I don't believe there is a severity to our compliance and business events.  I 
could be wrong.  If they had a severity it would certainly make them fit into 
the logging model more cleanly, but I just don't see it.  And I just had this 
discussion with one of my colleagues.  They were suggesting a result code for a 
business event.  However, I pointed out that you'd only need that if you 
planned on logging failed business events, which is what he was thinking.  
Would you just log the failed business event or maybe the failed business event 
and an error event?  Would a failure business event go into the business event 
store or the critical diagnostic (errors, warnings, info) store?  We might have 
systems management people monitoring the critical diagnostics store to see 
what, if any, issues are currently happening thus just logging a failed 
business event might not set of any alarms.  Though you could say that a failed 
business event it not a critical diagnostics events.  Maybe it's just a 
business failure event.  For instance, low balance.  Though I probably see a 
low balance as yet another business event, not a failure of some other business 
event.


Just in case anyone is wondering I should probably make this clear, none of the 
logging we're doing is for auditing.  We made it perfectly clear that events 
can be lost and thus you should not be using the logging frameworks and these 
events to audit.  I have a clear definition for an audit, "if you fail to audit 
then you fail the application transaction".


I'm thinking our compliance and business events would have fit nicely into the 
EventLogger.  As I mentioned, there are two issues I have with the event 
logger.  Therefore I'm thinking that maybe we provide some methods to log these 
events to the All level in an attempt to implement something similar to the 
EventLogger but do it against a private logger.  So something like this (pseudo 
code):


public class ExtensionMethods

{

public void LogEvent(Logger logger, object evnt);


or


public void LogEvent(Logger logger, String category, object evnt);

}


The other thing I'll need to make sure is that we have a way to distinguish 
between our different categories of events.  I won't use Markers as they don't 
exist on log4net and we have a "category" property anyway so I think I can use 
that.


Thanks,

Nick


From: Gary Gregory <garydgreg...@gmail.com>
Sent: Monday, October 17, 2016 10:46 PM
To: Log4J Users List
Subject: Re: approach for defining loggers

On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <nic...@msn.com> wrote:

> Sorry to revive this old thread.  However, we're in the process of adding
> support for other "categories" of events and thus I wanted to first take a
> step back and try to ensure we're not convoluting things.
>
>
> There was a requirement to log a "compliance" event under certain
> conditions.  We did not want to write our own logging framework and instead
> decided to use existing off-the-shelf logging frameworks.  We have
> applications on both Linux/Java, Windows/.NET and Windows/Java.  Initially
> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> Linux/Java.  For these logging frameworks we wrote artifacts, appenders
> basically, to help facilitate getting these events to our system.  By the
> way, our system will get the events centrally, possibly put them into a
> relational database and also hand them off to another system which will get
> them eventually to an HDFS backend.  We also exposed methods for creating
> this compliance event.  The compliance event is basically a map.  We chose
> a map so that the event could also be extended by the application team in
> case they needed to add additional properties which made sense for them.
>
>
> We chose to create a custom level for this "compliance" event such that we
> could filter out only these events and get them into our system.  The
> configuration example we created had our custom unix domain socket appender
> added to the root logger.  It also contained a filter which filtered out
> any events that weren't compliance events.  The level we chose for
> "compliance" was less critical than off and more critical than fatal as we
> wanted to ensure that as long as logging wasn't turned off altogether our
> events would get logged.
>
>
> I want to go over a few suggestions that were made and explain why I
> didn't make use of those suggestions.
>
>
> 1. Since our "compliance" level didn't fit within the "vernacular" of the
> existing levels we should not define this custom level.  Instead we should
> look at using markers.
>

Yes, this is a use case for markers. The level should be used to note how
important is each compliance event.

Re: porting log4j2 to .NET

[Nicholas Duane]

A similar analogy might be EMS.  EMS is a specification.  There is a java 
implementation, JMS.  I know TIBCO also has C/C++ and C# implementations on 
Windows.  I think the C# one is a wrapper around their C/C++ implementation.  I 
assume there is also a C/C++ implementation on Linux.


Thanks,

Nick


From: Nicholas Duane <nic...@msn.com>
Sent: Tuesday, October 18, 2016 9:36 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

But I'm not suggesting a code base that will run everywhere.  As I said, I'm 
not talking about a single source code base.  What I'm suggesting is a single 
design/architecture which is then implemented across a set of runtimes/OS's.  
As opposed to what seems to be the case now where log4j is its own team with 
it's own design and log4net, I guess, was originally a port of log4j but might 
be moving in its own direction.


I suggested the same to the log4net team.  And while it could be the case that 
I could help with the log4net effort, I would not be interested in it going off 
in its own direction as I see a big benefit in having similar logging 
frameworks across Java and .NET.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Tuesday, October 18, 2016 8:08 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I feel lost because I don’t understand the concept of a code base that will run 
everywhere in any language. The run everywhere part is called “Java”. The run 
in any language part doesn’t exist as far as I know, let alone when combined 
with “run everywhere”. So I don’t know where that part of the discussion is 
coming from.

It would be possible to create implementations of the Log4j design in multiple 
languages, but we would need many more committers with skills in those various 
languages to do it.  To be sure, I would love to see that happen, but it isn’t 
possible with the set of committers who actively contribute to the logging 
project today. If you are volunteering to kick that off we won’t get in your 
way.

Ralph



> On Oct 18, 2016, at 1:53 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
> the implementation will cause variations, in the config for instance.  And 
> with respect to asynchronous appenders, that might even be a feature missing 
> in some implementations if support for it would be too difficult.
>
>
> By the way, thanks to everyone for putting up with my questions as I try to 
> work though the issues I have with our implementation.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>>
> Sent: Tuesday, October 18, 2016 4:25 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> I’ve gotten completely lost in this conversation.
>
> The design certainly doesn’t need to know about the language, but certain 
> design features have to be implementable.
>
> For example, to use the same configuration each implementation would have to 
> support the plugin concept. The Java implementation relies upon annotations 
> to do this. .NET has something similar but other languages may not.  
> Asynchronous Loggers take advantage of a highly optimized concurrent queue.  
> Although you might be able to create something equivalent in other languages 
> it might not scale as well. Then again, some languages don’t support 
> multi-threading so either might require all loggers to be synchronous.
>
> Ralph
>
>> On Oct 18, 2016, at 10:22 AM, Nicholas Duane <nic...@msn.com> wrote:
>>
>> I guess I don't agree.  And just to be clear, I'm not talking about trying 
>> to have a huge percentage, or any at all really, of single source and then 
>> glue code around it for the various runtimes/OS's you're targeting.
>>
>>
>> I'm not that familiar with log4j2 but I would assume you have:
>>
>>
>> * a core engine with accepts events and then runs them through some checks 
>> before throwing them out or sending them along their way.
>>
>>
>> * seems the major abstraction is the appender.
>>
>>
>> * some other abstractions like filters and layouts.
>>
>>
>> * configuration
>>
>>
>> * an object model such that most, if not all, can be configured 
>> programmatically
>>
>>
>> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
>> design for this has to know what runtime/language it's targeting.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Matt Sicker <boa...@gmail.com <mailt

Re: porting log4j2 to .NET

[Nicholas Duane]

But I'm not suggesting a code base that will run everywhere.  As I said, I'm 
not talking about a single source code base.  What I'm suggesting is a single 
design/architecture which is then implemented across a set of runtimes/OS's.  
As opposed to what seems to be the case now where log4j is its own team with 
it's own design and log4net, I guess, was originally a port of log4j but might 
be moving in its own direction.


I suggested the same to the log4net team.  And while it could be the case that 
I could help with the log4net effort, I would not be interested in it going off 
in its own direction as I see a big benefit in having similar logging 
frameworks across Java and .NET.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Tuesday, October 18, 2016 8:08 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I feel lost because I don’t understand the concept of a code base that will run 
everywhere in any language. The run everywhere part is called “Java”. The run 
in any language part doesn’t exist as far as I know, let alone when combined 
with “run everywhere”. So I don’t know where that part of the discussion is 
coming from.

It would be possible to create implementations of the Log4j design in multiple 
languages, but we would need many more committers with skills in those various 
languages to do it.  To be sure, I would love to see that happen, but it isn’t 
possible with the set of committers who actively contribute to the logging 
project today. If you are volunteering to kick that off we won’t get in your 
way.

Ralph



> On Oct 18, 2016, at 1:53 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
> the implementation will cause variations, in the config for instance.  And 
> with respect to asynchronous appenders, that might even be a feature missing 
> in some implementations if support for it would be too difficult.
>
>
> By the way, thanks to everyone for putting up with my questions as I try to 
> work though the issues I have with our implementation.
>
>
> Thanks,
>
> Nick
>
> 
> From: Ralph Goers <ralph.go...@dslextreme.com 
> <mailto:ralph.go...@dslextreme.com>>
> Sent: Tuesday, October 18, 2016 4:25 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> I’ve gotten completely lost in this conversation.
>
> The design certainly doesn’t need to know about the language, but certain 
> design features have to be implementable.
>
> For example, to use the same configuration each implementation would have to 
> support the plugin concept. The Java implementation relies upon annotations 
> to do this. .NET has something similar but other languages may not.  
> Asynchronous Loggers take advantage of a highly optimized concurrent queue.  
> Although you might be able to create something equivalent in other languages 
> it might not scale as well. Then again, some languages don’t support 
> multi-threading so either might require all loggers to be synchronous.
>
> Ralph
>
>> On Oct 18, 2016, at 10:22 AM, Nicholas Duane <nic...@msn.com> wrote:
>>
>> I guess I don't agree.  And just to be clear, I'm not talking about trying 
>> to have a huge percentage, or any at all really, of single source and then 
>> glue code around it for the various runtimes/OS's you're targeting.
>>
>>
>> I'm not that familiar with log4j2 but I would assume you have:
>>
>>
>> * a core engine with accepts events and then runs them through some checks 
>> before throwing them out or sending them along their way.
>>
>>
>> * seems the major abstraction is the appender.
>>
>>
>> * some other abstractions like filters and layouts.
>>
>>
>> * configuration
>>
>>
>> * an object model such that most, if not all, can be configured 
>> programmatically
>>
>>
>> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
>> design for this has to know what runtime/language it's targeting.
>>
>>
>> Thanks,
>>
>> Nick
>>
>> 
>> From: Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com> 
>> <mailto:boa...@gmail.com <mailto:boa...@gmail.com>>>
>> Sent: Tuesday, October 18, 2016 12:22 PM
>> To: Log4J Users List
>> Subject: Re: porting log4j2 to .NET
>>
>> Really, the only portable-ish way to make a common framework would be to
>> write them in C or Rust or something and make glue code for every runtime
>> out there. JVM users tend to prefer Java-native libraries over
>> 

Re: porting log4j2 to .NET

[Nicholas Duane]

Doesn't sound like you're too lost.  Yes, plug-ins certainly is an area where 
the implementation will cause variations, in the config for instance.  And with 
respect to asynchronous appenders, that might even be a feature missing in some 
implementations if support for it would be too difficult.


By the way, thanks to everyone for putting up with my questions as I try to 
work though the issues I have with our implementation.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Tuesday, October 18, 2016 4:25 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

I’ve gotten completely lost in this conversation.

The design certainly doesn’t need to know about the language, but certain 
design features have to be implementable.

For example, to use the same configuration each implementation would have to 
support the plugin concept. The Java implementation relies upon annotations to 
do this. .NET has something similar but other languages may not.  Asynchronous 
Loggers take advantage of a highly optimized concurrent queue.  Although you 
might be able to create something equivalent in other languages it might not 
scale as well.  Then again, some languages don’t support multi-threading so 
either might require all loggers to be synchronous.

Ralph

> On Oct 18, 2016, at 10:22 AM, Nicholas Duane <nic...@msn.com> wrote:
>
> I guess I don't agree.  And just to be clear, I'm not talking about trying to 
> have a huge percentage, or any at all really, of single source and then glue 
> code around it for the various runtimes/OS's you're targeting.
>
>
> I'm not that familiar with log4j2 but I would assume you have:
>
>
> * a core engine with accepts events and then runs them through some checks 
> before throwing them out or sending them along their way.
>
>
> * seems the major abstraction is the appender.
>
>
> * some other abstractions like filters and layouts.
>
>
> * configuration
>
>
> * an object model such that most, if not all, can be configured 
> programmatically
>
>
> I'm sure there's some stuff I'm missing.  Still not sure why most of the 
> design for this has to know what runtime/language it's targeting.
>
>
> Thanks,
>
> Nick
>
> 
> From: Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> Sent: Tuesday, October 18, 2016 12:22 PM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Really, the only portable-ish way to make a common framework would be to
> write them in C or Rust or something and make glue code for every runtime
> out there. JVM users tend to prefer Java-native libraries over
> JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
> other runtimes.
>
> On 18 October 2016 at 10:11, Mikael Ståldal <mikael.stal...@magine.com>
> wrote:
>
>> In my opinion, one of the major benefits of Log4j is its comprehensive
>> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
>> This will automatically benefit all users of Log4j, regardless of language
>> (on the JVM) and OS (that you can run the JVM on). But this does not extend
>> to other runtimes (e.g. .Net).
>>
>> Another benefit is that your application and 3rd party frameworks/libraries
>> you use can log via the same framework and you can collect the logs
>> together. This does not extend to other runtimes either, since you won't
>> use the same libraries.
>>
>> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker <boa...@gmail.com> wrote:
>>
>>> I'm saying the architecture of the code depends on the language you're
>>> using. Different design patterns apply to different languages, for
>>> instance. A logging framework in Java and C# might be very similar, but
>>> they'd look quite different from one written entirely in Clojure or F#.
>> The
>>> general concept of appenders, loggers, filters, etc., would all probably
>>> apply, but the APIs would probably differ a lot. This would affect plugin
>>> authors more than users of the library, but the only common things I
>> could
>>> see happening between different languages might be a similar API in a
>>> Logger class or module.
>>>
>>> On 18 October 2016 at 09:45, Nicholas Duane <nic...@msn.com> wrote:
>>>
>>>> I just mentioned the config as one piece where I think it would be very
>>>> useful to have similar, if not exactly the same, configs across
>>>> implementations.  I also realize that it might not be possible.
>>>>
>>>>
>>>> So are you saying that when you get to designing a logging f

Re: porting log4j2 to .NET

[Nicholas Duane]

I guess I don't agree.  And just to be clear, I'm not talking about trying to 
have a huge percentage, or any at all really, of single source and then glue 
code around it for the various runtimes/OS's you're targeting.


I'm not that familiar with log4j2 but I would assume you have:


* a core engine with accepts events and then runs them through some checks 
before throwing them out or sending them along their way.


* seems the major abstraction is the appender.


* some other abstractions like filters and layouts.


* configuration


* an object model such that most, if not all, can be configured programmatically


I'm sure there's some stuff I'm missing.  Still not sure why most of the design 
for this has to know what runtime/language it's targeting.


Thanks,

Nick


From: Matt Sicker <boa...@gmail.com>
Sent: Tuesday, October 18, 2016 12:22 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Really, the only portable-ish way to make a common framework would be to
write them in C or Rust or something and make glue code for every runtime
out there. JVM users tend to prefer Java-native libraries over
JNI/JNA/whatever type libraries, and I'm sure that's not uncommon in some
other runtimes.

On 18 October 2016 at 10:11, Mikael Ståldal <mikael.stal...@magine.com>
wrote:

> In my opinion, one of the major benefits of Log4j is its comprehensive
> ecosystem of plugins (appenders, layouts, etc), both bundled and 3rd party.
> This will automatically benefit all users of Log4j, regardless of language
> (on the JVM) and OS (that you can run the JVM on). But this does not extend
> to other runtimes (e.g. .Net).
>
> Another benefit is that your application and 3rd party frameworks/libraries
> you use can log via the same framework and you can collect the logs
> together. This does not extend to other runtimes either, since you won't
> use the same libraries.
>
> On Tue, Oct 18, 2016 at 5:03 PM, Matt Sicker <boa...@gmail.com> wrote:
>
> > I'm saying the architecture of the code depends on the language you're
> > using. Different design patterns apply to different languages, for
> > instance. A logging framework in Java and C# might be very similar, but
> > they'd look quite different from one written entirely in Clojure or F#.
> The
> > general concept of appenders, loggers, filters, etc., would all probably
> > apply, but the APIs would probably differ a lot. This would affect plugin
> > authors more than users of the library, but the only common things I
> could
> > see happening between different languages might be a similar API in a
> > Logger class or module.
> >
> > On 18 October 2016 at 09:45, Nicholas Duane <nic...@msn.com> wrote:
> >
> > > I just mentioned the config as one piece where I think it would be very
> > > useful to have similar, if not exactly the same, configs across
> > > implementations.  I also realize that it might not be possible.
> > >
> > >
> > > So are you saying that when you get to designing a logging framework
> you
> > > first have to know what language/runtime you're designing it for?  I
> > would
> > > think not.  Hopefully most, if not all, can be designed OS/runtime
> > agnostic
> > > and without having to design to a lowest common denominator.
> > >
> > >
> > > Also not sure about the OOP thing.  As far as I can tell, OOP is just a
> > > convenience thing, syntactic sugar.  I believe you can do the same in a
> > > procedural language.
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> > > 
> > > From: Matt Sicker <boa...@gmail.com>
> > > Sent: Tuesday, October 18, 2016 10:37 AM
> > > To: Log4J Users List
> > > Subject: Re: porting log4j2 to .NET
> > >
> > > Every programming language has its own idioms, and that even goes for
> all
> > > the various JVM languages as demonstrated by the log4j-scala API.
> Unless
> > > you mean more of an architectural thing with a similar config format,
> > then
> > > that might be more possible, but even that relies on a language being
> > > mostly OOP or mostly procedural or mostly functional or some other
> exotic
> > > thing.
> > >
> > > On 18 October 2016 at 09:23, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > > > I agree.  I'm also one for not coding to the lowest common
> denominator.
> > > > That's one reason we're not using a logging facade as I assume with a
> > > > facade you get only the features that are common across the s

Re: porting log4j2 to .NET

[Nicholas Duane]

I just mentioned the config as one piece where I think it would be very useful 
to have similar, if not exactly the same, configs across implementations.  I 
also realize that it might not be possible.


So are you saying that when you get to designing a logging framework you first 
have to know what language/runtime you're designing it for?  I would think not. 
 Hopefully most, if not all, can be designed OS/runtime agnostic and without 
having to design to a lowest common denominator.


Also not sure about the OOP thing.  As far as I can tell, OOP is just a 
convenience thing, syntactic sugar.  I believe you can do the same in a 
procedural language.


Thanks,

Nick


From: Matt Sicker <boa...@gmail.com>
Sent: Tuesday, October 18, 2016 10:37 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Every programming language has its own idioms, and that even goes for all
the various JVM languages as demonstrated by the log4j-scala API. Unless
you mean more of an architectural thing with a similar config format, then
that might be more possible, but even that relies on a language being
mostly OOP or mostly procedural or mostly functional or some other exotic
thing.

On 18 October 2016 at 09:23, Nicholas Duane <nic...@msn.com> wrote:

> I agree.  I'm also one for not coding to the lowest common denominator.
> That's one reason we're not using a logging facade as I assume with a
> facade you get only the features that are common across the set of logging
> frameworks the facade supports.
>
>
> What I'm suggesting is to come up with a design and architecture which is
> language/runtime/OS agnostic.  While it's easy for me to say that I
> wouldn't be surprised if it's more difficult to achieve.  When it comes to
> implementation I would assume the features might manifest themselves in
> different ways across the different languages/runtimes/OS's.  For instance,
> .NET has extension methods and Java doesn't.  You might decide to implement
> some features in .NET using extension methods and in Java you'll have to
> pick a different way to implement.  Configuration might be another area
> where there are differences among the different runtimes and thus the
> implementation might be a bit different.  Maybe there's even a feature that
> one implementation has that others don't just because there is no way, or
> no easy enough way to implement.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal <mikael.stal...@magine.com>
> Sent: Tuesday, October 18, 2016 10:04 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
> you run on the JVM (Java, Scala, Groovy, Clojure, etc).
>
> I guess it would be nice to have similar logging framework for other
> runtimes (such as .Net). However, I would not like to constrain Log4j to
> only use features available on both JVM and .Net.
>
> On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal <mikael.stal...@magine.com>
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> >

Re: porting log4j2 to .NET

[Nicholas Duane]

I did look a bit into syslog.  That appeared to be the defacto standard for 
logging, though it also seems that many just write to their own log files.  The 
other constraint we had was working in a PaaS environment and thus writing to 
local disk might not be possible.  While I'm not sure whether we're going to be 
running in a PaaS environment, that's what was in the back of our minds as we 
were developing the solution.  We wrote a unix domain socket appender which we 
use to send events to a daemon we have running.  This daemon buffers events in 
memory and when the buffer is full it compresses it and sends it via http to 
one of our endpoints.


Thanks,

Nick


From: Mikael Ståldal <mikael.stal...@magine.com>
Sent: Tuesday, October 18, 2016 10:06 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

...or a standardized non-binary format (like GELF, JSON based).

On Tue, Oct 18, 2016 at 3:58 PM, Matt Sicker <boa...@gmail.com> wrote:

> Using syslog is a pretty standard way to collect logs from all sorts of
> programs and goes back decades. There has been an update to the syslog
> format in RFC 5424 which fleshes it out a bunch.
>
> Then there are programs like Logstash and Flume which can be used in a more
> platform-agnostic manner to collect logs from different applications.
>
> Really, when it comes down to it, the most standard way you can log
> everything regardless of programming language is to use log files or some
> sort of network appender using a standardized binary format.
>
> On 18 October 2016 at 08:53, Nicholas Duane <nic...@msn.com> wrote:
>
> > I guess platform is vague.  Maybe I should have said language agnostic.
> > It would be nice to have a single logging architecture/design run on
> C/C++,
> > .NET, Java, etc.  Or at least it seems like a nice feature to me.  I
> would
> > assume there are many enterprises out there that have applications
> running
> > on different OS's and languages.  If I'm trying to pick a logging
> framework
> > to use and I find a popular one which is capable and runs similarly
> across
> > the OS's and languages then that's a big plus in my mind.
> >
> >
> > Thanks,
> >
> > Nick
> >
> > 
> > From: Mikael Ståldal <mikael.stal...@magine.com>
> > Sent: Tuesday, October 18, 2016 2:52 AM
> > To: Log4J Users List
> > Subject: Re: porting log4j2 to .NET
> >
> > Just to make things clear, Log4j is a logging framework for the JVM
> > platform, and it is agnostic to the underlying OS. It it well tested on
> (at
> > least) both Linux and Windows.
> >
> > On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > > Figured I would send this question out to the log4j side.  I have
> already
> > > had some email exchanges with the log4net mailing list regarding
> porting
> > > log4j2 to .NET.  My suggestion was that the apache logging framework
> be a
> > > single architecture design which is platform agnostic and then teams
> > which
> > > port to the different platforms.  It seems log4net was a port of log4j
> > and
> > > may be going off in its own direction from that initial port.  My
> > viewpoint
> > > is that's a bad idea as one of the benefits I saw was that log4net was
> > > similar to log4j2 and we're looking for logging frameworks for our
> > > enterprise.  We have applications on both Windows/.NET and Linux/Java
> so
> > > having a logging framework for Windows/.NET which is similar to a
> logging
> > > framework for Linux/Java was a big plus.
> > >
> > >
> > > While I have no doubt the effort to port log4j2 to .NET is
> considerable,
> > > it would be a port and thus I'm not spending time figuring out design
> and
> > > algorithms.  Would anyone want to venture a guess at what that effort
> > might
> > > be?
> > >
> > >
> > > Thanks,
> > >
> > > Nick
> > >
> >
> >
> >
> > --
> > [image: MagineTV]
> >
> > *Mikael Ståldal*
> > Senior software developer
> >
> > *Magine TV*
> > mikael.stal...@magine.com
> > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
> > www.magine.com<<http://www.magine.com<>
> > http://www.magine.com>
> > [https://de.magine.com/content/uploads/2016/09/magine_global_social.png
> ]<
> > http://www.magine.com/>
> >
> > TV online with Magine TV<http://www.magine.com/>
> > www.magine.com<http://www.magine.com>
> > Wat

Re: porting log4j2 to .NET

[Nicholas Duane]

I agree.  I'm also one for not coding to the lowest common denominator.  That's 
one reason we're not using a logging facade as I assume with a facade you get 
only the features that are common across the set of logging frameworks the 
facade supports.


What I'm suggesting is to come up with a design and architecture which is 
language/runtime/OS agnostic.  While it's easy for me to say that I wouldn't be 
surprised if it's more difficult to achieve.  When it comes to implementation I 
would assume the features might manifest themselves in different ways across 
the different languages/runtimes/OS's.  For instance, .NET has extension 
methods and Java doesn't.  You might decide to implement some features in .NET 
using extension methods and in Java you'll have to pick a different way to 
implement.  Configuration might be another area where there are differences 
among the different runtimes and thus the implementation might be a bit 
different.  Maybe there's even a feature that one implementation has that 
others don't just because there is no way, or no easy enough way to implement.


Thanks,

Nick


From: Mikael Ståldal <mikael.stal...@magine.com>
Sent: Tuesday, October 18, 2016 10:04 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Maybe I am nitpicking, but Log4j is also (mostly) agnostic to what language
you run on the JVM (Java, Scala, Groovy, Clojure, etc).

I guess it would be nice to have similar logging framework for other
runtimes (such as .Net). However, I would not like to constrain Log4j to
only use features available on both JVM and .Net.

On Tue, Oct 18, 2016 at 3:53 PM, Nicholas Duane <nic...@msn.com> wrote:

> I guess platform is vague.  Maybe I should have said language agnostic.
> It would be nice to have a single logging architecture/design run on C/C++,
> .NET, Java, etc.  Or at least it seems like a nice feature to me.  I would
> assume there are many enterprises out there that have applications running
> on different OS's and languages.  If I'm trying to pick a logging framework
> to use and I find a popular one which is capable and runs similarly across
> the OS's and languages then that's a big plus in my mind.
>
>
> Thanks,
>
> Nick
>
> 
> From: Mikael Ståldal <mikael.stal...@magine.com>
> Sent: Tuesday, October 18, 2016 2:52 AM
> To: Log4J Users List
> Subject: Re: porting log4j2 to .NET
>
> Just to make things clear, Log4j is a logging framework for the JVM
> platform, and it is agnostic to the underlying OS. It it well tested on (at
> least) both Linux and Windows.
>
> On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane <nic...@msn.com> wrote:
>
> > Figured I would send this question out to the log4j side.  I have already
> > had some email exchanges with the log4net mailing list regarding porting
> > log4j2 to .NET.  My suggestion was that the apache logging framework be a
> > single architecture design which is platform agnostic and then teams
> which
> > port to the different platforms.  It seems log4net was a port of log4j
> and
> > may be going off in its own direction from that initial port.  My
> viewpoint
> > is that's a bad idea as one of the benefits I saw was that log4net was
> > similar to log4j2 and we're looking for logging frameworks for our
> > enterprise.  We have applications on both Windows/.NET and Linux/Java so
> > having a logging framework for Windows/.NET which is similar to a logging
> > framework for Linux/Java was a big plus.
> >
> >
> > While I have no doubt the effort to port log4j2 to .NET is considerable,
> > it would be a port and thus I'm not spending time figuring out design and
> > algorithms.  Would anyone want to venture a guess at what that effort
> might
> > be?
> >
> >
> > Thanks,
> >
> > Nick
> >
>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.stal...@magine.com
> Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
> www.magine.com<<http://www.magine.com<>
> http://www.magine.com>
> [https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<
> http://www.magine.com/>
>
> TV online with Magine TV<http://www.magine.com/>
> www.magine.com<http://www.magine.com>
> Watch the TV you love, on any device, anywhere in Germany and Sweden and
> find out more about our global OTT B2B solutions. Get started today.
>
>
>
> Privileged and/or Confidential Information may be contained in this
> message. If you are not the addressee indicated in this message
> (or responsible for delivery of the message to such a person), you may not
> copy or delive

Re: approach for defining loggers

[Nicholas Duane]

The convention is to use the class name as the logger name and we find that 
useful information.  Getting the class name, method name and line number 
dynamically I assume is costly and thus we'd probably want to just stick with 
the logger name.


We're not planning to turn off the business events by logger name, it's just a 
nice option to have in the event we have some code which is misbehaving.  We 
wouldn't have that option if we use a "well known" logger.


Thanks,

Nick


From: Ralph Goers <ralph.go...@dslextreme.com>
Sent: Tuesday, October 18, 2016 10:01 AM
To: Log4J Users List
Subject: Re: approach for defining loggers

The “context” of the call is only grossly captured by the logger name, and that 
is only by convention. If you really want the name of the class then you need 
the location information, which gives you the class name, method name and line 
number of the caller.

If these are “business” events why do you want to turn them off by the name of 
the logger? I would think you might want to filter out certain event types, but 
that shouldn’t be represented by the logger name.

Ralph

> On Oct 18, 2016, at 6:47 AM, Nicholas Duane <nic...@msn.com> wrote:
>
> That's what I initially thought.  However, as I pointed out it has the same 
> downsides as a "well known" logger.  We lose the context of what code is 
> logging the call (e.g the class name which is usually used as the logger 
> name), and there is no way to turn on/off a section of code from logging, in 
> the case we find some errant code.  Those two are big enough issues which are 
> keeping me away from using "well known" loggers.
>
>
> Thanks,
>
> Nick
>
> 
> From: Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
> Sent: Monday, October 17, 2016 11:15 PM
> To: Log4J Users List
> Subject: Re: approach for defining loggers
>
> What about event logging? <
> https://logging.apache.org/log4j/2.x/manual/eventlogging.html 
> <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> Log4j – Log4j 2 API - Apache Log4j 
> 2<https://logging.apache.org/log4j/2.x/manual/eventlogging.html 
> <https://logging.apache.org/log4j/2.x/manual/eventlogging.html>>
> logging.apache.org <http://logging.apache.org/>
> The EventLogger class provides a simple mechanism for logging events that 
> occur in an application. While the EventLogger is useful as a way of 
> initiating events that ...
>
>
>
> This sounds pretty similar to what you're asking about. You define a map
> message essentially, plus your other requirements seem to be met here.
>
> On 17 October 2016 at 21:46, Gary Gregory <garydgreg...@gmail.com> wrote:
>
>> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <nic...@msn.com> wrote:
>>
>>> Sorry to revive this old thread.  However, we're in the process of adding
>>> support for other "categories" of events and thus I wanted to first take
>> a
>>> step back and try to ensure we're not convoluting things.
>>>
>>>
>>> There was a requirement to log a "compliance" event under certain
>>> conditions.  We did not want to write our own logging framework and
>> instead
>>> decided to use existing off-the-shelf logging frameworks.  We have
>>> applications on both Linux/Java, Windows/.NET and Windows/Java.
>> Initially
>>> we chose log4net for Windows/.NET and log4j2 for Windows/Java and
>>> Linux/Java.  For these logging frameworks we wrote artifacts, appenders
>>> basically, to help facilitate getting these events to our system.  By the
>>> way, our system will get the events centrally, possibly put them into a
>>> relational database and also hand them off to another system which will
>> get
>>> them eventually to an HDFS backend.  We also exposed methods for creating
>>> this compliance event.  The compliance event is basically a map.  We
>> chose
>>> a map so that the event could also be extended by the application team in
>>> case they needed to add additional properties which made sense for them.
>>>
>>>
>>> We chose to create a custom level for this "compliance" event such that
>> we
>>> could filter out only these events and get them into our system.  The
>>> configuration example we created had our custom unix domain socket
>> appender
>>> added to the root logger.  It also contained a filter which filtered out
>>> any events that weren't compliance events.  The level we chose for
>>> "compliance" was less critical than off and more

Re: porting log4j2 to .NET

[Nicholas Duane]

I guess platform is vague.  Maybe I should have said language agnostic.  It 
would be nice to have a single logging architecture/design run on C/C++, .NET, 
Java, etc.  Or at least it seems like a nice feature to me.  I would assume 
there are many enterprises out there that have applications running on 
different OS's and languages.  If I'm trying to pick a logging framework to use 
and I find a popular one which is capable and runs similarly across the OS's 
and languages then that's a big plus in my mind.


Thanks,

Nick


From: Mikael Ståldal <mikael.stal...@magine.com>
Sent: Tuesday, October 18, 2016 2:52 AM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Just to make things clear, Log4j is a logging framework for the JVM
platform, and it is agnostic to the underlying OS. It it well tested on (at
least) both Linux and Windows.

On Tue, Oct 18, 2016 at 2:33 AM, Nicholas Duane <nic...@msn.com> wrote:

> Figured I would send this question out to the log4j side.  I have already
> had some email exchanges with the log4net mailing list regarding porting
> log4j2 to .NET.  My suggestion was that the apache logging framework be a
> single architecture design which is platform agnostic and then teams which
> port to the different platforms.  It seems log4net was a port of log4j and
> may be going off in its own direction from that initial port.  My viewpoint
> is that's a bad idea as one of the benefits I saw was that log4net was
> similar to log4j2 and we're looking for logging frameworks for our
> enterprise.  We have applications on both Windows/.NET and Linux/Java so
> having a logging framework for Windows/.NET which is similar to a logging
> framework for Linux/Java was a big plus.
>
>
> While I have no doubt the effort to port log4j2 to .NET is considerable,
> it would be a port and thus I'm not spending time figuring out design and
> algorithms.  Would anyone want to venture a guess at what that effort might
> be?
>
>
> Thanks,
>
> Nick
>



--
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   
www.magine.com<http://www.magine.com>
[https://de.magine.com/content/uploads/2016/09/magine_global_social.png]<http://www.magine.com/>

TV online with Magine TV<http://www.magine.com/>
www.magine.com
Watch the TV you love, on any device, anywhere in Germany and Sweden and find 
out more about our global OTT B2B solutions. Get started today.



Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Re: approach for defining loggers

[Nicholas Duane]

That's what I initially thought.  However, as I pointed out it has the same 
downsides as a "well known" logger.  We lose the context of what code is 
logging the call (e.g the class name which is usually used as the logger name), 
and there is no way to turn on/off a section of code from logging, in the case 
we find some errant code.  Those two are big enough issues which are keeping me 
away from using "well known" loggers.


Thanks,

Nick


From: Matt Sicker <boa...@gmail.com>
Sent: Monday, October 17, 2016 11:15 PM
To: Log4J Users List
Subject: Re: approach for defining loggers

What about event logging? <
https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
Log4j – Log4j 2 API - Apache Log4j 
2<https://logging.apache.org/log4j/2.x/manual/eventlogging.html>
logging.apache.org
The EventLogger class provides a simple mechanism for logging events that occur 
in an application. While the EventLogger is useful as a way of initiating 
events that ...



This sounds pretty similar to what you're asking about. You define a map
message essentially, plus your other requirements seem to be met here.

On 17 October 2016 at 21:46, Gary Gregory <garydgreg...@gmail.com> wrote:

> On Mon, Oct 17, 2016 at 4:27 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> > Sorry to revive this old thread.  However, we're in the process of adding
> > support for other "categories" of events and thus I wanted to first take
> a
> > step back and try to ensure we're not convoluting things.
> >
> >
> > There was a requirement to log a "compliance" event under certain
> > conditions.  We did not want to write our own logging framework and
> instead
> > decided to use existing off-the-shelf logging frameworks.  We have
> > applications on both Linux/Java, Windows/.NET and Windows/Java.
> Initially
> > we chose log4net for Windows/.NET and log4j2 for Windows/Java and
> > Linux/Java.  For these logging frameworks we wrote artifacts, appenders
> > basically, to help facilitate getting these events to our system.  By the
> > way, our system will get the events centrally, possibly put them into a
> > relational database and also hand them off to another system which will
> get
> > them eventually to an HDFS backend.  We also exposed methods for creating
> > this compliance event.  The compliance event is basically a map.  We
> chose
> > a map so that the event could also be extended by the application team in
> > case they needed to add additional properties which made sense for them.
> >
> >
> > We chose to create a custom level for this "compliance" event such that
> we
> > could filter out only these events and get them into our system.  The
> > configuration example we created had our custom unix domain socket
> appender
> > added to the root logger.  It also contained a filter which filtered out
> > any events that weren't compliance events.  The level we chose for
> > "compliance" was less critical than off and more critical than fatal as
> we
> > wanted to ensure that as long as logging wasn't turned off altogether our
> > events would get logged.
> >
> >
> > I want to go over a few suggestions that were made and explain why I
> > didn't make use of those suggestions.
> >
> >
> > 1. Since our "compliance" level didn't fit within the "vernacular" of the
> > existing levels we should not define this custom level.  Instead we
> should
> > look at using markers.
> >
>
> Yes, this is a use case for markers. The level should be used to note how
> important is each compliance event.
>
>
> >
> > I am not that familiar with markers but did look into them when they were
> > suggested.  While I don't have anything against markers in general there
> > were some downsides as I saw it.
> >
> >
> > a. Markers are not available, as far as I know, in log4net so we'd still
> > have to figure out something there.
> >
>
> Indeed, we really need a port of Log4j 2 to .NET.
>
>
> >
> > b. A bigger problem, at least I thought it was a bigger problem, was that
> > there would be confusion about what level to log the event at.  I would
> > certainly not want to give an example as follows:
> >
> >
> > logger.debug(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.info(COMPLIANCE_MARKER, evnt);
> >
> >
> > or
> >
> >
> > logger.error(COMPLIANCE_MARKER, evnt);
> >
> >
> > ...
> >
>
> Think about: How important is this event? Are

Re: porting log4j2 to .NET

[Nicholas Duane]

Thanks for the guess.  I assume there is enough "separate" big enough pieces 
that a small group of people could work on different sections without stepping 
on each others toes such that you'd get some linear scaling.  For instance, it 
might take 3 people 2 months?  Even if we double your estimate, 3 people taking 
4 months?  Doesn't sound too bad.


Thanks,

Nick


From: Gary Gregory <garydgreg...@gmail.com>
Sent: Monday, October 17, 2016 8:54 PM
To: Log4J Users List
Subject: Re: porting log4j2 to .NET

Random guesstimate for a complete port, including tests (what about docs):
6 man-months. You can shorten things up by reducing appenders and
configuration formats.

Gary

On Mon, Oct 17, 2016 at 5:33 PM, Nicholas Duane <nic...@msn.com> wrote:

> Figured I would send this question out to the log4j side.  I have already
> had some email exchanges with the log4net mailing list regarding porting
> log4j2 to .NET.  My suggestion was that the apache logging framework be a
> single architecture design which is platform agnostic and then teams which
> port to the different platforms.  It seems log4net was a port of log4j and
> may be going off in its own direction from that initial port.  My viewpoint
> is that's a bad idea as one of the benefits I saw was that log4net was
> similar to log4j2 and we're looking for logging frameworks for our
> enterprise.  We have applications on both Windows/.NET and Linux/Java so
> having a logging framework for Windows/.NET which is similar to a logging
> framework for Linux/Java was a big plus.
>
>
> While I have no doubt the effort to port log4j2 to .NET is considerable,
> it would be a port and thus I'm not spending time figuring out design and
> algorithms.  Would anyone want to venture a guess at what that effort might
> be?
>
>
> Thanks,
>
> Nick
>



--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8=1789=9325=1617290459=as2=garygregory-20=cadb800f39946ec62ea2b1af9fe6a2b8>

<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
JUnit in Action, Second Edition: Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory: 9781935182023: Amazon.com: 
Books<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8=1789=9325=1935182021=as2=garygregory-20=31ecd1f6b6d1eaf8886ac902a24de418%22>
www.amazon.com
JUnit in Action, Second Edition [Petar Tahchiev, Felipe Leme, Vincent Massol, 
Gary Gregory] on Amazon.com. *FREE* shipping on qualifying offers.
When JUnit was first introduced a decade ago by Kent Beck and Erich Gamma, the 
Agile movement was in its infancy



<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
Spring Batch in Action: Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud: 9781935182955: Amazon.com: 
Books<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8=1789=9325=1935182951=%7B%7BlinkCode%7D%7D=garygregory-20=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
www.amazon.com
Spring Batch in Action [Arnaud Cogoluegnes, Thierry Templier, Gary Gregory, 
Olivier Bazoud] on Amazon.com. *FREE* shipping on qualifying offers.
Summary Spring Batch in Action is an in-depth guide to writing batch 
applications using Spring Batch. Written for developers who have basic 
knowledge of Java and the Spring lightweight container


<http:ir-na.amazon-adsystem.com/e/ir?t=garygregory-20=am2=1=1935182951>
Blog: http://garygregory.wordpress.com
[https://s0.wp.com/i/blank.jpg]<http://garygregory.wordpress.com/>

Gary Gregory<http://garygregory.wordpress.com/>
garygregory.wordpress.com
Software construction, the web, and other techs


Home: http://garygregory.com/
Gary Gregory<http://garygregory.com/>
garygregory.com
Rocket | Seagull . I am a Software Architect for Seagull Software, a division 
of Rocket Software. Rocket Seagull specializes in tools and expertise to 
modernize ...


Tweet! http://twitter.com/GaryGregory

porting log4j2 to .NET

[Nicholas Duane]

Figured I would send this question out to the log4j side.  I have already had 
some email exchanges with the log4net mailing list regarding porting log4j2 to 
.NET.  My suggestion was that the apache logging framework be a single 
architecture design which is platform agnostic and then teams which port to the 
different platforms.  It seems log4net was a port of log4j and may be going off 
in its own direction from that initial port.  My viewpoint is that's a bad idea 
as one of the benefits I saw was that log4net was similar to log4j2 and we're 
looking for logging frameworks for our enterprise.  We have applications on 
both Windows/.NET and Linux/Java so having a logging framework for Windows/.NET 
which is similar to a logging framework for Linux/Java was a big plus.


While I have no doubt the effort to port log4j2 to .NET is considerable, it 
would be a port and thus I'm not spending time figuring out design and 
algorithms.  Would anyone want to venture a guess at what that effort might be?


Thanks,

Nick

RE: controlling the status logger output?

[Nicholas Duane]

Just realized that maybe you meant we write our own application and handle the 
rollover in that app when you stated "That said, if you are concerned you can 
redirect stdout and implement the rolling yourself.".

Thanks,
Nick

From: nic...@msn.com
To: log4j-user@logging.apache.org
Subject: RE: controlling the status logger output?
Date: Mon, 7 Mar 2016 11:19:59 -0500




I was asking about what's getting logged as I figured we shouldn't have that 
much in there to be too worried about disk space consumption.  The appender in 
question is an https appender we wrote.  If it encounters an exception is calls 
LOGGER.error().  We should have some throttling around that such that we don't 
generate 1-for-1 errors for each exception we encounter since a problem with 
the https endpoint could flood the system, but we don't have that throttling 
yet.  We're redirecting stdout now which is why we're running into some disk 
consumption issue.  Is there a safe way to implement rolling the file without 
the generating app knowing about it?  Wouldn't I potentially be deleting the 
file contents out from under it?

I have a related question, does log4j2 have some throttling of its own?  If I 
removed the LOGGER.error() and just let the exception bubble up to log4j2, 
would it throttle those errors?  I think I was investigating this earlier and 
noticed some throttling but can't be sure.

..

I guess we could write our own application which takes stdin and writes to 
files and this could do the rolling file work.  I would think something like 
that might already exist in linux.

Thanks,
Nick

> Subject: Re: controlling the status logger output?
> From: ralph.go...@dslextreme.com
> Date: Mon, 7 Mar 2016 08:54:05 -0700
> To: log4j-user@logging.apache.org
> 
> If you set the status level to ERROR the StatusLogger should generate very 
> little output. That said, if you are concerned you can redirect stdout and 
> implement the rolling yourself.
> 
> Ralph
> 
> > On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We've written some appenders and I think the prescribed approach is to use 
> > the status logger in log4j2 components, is that correct?  The problem we're 
> > running into is that we redirect stdout to a file and thus that file can 
> > grow unbounded.  It seems there's no way to have something like a rolling 
> > file appender for the status logger, correct?  Any suggestions for limiting 
> > the size of the log generated by the status logger when stdout has been 
> > redirected to a file?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 

  

RE: controlling the status logger output?

[Nicholas Duane]

I was asking about what's getting logged as I figured we shouldn't have that 
much in there to be too worried about disk space consumption.  The appender in 
question is an https appender we wrote.  If it encounters an exception is calls 
LOGGER.error().  We should have some throttling around that such that we don't 
generate 1-for-1 errors for each exception we encounter since a problem with 
the https endpoint could flood the system, but we don't have that throttling 
yet.  We're redirecting stdout now which is why we're running into some disk 
consumption issue.  Is there a safe way to implement rolling the file without 
the generating app knowing about it?  Wouldn't I potentially be deleting the 
file contents out from under it?

I have a related question, does log4j2 have some throttling of its own?  If I 
removed the LOGGER.error() and just let the exception bubble up to log4j2, 
would it throttle those errors?  I think I was investigating this earlier and 
noticed some throttling but can't be sure.

..

I guess we could write our own application which takes stdin and writes to 
files and this could do the rolling file work.  I would think something like 
that might already exist in linux.

Thanks,
Nick

> Subject: Re: controlling the status logger output?
> From: ralph.go...@dslextreme.com
> Date: Mon, 7 Mar 2016 08:54:05 -0700
> To: log4j-user@logging.apache.org
> 
> If you set the status level to ERROR the StatusLogger should generate very 
> little output. That said, if you are concerned you can redirect stdout and 
> implement the rolling yourself.
> 
> Ralph
> 
> > On Mar 7, 2016, at 8:39 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We've written some appenders and I think the prescribed approach is to use 
> > the status logger in log4j2 components, is that correct?  The problem we're 
> > running into is that we redirect stdout to a file and thus that file can 
> > grow unbounded.  It seems there's no way to have something like a rolling 
> > file appender for the status logger, correct?  Any suggestions for limiting 
> > the size of the log generated by the status logger when stdout has been 
> > redirected to a file?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

controlling the status logger output?

[Nicholas Duane]

We've written some appenders and I think the prescribed approach is to use the 
status logger in log4j2 components, is that correct?  The problem we're running 
into is that we redirect stdout to a file and thus that file can grow 
unbounded.  It seems there's no way to have something like a rolling file 
appender for the status logger, correct?  Any suggestions for limiting the size 
of the log generated by the status logger when stdout has been redirected to a 
file?

Thanks,
Nick
  

RE: Appender's append() method

[Nicholas Duane]

I'm getting a little confused here.  I also left out some information.  We do 
need to catch because for some of our appenders we log the errors to loggers 
which will capture the errors in a central location.

If we didn't include any exception handling that would mean any type of 
exception could be thrown back to the AppenderControl.  So if I do catch 
exceptions so that I can log them and then I want to rethrow them, is there a 
reason why I have to wrap them in some specific type of exception?

Also, as I mentioned earlier, and unfortunately I didn't get a chance to test 
this yet but I believe I've seen this happen before, if I'm attempting to 
override a method which doesn't indicate it throws exceptions, won't the 
compiler complain if I attempt to throw an exception from that method?

Thanks,
Nick

> Subject: Re: Appender's append() method
> From: ralph.go...@dslextreme.com
> Date: Wed, 13 Jan 2016 22:50:41 -0700
> To: log4j-user@logging.apache.org
> 
> Why are you catching it at all? AppenderControl also takes care of handling 
> logging the exception so you don’t even have to catch the exception to do 
> that.
> 
> Ralph
> 
> > On Jan 13, 2016, at 7:49 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > Also, why would we not just rethrow whatever exception we caught?
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: Appender's append() method
> >> From: ralph.go...@dslextreme.com
> >> Date: Wed, 13 Jan 2016 17:28:11 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> Sorry, that was what I meant.
> >> 
> >> Ralph
> >> 
> >>> On Jan 13, 2016, at 3:17 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> >>> 
> >>> IMO a RuntimeException subclass is appropriate while RuntimeException
> >>> should not be used.
> >>> 
> >>> Gary
> >>> 
> >>> On Wed, Jan 13, 2016 at 1:53 PM, Ralph Goers <ralph.go...@dslextreme.com>
> >>> wrote:
> >>> 
> >>>> Your appender is automatically wrapped by an AppenderControl object. The
> >>>> AppenderControl will inspect the ignoreExceptions flag so your Appender
> >>>> does not have to.  Your Appender should just throw a RuntimeException if 
> >>>> it
> >>>> encounters a problem.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>>> On Jan 13, 2016, at 2:38 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>> 
> >>>>> I'm new to java so maybe this should be an obvious question to most java
> >>>> developers.  If I'm trying to override the append() method but also throw
> >>>> exceptions, how is that done?
> >>>>> 
> >>>>> I'm asking because I assume my append method's outermost catch block is
> >>>> to inspect the ignoreExceptions flag and either bubble up the exception 
> >>>> if
> >>>> ignoreExceptions is false or eat the exception otherwise, most likely 
> >>>> just
> >>>> logging an event.  Is that true?  If so, then how do I accomplish that?  
> >>>> I
> >>>> tried coding it as I mentioned above (actually someone else did it for 
> >>>> me),
> >>>> but the compiler I guess was complaining about the throw needing to be 
> >>>> in a
> >>>> catch block, I assume because the append() method is not defined to throw
> >>>> exceptions.
> >>>>> 
> >>>>> In addition, looking at what I think was source for one of your
> >>>> appenders at:
> >>>>> 
> >>>>> 
> >>>> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/appender/AbstractOutputStreamAppender.java;h=9a4cfde83194c866c30c4687e9f4ebb19cb20a17;hb=75d33d96ac00356014cf11f8ad9e8c6ead4db37a
> >>>>> 
> >>>>> Why does it always throw an exception in the catch block instead of
> >>>> checking the state of the ignoreExceptions flag?
> >>>>> 
> >>>>> Thanks,
> >>>>> Nick
> >>>>> 
> >>>> 
> >>>> 
> >>>> 
> >>>> -
> >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> -- 
> >>> 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
> >> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >> 
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: Appender's append() method

[Nicholas Duane]

Thanks for the info.  What about the compiler problem which appears to be due 
to the fact that the append() method is not marked as throwing exceptions?

Thanks,
Nick

> Date: Wed, 13 Jan 2016 14:17:47 -0800
> Subject: Re: Appender's append() method
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> IMO a RuntimeException subclass is appropriate while RuntimeException
> should not be used.
> 
> Gary
> 
> On Wed, Jan 13, 2016 at 1:53 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
> > Your appender is automatically wrapped by an AppenderControl object. The
> > AppenderControl will inspect the ignoreExceptions flag so your Appender
> > does not have to.  Your Appender should just throw a RuntimeException if it
> > encounters a problem.
> >
> > Ralph
> >
> > > On Jan 13, 2016, at 2:38 PM, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > > I'm new to java so maybe this should be an obvious question to most java
> > developers.  If I'm trying to override the append() method but also throw
> > exceptions, how is that done?
> > >
> > > I'm asking because I assume my append method's outermost catch block is
> > to inspect the ignoreExceptions flag and either bubble up the exception if
> > ignoreExceptions is false or eat the exception otherwise, most likely just
> > logging an event.  Is that true?  If so, then how do I accomplish that?  I
> > tried coding it as I mentioned above (actually someone else did it for me),
> > but the compiler I guess was complaining about the throw needing to be in a
> > catch block, I assume because the append() method is not defined to throw
> > exceptions.
> > >
> > > In addition, looking at what I think was source for one of your
> > appenders at:
> > >
> > >
> > https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/appender/AbstractOutputStreamAppender.java;h=9a4cfde83194c866c30c4687e9f4ebb19cb20a17;hb=75d33d96ac00356014cf11f8ad9e8c6ead4db37a
> > >
> > > Why does it always throw an exception in the catch block instead of
> > checking the state of the ignoreExceptions flag?
> > >
> > > Thanks,
> > > Nick
> > >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> > For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >
> >
> 
> 
> -- 
> 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: Appender's append() method

[Nicholas Duane]

Also, why would we not just rethrow whatever exception we caught?

Thanks,
Nick

> Subject: Re: Appender's append() method
> From: ralph.go...@dslextreme.com
> Date: Wed, 13 Jan 2016 17:28:11 -0700
> To: log4j-user@logging.apache.org
> 
> Sorry, that was what I meant.
> 
> Ralph
> 
> > On Jan 13, 2016, at 3:17 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> > 
> > IMO a RuntimeException subclass is appropriate while RuntimeException
> > should not be used.
> > 
> > Gary
> > 
> > On Wed, Jan 13, 2016 at 1:53 PM, Ralph Goers <ralph.go...@dslextreme.com>
> > wrote:
> > 
> >> Your appender is automatically wrapped by an AppenderControl object. The
> >> AppenderControl will inspect the ignoreExceptions flag so your Appender
> >> does not have to.  Your Appender should just throw a RuntimeException if it
> >> encounters a problem.
> >> 
> >> Ralph
> >> 
> >>> On Jan 13, 2016, at 2:38 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> I'm new to java so maybe this should be an obvious question to most java
> >> developers.  If I'm trying to override the append() method but also throw
> >> exceptions, how is that done?
> >>> 
> >>> I'm asking because I assume my append method's outermost catch block is
> >> to inspect the ignoreExceptions flag and either bubble up the exception if
> >> ignoreExceptions is false or eat the exception otherwise, most likely just
> >> logging an event.  Is that true?  If so, then how do I accomplish that?  I
> >> tried coding it as I mentioned above (actually someone else did it for me),
> >> but the compiler I guess was complaining about the throw needing to be in a
> >> catch block, I assume because the append() method is not defined to throw
> >> exceptions.
> >>> 
> >>> In addition, looking at what I think was source for one of your
> >> appenders at:
> >>> 
> >>> 
> >> https://git-wip-us.apache.org/repos/asf?p=logging-log4j2.git;a=blob;f=log4j-core/src/main/java/org/apache/logging/log4j/core/appender/AbstractOutputStreamAppender.java;h=9a4cfde83194c866c30c4687e9f4ebb19cb20a17;hb=75d33d96ac00356014cf11f8ad9e8c6ead4db37a
> >>> 
> >>> Why does it always throw an exception in the catch block instead of
> >> checking the state of the ignoreExceptions flag?
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >> 
> >> 
> > 
> > 
> > -- 
> > 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
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: status appender?

[Nicholas Duane]

Good question.  We currently have an instrumentation framework, in .NET, which 
we use to log events and capture centrally.  This was developed back in 2001 
and has served us well.  When we discussed capturing these new events we 
decided that it would be best to use a leading logging framework if possible 
instead of develop our own.  While these business events are the ones in scope 
now, eventually we plan to capture all the application events.  The pieces I 
mentioned below, the log4j2 appenders and the domain socket daemon, is just the 
conduit we've developed to simplify application getting their events to our 
API.  Our API will consist of several "protocol" endpoints, like HTTP, FTP, MQ, 
etc.  These endpoints will accept events and then funnel them to an HDFS data 
lake.

Thanks,
Nick

> From: remko.po...@gmail.com
> Subject: Re: status appender?
> Date: Tue, 15 Dec 2015 06:20:24 +0900
> To: log4j-user@logging.apache.org
> 
> Nick,
> 
> Are you sure you want to use a logging framework for this? When I hear terms 
> like "business event" and "domain socket appender" that makes me think you 
> may want to look at some message oriented middleware solution, like JMS or 
> the like. 
> 
> Remko 
> 
> Sent from my iPhone
> 
> > On 2015/12/15, at 3:27, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > I'll give a brief description on the setup so that hopefully you have a 
> > better picture.
> > 
> > We want to capture a specific type of event, let's say a business event, 
> > from all the applications on the box and get them to a central location.  
> > We're also looking ahead to a possible PaaS environment and thinking that 
> > writing to log files might not be an option.  Our solution is that all the 
> > applications on the box will use our domain socket appender to write these 
> > business events into.  In addition, there will be a daemon on this box 
> > listening on the domain socket.  It will buffer, compress and send the 
> > events to a central location.  Even if we don't want to take into 
> > consideration the PaaS environment and thus can consider writing to local 
> > files (as I guess that's the most common logging solution and has its 
> > benefits), there might be issues there.  For instance, let's say we have a 
> > process which picks up log files and sends them centrally.  What happens 
> > when new applications are installed on the box?  We would probably have to 
> > update the configuration of this "log file consolidator" to watch new 
> > folder locations.  That might be a bit of a maintenance nightmare.
> > 
> > If the domain socket appender runs into issues, like it can't open the 
> > socket, we need for someone to look into it.  I guess the thinking is that 
> > if we get these ERROR/INFO events to a central location we can have some 
> > monitoring there to address these issues.
> > 
> > We also, currently, are failing over the event sent to the domain socket 
> > appender to the domain socket appender's logger, which I guess is what 
> > you're referring to by "Routing events being processed by an Appender 
> > through a Logger is a bad idea.".  While that is happening now, that's not 
> > the main question I have here.  It's about how to send INFO - ERROR to one 
> > location, or possibly two, and have DEBUG only go to the status logger.
> > 
> > There is push back on "failing over" the events from the domain socket 
> > appender so that code might get pulled out.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: status appender?
> >> From: ralph.go...@dslextreme.com
> >> Date: Mon, 14 Dec 2015 10:56:11 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> I don’t think I understand - “we’re writing to our own logger within our 
> >> DomainSocketAppender”.  The status logger in your appender should only be 
> >> logging errors or other events that occur within that Appender, which 
> >> normally would be nothing. Routing events being processed by an Appender 
> >> through a Logger is a bad idea.
> >> 
> >> Ralph
> >> 
> >> 
> >> 
> >>> On Dec 14, 2015, at 10:17 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> Thanks.  Yes, that's the one option I was thinking of.  Adding a console 
> >>> or file appender to our logger.  However, the actual class in question is 
> >>> our DomainSocketAppender.  This is somewhat related to a previous 
> >>> question I asked about capturing events from our appenders cent

RE: status appender?

[Nicholas Duane]

Thanks.  Yes, that's the one option I was thinking of.  Adding a console or 
file appender to our logger.  However, the actual class in question is our 
DomainSocketAppender.  This is somewhat related to a previous question I asked 
about capturing events from our appenders centrally.  I guess in general, the 
advice is to log to the status logger in your log4j2 classes.  We want to 
capture INFO - ERROR messages centrally so we're writing to our own logger 
within our DomainSocketAppender.  It would be nice to have all other events, 
DEBUG and less specific (or maybe just all events), go to the status logger and 
let the application team decide what they want to do with status logger events.

I was just thinking that one other solution would be to log all events within 
our DomainSocketsAppender to both its private logger and the status logger, 
thus somewhat removing the "routing" within the code.  Our filter on the http 
appender already filters out anything less specific than INFO.

Thanks,
Nick

> Subject: Re: status appender?
> From: ralph.go...@dslextreme.com
> Date: Mon, 14 Dec 2015 09:32:51 -0700
> To: log4j-user@logging.apache.org
> 
> First, what you are wanting to do is, in fact, pretty normal.  However, by 
> default the StatusLogger that Log4j uses for its components doesn’t use an 
> Appender. Although the API is the same the internals of the StatusLogger are 
> actually quite different than the “normal” Log4j implementation.  That said, 
> the StatusLogger normally just writes to the console.  I actually doubt that 
> that is where you want your debug events to go.  Most people prefer them to 
> go to a rolling file.
> 
> To accomplish what you want you just need to set up filtering in your 
> configuration so that the FATAL-INFO events go to one Appender and the DEBUG 
> and TRACE events go to another Appender.
> 
> Ralph
> 
> > On Dec 14, 2015, at 8:34 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > I'm curious if there is such a thing as a StatusAppender in log4j2 which, 
> > as you would guess, is the appender the StatusLogger would use?
> > 
> > Here's what I'm trying to solve, I think.
> > 
> > I've been telling other developers I work with that a piece of code should 
> > only write to a single logger.  The reason for this, in my mind, is that if 
> > a piece of code writes to more than one logger then it essentially has 
> > routing logic in it and I would rather have the routing in the 
> > configuration.  For example:
> > 
> > try
> >{
> >logger1.info(...);
> >.
> >.
> >.
> >logger2.debug(...);
> >}
> > catch(Exception e)
> >{
> >logger1.error(...);
> >}
> > 
> > The above code is sending debug events to a different logger than the rest 
> > of the events it raises.  I would rather have the code send all events to a 
> > single logger and control where those events are routed via the 
> > configuration.  Feel free to let me know whether this is in line with 
> > logging principles.
> > 
> > So here's the problem.  We've got some code which writes events to its 
> > logger.  We want to capture these events centrally so we're sending them to 
> > a central location via an HTTP appender.  We want to do this only for FATAL 
> > - INFO events, so we're not expecting a huge load.  DEBUG events however, 
> > we'd like to send to the same location as the status logger.  We can, of 
> > course, just add a console appender for DEBUG events but that would have to 
> > be controlled separately from the status logger and ideally it would be 
> > nice to just piggy back on the status logger.  We could have this code 
> > write to its private logger and the status logger for DEBUG events, but 
> > then we get into the routing issue I mentioned above.  So I'm wondering, is 
> > there such a thing as a StatusAppender?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: status appender?

[Nicholas Duane]

I'll give a brief description on the setup so that hopefully you have a better 
picture.

We want to capture a specific type of event, let's say a business event, from 
all the applications on the box and get them to a central location.  We're also 
looking ahead to a possible PaaS environment and thinking that writing to log 
files might not be an option.  Our solution is that all the applications on the 
box will use our domain socket appender to write these business events into.  
In addition, there will be a daemon on this box listening on the domain socket. 
 It will buffer, compress and send the events to a central location.  Even if 
we don't want to take into consideration the PaaS environment and thus can 
consider writing to local files (as I guess that's the most common logging 
solution and has its benefits), there might be issues there.  For instance, 
let's say we have a process which picks up log files and sends them centrally.  
What happens when new applications are installed on the box?  We would probably 
have to update the configuration of this "log file consolidator" to watch new 
folder locations.  That might be a bit of a maintenance nightmare.

If the domain socket appender runs into issues, like it can't open the socket, 
we need for someone to look into it.  I guess the thinking is that if we get 
these ERROR/INFO events to a central location we can have some monitoring there 
to address these issues.

We also, currently, are failing over the event sent to the domain socket 
appender to the domain socket appender's logger, which I guess is what you're 
referring to by "Routing events being processed by an Appender through a Logger 
is a bad idea.".  While that is happening now, that's not the main question I 
have here.  It's about how to send INFO - ERROR to one location, or possibly 
two, and have DEBUG only go to the status logger.

There is push back on "failing over" the events from the domain socket appender 
so that code might get pulled out.

Thanks,
Nick

> Subject: Re: status appender?
> From: ralph.go...@dslextreme.com
> Date: Mon, 14 Dec 2015 10:56:11 -0700
> To: log4j-user@logging.apache.org
> 
> I don’t think I understand - “we’re writing to our own logger within our 
> DomainSocketAppender”.  The status logger in your appender should only be 
> logging errors or other events that occur within that Appender, which 
> normally would be nothing. Routing events being processed by an Appender 
> through a Logger is a bad idea.
> 
> Ralph
> 
> 
> 
> > On Dec 14, 2015, at 10:17 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > Thanks.  Yes, that's the one option I was thinking of.  Adding a console or 
> > file appender to our logger.  However, the actual class in question is our 
> > DomainSocketAppender.  This is somewhat related to a previous question I 
> > asked about capturing events from our appenders centrally.  I guess in 
> > general, the advice is to log to the status logger in your log4j2 classes.  
> > We want to capture INFO - ERROR messages centrally so we're writing to our 
> > own logger within our DomainSocketAppender.  It would be nice to have all 
> > other events, DEBUG and less specific (or maybe just all events), go to the 
> > status logger and let the application team decide what they want to do with 
> > status logger events.
> > 
> > I was just thinking that one other solution would be to log all events 
> > within our DomainSocketsAppender to both its private logger and the status 
> > logger, thus somewhat removing the "routing" within the code.  Our filter 
> > on the http appender already filters out anything less specific than INFO.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: status appender?
> >> From: ralph.go...@dslextreme.com
> >> Date: Mon, 14 Dec 2015 09:32:51 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> First, what you are wanting to do is, in fact, pretty normal.  However, by 
> >> default the StatusLogger that Log4j uses for its components doesn’t use an 
> >> Appender. Although the API is the same the internals of the StatusLogger 
> >> are actually quite different than the “normal” Log4j implementation.  That 
> >> said, the StatusLogger normally just writes to the console.  I actually 
> >> doubt that that is where you want your debug events to go.  Most people 
> >> prefer them to go to a rolling file.
> >> 
> >> To accomplish what you want you just need to set up filtering in your 
> >> configuration so that the FATAL-INFO events go to one Appender and the 
> >> DEBUG and TRACE events go to another Appender.
> >> 
> >> Ralph
> >

RE: StatusLogger

[Nicholas Duane]

I'm not necessarily after the string.  I'm trying to get the original object 
that was passed to one of the logging methods.  It could have been a string or 
some complex object.

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Mon, 30 Nov 2015 08:30:37 -0700
> To: log4j-user@logging.apache.org
> 
> Log4j2 logs Message objects. The object being logged is contained within the 
> message. You would normally call getFormattedMessage() to get the message 
> String if that is what you are after.
> 
> Ralph
> 
> > On Nov 30, 2015, at 7:10 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > Is there a way within an appender to get the original object logged?  In 
> > log4net we call LoggingEvent.MessageObject.  In log4j2 it doesn't seem as 
> > straight forward.  A LogEvent object has a getMessage() method but I assume 
> > that's some sort of wrapper around the object that was logged.  We 
> > currently have code which gets our complex object which was logged by 
> > calling getParameters() and checking those objects against the interface 
> > our object implements.  However, if a simple string was logged how do we 
> > get that?  Can we always count on the zeroth element of the parameters 
> > array to be the original object that was logged?
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: StatusLogger
> >> From: ralph.go...@dslextreme.com
> >> Date: Fri, 20 Nov 2015 12:08:38 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> OK - so it sounds like you are fine.
> >> 
> >> Ralph
> >> 
> >> 
> >>> On Nov 20, 2015, at 11:24 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> That's what we're doing.  The appender it writing to a logger and via the 
> >>> configuration we have that going to this http endpoint.  We're careful to 
> >>> ensure that the events raised by our appender don't come back to itself.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Subject: Re: StatusLogger
> >>>> From: ralph.go...@dslextreme.com
> >>>> Date: Fri, 20 Nov 2015 11:04:57 -0700
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> You can also use a normal logger in your appender for stuff that will 
> >>>> happen at runtime. You just have to be aware that if you have things 
> >>>> configured incorrectly that may result in a loop - at which point Log4j 
> >>>> will detect it and ignore those logging events.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>>> On Nov 20, 2015, at 10:55 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>> 
> >>>>> We're attempting to capture error, or info, events that our plugins 
> >>>>> raise.  For instance, we wrote a domain sockets appender.  If that 
> >>>>> domain sockets appender has trouble connecting to the domain socket 
> >>>>> we'd like to know about it.  In addition, we'd like to know about it 
> >>>>> centrally so that we don't have to monitor each of the boxes our code 
> >>>>> is running on.  We therefore have a "logging" appender which writes to 
> >>>>> an http endpoint.  The log messages our plugins emit will get forwarded 
> >>>>> to this logging appender (via the configuration) in hopes to get these 
> >>>>> issues to a central location.  Of course if the http appender has 
> >>>>> trouble communicating with the http endpoint there's not much we can 
> >>>>> report on that, though I guess we could write to the StatusLogger at 
> >>>>> that point.
> >>>>> 
> >>>>> I hope I explained it well enough so that you understand what it is 
> >>>>> we're trying to do.
> >>>>> 
> >>>>> Thanks,
> >>>>> Nick
> >>>>> 
> >>>>>> Subject: Re: StatusLogger
> >>>>>> From: ralph.go...@dslextreme.com
> >>>>>> Date: Fri, 20 Nov 2015 10:16:17 -0700
> >>>>>> To: log4j-user@logging.apache.org
> >>>>>> 
> >>>>>> What do you mean by “capture the events from our appenders”?  The 
> >>>>>> StatusLogger is primarily used during configuration or to log errors 
> >>>>>> that occur in the appender. If you are tryin

RE: StatusLogger

[Nicholas Duane]

As I mentioned, what we're trying to do is capture events from our appenders.  
However, the part I didn't mention is that we *might* want to also "failover" 
the event which was sent to our appender to another appender.  In that case we 
want to log the event our appender received to our appender's logger.  I'm 
therefore trying to find out how to get the original object logged as I assume 
I don't want to pass the logEvent to the logger.

We've noticed that when we log one of our complex objects, such as:

IEvent evnt = Event.create(...);
logger.info(evnt);

that our evnt object happens to be one of the parameters in the logEvent's 
message object.  I'm trying to see how I can "resubmit" this event to the 
appender's logger in a consistent fashion regardless of how it was originally 
logged.  So whether I do the above or:

logger.Error("this is my error message");

within the appender I want to "failover" this event to the appender's logger.  
Is that possible?

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Mon, 30 Nov 2015 13:01:23 -0700
> To: log4j-user@logging.apache.org
> 
> To elaborate a bit more, if you call Log4j to log just a String then a 
> SimpleMessage will be passed in. If you log a String with parameters then you 
> will have either a ParameterizedMessage (the default) or a 
> StringFormattedMessage, MessageFormatMessage or FormattedMessage, depending 
> on the MessageFactory specified on the Logger. It also could be an RFC5424 
> Message or a MapMessage in which case the Message will contain a Map of data 
> elements.  Users can also create their own Message types.
> 
> Ralph
> 
> > On Nov 30, 2015, at 12:46 PM, Ralph Goers <ralph.go...@dslextreme.com> 
> > wrote:
> > 
> > From Log4j’s perspective, what is logged is the Message. Each message may 
> > have a different way of encapsulating its information.
> > 
> > Ralph
> > 
> >> On Nov 30, 2015, at 8:33 AM, Nicholas Duane <nic...@msn.com> wrote:
> >> 
> >> I'm not necessarily after the string.  I'm trying to get the original 
> >> object that was passed to one of the logging methods.  It could have been 
> >> a string or some complex object.
> >> 
> >> Thanks,
> >> Nick
> >> 
> >>> Subject: Re: StatusLogger
> >>> From: ralph.go...@dslextreme.com
> >>> Date: Mon, 30 Nov 2015 08:30:37 -0700
> >>> To: log4j-user@logging.apache.org
> >>> 
> >>> Log4j2 logs Message objects. The object being logged is contained within 
> >>> the message. You would normally call getFormattedMessage() to get the 
> >>> message String if that is what you are after.
> >>> 
> >>> Ralph
> >>> 
> >>>> On Nov 30, 2015, at 7:10 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>>> 
> >>>> Is there a way within an appender to get the original object logged?  In 
> >>>> log4net we call LoggingEvent.MessageObject.  In log4j2 it doesn't seem 
> >>>> as straight forward.  A LogEvent object has a getMessage() method but I 
> >>>> assume that's some sort of wrapper around the object that was logged.  
> >>>> We currently have code which gets our complex object which was logged by 
> >>>> calling getParameters() and checking those objects against the interface 
> >>>> our object implements.  However, if a simple string was logged how do we 
> >>>> get that?  Can we always count on the zeroth element of the parameters 
> >>>> array to be the original object that was logged?
> >>>> 
> >>>> Thanks,
> >>>> Nick
> >>>> 
> >>>>> Subject: Re: StatusLogger
> >>>>> From: ralph.go...@dslextreme.com
> >>>>> Date: Fri, 20 Nov 2015 12:08:38 -0700
> >>>>> To: log4j-user@logging.apache.org
> >>>>> 
> >>>>> OK - so it sounds like you are fine.
> >>>>> 
> >>>>> Ralph
> >>>>> 
> >>>>> 
> >>>>>> On Nov 20, 2015, at 11:24 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>>> 
> >>>>>> That's what we're doing.  The appender it writing to a logger and via 
> >>>>>> the configuration we have that going to this http endpoint.  We're 
> >>>>>> careful to ensure that the events raised by our appender don't come 
> >>>>>> back to itself.
> >>>>>> 
> &

RE: StatusLogger

[Nicholas Duane]

Is there a way within an appender to get the original object logged?  In 
log4net we call LoggingEvent.MessageObject.  In log4j2 it doesn't seem as 
straight forward.  A LogEvent object has a getMessage() method but I assume 
that's some sort of wrapper around the object that was logged.  We currently 
have code which gets our complex object which was logged by calling 
getParameters() and checking those objects against the interface our object 
implements.  However, if a simple string was logged how do we get that?  Can we 
always count on the zeroth element of the parameters array to be the original 
object that was logged?

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Fri, 20 Nov 2015 12:08:38 -0700
> To: log4j-user@logging.apache.org
> 
> OK - so it sounds like you are fine.
> 
> Ralph
> 
> 
> > On Nov 20, 2015, at 11:24 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > That's what we're doing.  The appender it writing to a logger and via the 
> > configuration we have that going to this http endpoint.  We're careful to 
> > ensure that the events raised by our appender don't come back to itself.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: StatusLogger
> >> From: ralph.go...@dslextreme.com
> >> Date: Fri, 20 Nov 2015 11:04:57 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> You can also use a normal logger in your appender for stuff that will 
> >> happen at runtime. You just have to be aware that if you have things 
> >> configured incorrectly that may result in a loop - at which point Log4j 
> >> will detect it and ignore those logging events.
> >> 
> >> Ralph
> >> 
> >>> On Nov 20, 2015, at 10:55 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> We're attempting to capture error, or info, events that our plugins 
> >>> raise.  For instance, we wrote a domain sockets appender.  If that domain 
> >>> sockets appender has trouble connecting to the domain socket we'd like to 
> >>> know about it.  In addition, we'd like to know about it centrally so that 
> >>> we don't have to monitor each of the boxes our code is running on.  We 
> >>> therefore have a "logging" appender which writes to an http endpoint.  
> >>> The log messages our plugins emit will get forwarded to this logging 
> >>> appender (via the configuration) in hopes to get these issues to a 
> >>> central location.  Of course if the http appender has trouble 
> >>> communicating with the http endpoint there's not much we can report on 
> >>> that, though I guess we could write to the StatusLogger at that point.
> >>> 
> >>> I hope I explained it well enough so that you understand what it is we're 
> >>> trying to do.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Subject: Re: StatusLogger
> >>>> From: ralph.go...@dslextreme.com
> >>>> Date: Fri, 20 Nov 2015 10:16:17 -0700
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> What do you mean by “capture the events from our appenders”?  The 
> >>>> StatusLogger is primarily used during configuration or to log errors 
> >>>> that occur in the appender. If you are trying to capture the events 
> >>>> being logged that sounds a bit odd as that is the purpose of an appender.
> >>>> 
> >>>> If you want to capture all the Log4j status logger output you can 
> >>>> specify a destination on the configuration element. The output will then 
> >>>> be written to that location instead of to stdout.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>>> On Nov 20, 2015, at 8:01 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>> 
> >>>>> The code happens to be a log4j2 appender, so it sounds like you're 
> >>>>> saying we should be using the StatusLogger, correct?  The issue is that 
> >>>>> we want to capture the events from our appenders to a central location.
> >>>>> 
> >>>>> Thanks,
> >>>>> Nick
> >>>>> 
> >>>>>> Subject: Re: StatusLogger
> >>>>>> From: ralph.go...@dslextreme.com
> >>>>>> Date: Thu, 19 Nov 2015 19:01:45 -0700
> >>>>>> To: log4j-user@logging.apache.org
> >>>>>> 
> >>>>>>

RE: StatusLogger

[Nicholas Duane]

The code happens to be a log4j2 appender, so it sounds like you're saying we 
should be using the StatusLogger, correct?  The issue is that we want to 
capture the events from our appenders to a central location.

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Thu, 19 Nov 2015 19:01:45 -0700
> To: log4j-user@logging.apache.org
> 
> Yes, the StatusLogger is how Log4j logs things that happen within Log4j 
> itself. If you are writing plugins for Log4j those should also use the 
> StatusLogger as they effectively become part of Log4j. If the are regular 
> application code then they should not use the StatusLogger.
> 
> Although the StatusLogger uses the same API as the Log4j API its 
> implementation is quite different and much more limited in what can be done 
> with the output.
> 
> The StatusLogger implementation doesn’t have Appenders. Instead it has 
> StatusListeners that receive the events. The only listeners provided with 
> Log4j are the StatusConsoleListener, which writes events to stdout or a 
> PrintStream, and StatusLoggerAdmin, which makes events available over JMX.
> 
> Ralph
> 
> 
> 
> > On Nov 19, 2015, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > I'm trying to get information on the StatusLogger.  I've searched and so 
> > far the log4j docs say:
> > 
> > "Records events that occur in the logging system."
> > 
> > There are also a bunch of articles related to people having problems with 
> > the StatusLogger.  I'm just looking to find out what it is.  It appears 
> > it's somewhat of an "internal" logger that log4j (log4j2) uses to log 
> > internal events.  One reason I'm looking into this is because I see some 
> > code in one of our projects in which the class is logging to the 
> > StatusLogger.  I assume we shouldn't be doing this.
> > 
> > Is the StatusLogger used in log4j2?  In one post I read that the "status" 
> > attribute controls the level.  Can I set the appender for the StatusLogger?
> > 
> > Thanks,
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: StatusLogger

[Nicholas Duane]

We're attempting to capture error, or info, events that our plugins raise.  For 
instance, we wrote a domain sockets appender.  If that domain sockets appender 
has trouble connecting to the domain socket we'd like to know about it.  In 
addition, we'd like to know about it centrally so that we don't have to monitor 
each of the boxes our code is running on.  We therefore have a "logging" 
appender which writes to an http endpoint.  The log messages our plugins emit 
will get forwarded to this logging appender (via the configuration) in hopes to 
get these issues to a central location.  Of course if the http appender has 
trouble communicating with the http endpoint there's not much we can report on 
that, though I guess we could write to the StatusLogger at that point.

I hope I explained it well enough so that you understand what it is we're 
trying to do.

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Fri, 20 Nov 2015 10:16:17 -0700
> To: log4j-user@logging.apache.org
> 
> What do you mean by “capture the events from our appenders”?  The 
> StatusLogger is primarily used during configuration or to log errors that 
> occur in the appender. If you are trying to capture the events being logged 
> that sounds a bit odd as that is the purpose of an appender.
> 
> If you want to capture all the Log4j status logger output you can specify a 
> destination on the configuration element. The output will then be written to 
> that location instead of to stdout.
> 
> Ralph
> 
> > On Nov 20, 2015, at 8:01 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > The code happens to be a log4j2 appender, so it sounds like you're saying 
> > we should be using the StatusLogger, correct?  The issue is that we want to 
> > capture the events from our appenders to a central location.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: StatusLogger
> >> From: ralph.go...@dslextreme.com
> >> Date: Thu, 19 Nov 2015 19:01:45 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> Yes, the StatusLogger is how Log4j logs things that happen within Log4j 
> >> itself. If you are writing plugins for Log4j those should also use the 
> >> StatusLogger as they effectively become part of Log4j. If the are regular 
> >> application code then they should not use the StatusLogger.
> >> 
> >> Although the StatusLogger uses the same API as the Log4j API its 
> >> implementation is quite different and much more limited in what can be 
> >> done with the output.
> >> 
> >> The StatusLogger implementation doesn’t have Appenders. Instead it has 
> >> StatusListeners that receive the events. The only listeners provided with 
> >> Log4j are the StatusConsoleListener, which writes events to stdout or a 
> >> PrintStream, and StatusLoggerAdmin, which makes events available over JMX.
> >> 
> >> Ralph
> >> 
> >> 
> >> 
> >>> On Nov 19, 2015, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> I'm trying to get information on the StatusLogger.  I've searched and so 
> >>> far the log4j docs say:
> >>> 
> >>> "Records events that occur in the logging system."
> >>> 
> >>> There are also a bunch of articles related to people having problems with 
> >>> the StatusLogger.  I'm just looking to find out what it is.  It appears 
> >>> it's somewhat of an "internal" logger that log4j (log4j2) uses to log 
> >>> internal events.  One reason I'm looking into this is because I see some 
> >>> code in one of our projects in which the class is logging to the 
> >>> StatusLogger.  I assume we shouldn't be doing this.
> >>> 
> >>> Is the StatusLogger used in log4j2?  In one post I read that the "status" 
> >>> attribute controls the level.  Can I set the appender for the 
> >>> StatusLogger?
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> >> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> >> 
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: StatusLogger

[Nicholas Duane]

That's what we're doing.  The appender it writing to a logger and via the 
configuration we have that going to this http endpoint.  We're careful to 
ensure that the events raised by our appender don't come back to itself.

Thanks,
Nick

> Subject: Re: StatusLogger
> From: ralph.go...@dslextreme.com
> Date: Fri, 20 Nov 2015 11:04:57 -0700
> To: log4j-user@logging.apache.org
> 
> You can also use a normal logger in your appender for stuff that will happen 
> at runtime. You just have to be aware that if you have things configured 
> incorrectly that may result in a loop - at which point Log4j will detect it 
> and ignore those logging events.
> 
> Ralph
> 
> > On Nov 20, 2015, at 10:55 AM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We're attempting to capture error, or info, events that our plugins raise.  
> > For instance, we wrote a domain sockets appender.  If that domain sockets 
> > appender has trouble connecting to the domain socket we'd like to know 
> > about it.  In addition, we'd like to know about it centrally so that we 
> > don't have to monitor each of the boxes our code is running on.  We 
> > therefore have a "logging" appender which writes to an http endpoint.  The 
> > log messages our plugins emit will get forwarded to this logging appender 
> > (via the configuration) in hopes to get these issues to a central location. 
> >  Of course if the http appender has trouble communicating with the http 
> > endpoint there's not much we can report on that, though I guess we could 
> > write to the StatusLogger at that point.
> > 
> > I hope I explained it well enough so that you understand what it is we're 
> > trying to do.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: StatusLogger
> >> From: ralph.go...@dslextreme.com
> >> Date: Fri, 20 Nov 2015 10:16:17 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> What do you mean by “capture the events from our appenders”?  The 
> >> StatusLogger is primarily used during configuration or to log errors that 
> >> occur in the appender. If you are trying to capture the events being 
> >> logged that sounds a bit odd as that is the purpose of an appender.
> >> 
> >> If you want to capture all the Log4j status logger output you can specify 
> >> a destination on the configuration element. The output will then be 
> >> written to that location instead of to stdout.
> >> 
> >> Ralph
> >> 
> >>> On Nov 20, 2015, at 8:01 AM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> The code happens to be a log4j2 appender, so it sounds like you're saying 
> >>> we should be using the StatusLogger, correct?  The issue is that we want 
> >>> to capture the events from our appenders to a central location.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Subject: Re: StatusLogger
> >>>> From: ralph.go...@dslextreme.com
> >>>> Date: Thu, 19 Nov 2015 19:01:45 -0700
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> Yes, the StatusLogger is how Log4j logs things that happen within Log4j 
> >>>> itself. If you are writing plugins for Log4j those should also use the 
> >>>> StatusLogger as they effectively become part of Log4j. If the are 
> >>>> regular application code then they should not use the StatusLogger.
> >>>> 
> >>>> Although the StatusLogger uses the same API as the Log4j API its 
> >>>> implementation is quite different and much more limited in what can be 
> >>>> done with the output.
> >>>> 
> >>>> The StatusLogger implementation doesn’t have Appenders. Instead it has 
> >>>> StatusListeners that receive the events. The only listeners provided 
> >>>> with Log4j are the StatusConsoleListener, which writes events to stdout 
> >>>> or a PrintStream, and StatusLoggerAdmin, which makes events available 
> >>>> over JMX.
> >>>> 
> >>>> Ralph
> >>>> 
> >>>> 
> >>>> 
> >>>>> On Nov 19, 2015, at 6:33 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>>>> 
> >>>>> I'm trying to get information on the StatusLogger.  I've searched and 
> >>>>> so far the log4j docs say:
> >>>>> 
> >>>>> "Records events that occur in the logging system."
> >>>>&g

StatusLogger

[Nicholas Duane]

I'm trying to get information on the StatusLogger.  I've searched and so far 
the log4j docs say:

"Records events that occur in the logging system."

There are also a bunch of articles related to people having problems with the 
StatusLogger.  I'm just looking to find out what it is.  It appears it's 
somewhat of an "internal" logger that log4j (log4j2) uses to log internal 
events.  One reason I'm looking into this is because I see some code in one of 
our projects in which the class is logging to the StatusLogger.  I assume we 
shouldn't be doing this.

Is the StatusLogger used in log4j2?  In one post I read that the "status" 
attribute controls the level.  Can I set the appender for the StatusLogger?

Thanks,
Nick
  

layout optional?

[Nicholas Duane]

>From reading the log4j2/log4net docs it appears adding a layout to an appender 
>is optional.  If I don't add a layout to an appender how does the appender 
>generate the string for the event?  Does it simply call toString()/ToString() 
>on the event object?  If that's the case then if we want our event to have a 
>specific format by default then I guess we need to code that in 
>toString()/ToString(), correct?

Thanks,
Nick
  

RE: how to detect logger is unable to write to file?

[Nicholas Duane]

It doesn't ring a bell.  I'll look again more thoroughly to see if I can find 
what I think I saw.

Thanks,
Nick

> Subject: Re: how to detect logger is unable to write to file?
> From: remko.po...@gmail.com
> Date: Fri, 30 Oct 2015 09:30:46 +0900
> To: log4j-user@logging.apache.org
> 
> With Async Loggers you can set an ExceptionHandler. Is that what you mean?
> 
> Sent from my iPhone
> 
> > On 2015/10/30, at 9:07, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > I could have sworn I saw some way to provide a sink for log4j2 (or maybe it 
> > was log4net) internal events.  I just did a quick search and couldn't find 
> > anything.  Is there such a mechanism?  If so, couldn't this be a way for 
> > you to at least capture internal errors which are not bubbled up through 
> > the logging API?  You could then forward these events to the platform 
> > logging mechanism.
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: how to detect logger is unable to write to file?
> >> From: ralph.go...@dslextreme.com
> >> Date: Thu, 29 Oct 2015 14:11:46 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> That feature is only in Log4j 2.
> >> 
> >> Ralph
> >> 
> >>> On Oct 29, 2015, at 1:18 PM, degenaro <lou.degen...@gmail.com> wrote:
> >>> 
> >>> This a quota on the filesystem.  Writes are blocked when the total
> >>> permitted bytes for the user is exceeded.  It looks like log4j2 might help
> >>> if an exception is being thrown.  I see that one can specify
> >>> ignoreException="false".
> >>> 
> >>> We currently have log4j (not log4j2).  Is there the equivalent or is the
> >>> new function in 2 only?
> >>> 
> >>> Lou.
> >>> 
> >>> On Thu, Oct 29, 2015 at 4:09 PM, John St. Ledger [via Apache Logging] <
> >>> ml-node+s6191n59129...@n7.nabble.com> wrote:
> >>> 
> >>>> Lou,
> >>>> 
> >>>> I don't know if this will help, but it is a daily rolling file appender
> >>>> that keeps a maximum of 6 log files. Rollover occurs at midnight, and if
> >>>> more that 6 log files exist, then the oldest is deleted.
> >>>> 
> >>>> You still can't tell if the logger fails to write to a file, but if your
> >>>> quota is number of files, then this approach might help.
> >>>> 
> >>>> John
> >>>> 
> >>>> *John W St. Ledger*
> >>>> 
> >>>> Los Alamos National Laboratory
> >>>> 
> >>>> 
> >>>> From: Matt Sicker <[hidden email]
> >>>> <http:///user/SendEmail.jtp?type=node=59129=0>>
> >>>> Reply-To: Log4J Users List <[hidden email]
> >>>> <http:///user/SendEmail.jtp?type=node=59129=1>>
> >>>> Date: Thursday, October 29, 2015 2:32 PM
> >>>> To: Log4J Users List <[hidden email]
> >>>> <http:///user/SendEmail.jtp?type=node=59129=2>>
> >>>> Subject: Re: how to detect logger is unable to write to file?
> >>>> 
> >>>> There's the FailoverAppender <
> >>>> http://logging.apache.org/log4j/2.x/manual/appenders.html#FailoverAppender
> >>>> that gives you a way to automatically switch to a different appender when
> >>>> the primary one errs.
> >>>> 
> >>>> On 29 October 2015 at 12:21, degenaro <[hidden email]
> >>>> <http:///user/SendEmail.jtp?type=node=59129=3>> wrote:
> >>>> 
> >>>> We use log4j with rolling appenders for daemons that run 24x7.  The 
> >>>> daemons
> >>>> run as a user on linux and the log files are written to a filesystem that
> >>>> has a quota.  Normally this works great.  Once in a while (usually due to
> >>>> human error) the quota is exceeded.  This, unfortunately, prevents the
> >>>> daemons from writing their logs...worst of all silently.  There is no
> >>>> indication that anything is wrong!
> >>>> 
> >>>> So my question is: how do we configure log4j so that when logging (to 
> >>>> file)
> >>>> fails the daemon can find out and take appropriate action?
> >>>> 
> >>>> 
> >>>> 
> >>>> --
> >>>> View this message in context:
> >>>> 
> >>>> http://a

RE: how to detect logger is unable to write to file?

[Nicholas Duane]

I could have sworn I saw some way to provide a sink for log4j2 (or maybe it was 
log4net) internal events.  I just did a quick search and couldn't find 
anything.  Is there such a mechanism?  If so, couldn't this be a way for you to 
at least capture internal errors which are not bubbled up through the logging 
API?  You could then forward these events to the platform logging mechanism.

Thanks,
Nick

> Subject: Re: how to detect logger is unable to write to file?
> From: ralph.go...@dslextreme.com
> Date: Thu, 29 Oct 2015 14:11:46 -0700
> To: log4j-user@logging.apache.org
> 
> That feature is only in Log4j 2.
> 
> Ralph
> 
> > On Oct 29, 2015, at 1:18 PM, degenaro  wrote:
> > 
> > This a quota on the filesystem.  Writes are blocked when the total
> > permitted bytes for the user is exceeded.  It looks like log4j2 might help
> > if an exception is being thrown.  I see that one can specify
> > ignoreException="false".
> > 
> > We currently have log4j (not log4j2).  Is there the equivalent or is the
> > new function in 2 only?
> > 
> > Lou.
> > 
> > On Thu, Oct 29, 2015 at 4:09 PM, John St. Ledger [via Apache Logging] <
> > ml-node+s6191n59129...@n7.nabble.com> wrote:
> > 
> >> Lou,
> >> 
> >> I don't know if this will help, but it is a daily rolling file appender
> >> that keeps a maximum of 6 log files. Rollover occurs at midnight, and if
> >> more that 6 log files exist, then the oldest is deleted.
> >> 
> >> You still can't tell if the logger fails to write to a file, but if your
> >> quota is number of files, then this approach might help.
> >> 
> >> John
> >> 
> >> *John W St. Ledger*
> >> 
> >> Los Alamos National Laboratory
> >> 
> >> 
> >> From: Matt Sicker <[hidden email]
> >> >
> >> Reply-To: Log4J Users List <[hidden email]
> >> >
> >> Date: Thursday, October 29, 2015 2:32 PM
> >> To: Log4J Users List <[hidden email]
> >> >
> >> Subject: Re: how to detect logger is unable to write to file?
> >> 
> >> There's the FailoverAppender <
> >> http://logging.apache.org/log4j/2.x/manual/appenders.html#FailoverAppender
> >>> 
> >> that gives you a way to automatically switch to a different appender when
> >> the primary one errs.
> >> 
> >> On 29 October 2015 at 12:21, degenaro <[hidden email]
> >> > wrote:
> >> 
> >> We use log4j with rolling appenders for daemons that run 24x7.  The daemons
> >> run as a user on linux and the log files are written to a filesystem that
> >> has a quota.  Normally this works great.  Once in a while (usually due to
> >> human error) the quota is exceeded.  This, unfortunately, prevents the
> >> daemons from writing their logs...worst of all silently.  There is no
> >> indication that anything is wrong!
> >> 
> >> So my question is: how do we configure log4j so that when logging (to file)
> >> fails the daemon can find out and take appropriate action?
> >> 
> >> 
> >> 
> >> --
> >> View this message in context:
> >> 
> >> http://apache-logging.6191.n7.nabble.com/how-to-detect-logger-is-unable-to-write-to-file-tp59123.html
> >> Sent from the Log4j - Users mailing list archive at Nabble.com.
> >> 
> >> -
> >> To unsubscribe, e-mail: [hidden email]
> >> 
> >> For additional commands, e-mail: [hidden email]
> >> 
> >> 
> >> 
> >> 
> >> 
> >> --
> >> Matt Sicker <[hidden email]
> >> >
> >> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: [hidden email]
> >> 
> >> For additional commands, e-mail: [hidden email]
> >> 
> >> 
> >> --
> >> If you reply to this email, your message will be added to the discussion
> >> below:
> >> 
> >> http://apache-logging.6191.n7.nabble.com/how-to-detect-logger-is-unable-to-write-to-file-tp59123p59129.html
> >> To unsubscribe from how to detect logger is unable to write to file?, click
> >> here
> >> 
> >> .
> >> NAML
> >> 
> >> 
> > 
> > 
> > 
> > 
> > --
> > View this message in context: 
> > 

RE: global context properties

[Nicholas Duane]

Thanks.  I assume you're talking about checking out the source for the 
RFC5424Layout, correct?  I guess the source is easily accessible from somewhere?

I have a couple follow-up questions.

1. While using the method you suggest, could I also set system properties in 
the configuration and get access to those from the layout object somehow?

2. What you suggest below using the PluginFactory @PluginConfiguration, does 
that allow you to get the entire list of parameters without having to have a 
member property for each one?

Thanks,
Nick

> Subject: Re: global context properties
> From: ralph.go...@dslextreme.com
> Date: Sat, 19 Sep 2015 20:43:14 -0700
> To: log4j-user@logging.apache.org
> 
> Take a look at RFC5424Layout. On the @PluginFactory method you will see a 
> Configuration parameters annotated with @PluginConfiguration. If you include 
> this in your factory method parameter list Log4j will automatically pass you 
> the current Configuration object. From that you can call the getProperties 
> method to get the Map of the properties that we provided in the configuration 
> file.
> 
> Ralph
> 
> 
> > On Sep 19, 2015, at 6:32 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > We're using log4j to log business events.  Each application needs to 
> > specify some application key/token.  I don't want to add this key/token to 
> > our API which creates the event as that data is static for each application 
> > and thus should not have to appear in the API.  I'm looking for some way to 
> > define this token/key somewhere, ideally configuration, and I then need to 
> > be able to read it from a custom layout.  What would be the best way to do 
> > this?
> > 
> > I looked over the MDC and I don't think I need to store it there as this 
> > information is global/static to the application.  I think you can define 
> > system properties within the config but I'm not sure how to access those 
> > from a custom layout plugin.
> > 
> > Thanks
> > Nick
> >   
> 
> 
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

global context properties

[Nicholas Duane]

We're using log4j to log business events.  Each application needs to specify 
some application key/token.  I don't want to add this key/token to our API 
which creates the event as that data is static for each application and thus 
should not have to appear in the API.  I'm looking for some way to define this 
token/key somewhere, ideally configuration, and I then need to be able to read 
it from a custom layout.  What would be the best way to do this?

I looked over the MDC and I don't think I need to store it there as this 
information is global/static to the application.  I think you can define system 
properties within the config but I'm not sure how to access those from a custom 
layout plugin.

Thanks
Nick
  

RE: Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

I looked over the thread you included below.  I can't tell from that whether 
the suggestion was to port log4j2.  Not sure if the comment about starting 
log4net 2.0 "from scratch" is an indication of having it be a port of log4j2.

In my mind the biggest benefit would be to have the same architecture/feature 
set running on both linux and windows.  Of course it would also be great if the 
releases were synchronized.  I know a big gripe of log4net is that it's not 
getting rev'd.

I would be interested in helping if the goal is to bring log4net in sync with 
log4j2.  And by this I guess I mean port as that would seem the easiest and 
safest path to the goal.

I haven't worked on any open source project in the past.  I'm curious, how does 
this work?  Who's coordinating and making the decisions?

Thanks,
Nick

> From: bode...@apache.org
> To: log4j-user@logging.apache.org; log4net-u...@logging.apache.org
> Subject: Re: Why is log4net not more similar to log4j(2)?
> Date: Fri, 18 Sep 2015 09:25:00 +0200
> 
> On 2015-09-17, Gary Gregory wrote:
> 
> > "Patches welcome" is my motto :-)
> 
> > Gary
> 
> > On Wed, Sep 16, 2015 at 2:42 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> >> Sending to both the log4j and log4net mailing lists.
> 
> >> I'm curious why log4net is not more similar to log4j(2)?  Is it because
> >> there is less development work being done on log4net and log4j had
> >> significant changes in the 2.0 version?
> 
> > I think I read somewhere that log4net was a port of log4j 1.
> 
> This is certainly part of the reason.  log4net was started as a port of
> 1.x a long time ago.  The developers (long before I joined) added some
> deviations that look closer to what log4j 2 is doing (XML
> configuration).
> 
> Incidently Dominik started a discussion about log4net 2.0 on the dev
> list[1] and some people expressed interest.  Any hand that can offer
> some help is more than welcome, so please come over and join.
> 
> [1] thread starting with 
> http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201508.mbox/%3C03be01d0da4f%24a85aaa10%24f90ffe30%24%40apache.org%3E
> 
> Stefan
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

I'll take a look at the link.  So if I'm interested in helping, if in fact the 
goal is to port log4j2 to .net, then how do I know whether anyone who would 
make that decision is even thinking about that, if they are thinking about it 
how do I know if they've decided to move forward, and when that decision takes 
place?  Do I just put my name on a "waiting list"?

Thanks,
Nick

Subject: Re: Why is log4net not more similar to log4j(2)?
From: ralph.go...@dslextreme.com
Date: Fri, 18 Sep 2015 11:25:40 -0700
CC: log4net-u...@logging.apache.org
To: log4j-user@logging.apache.org

To answer your last question, at the ASF the project committers decide what 
they are going to do. They make decisions by discussing their ideas on the 
mailing list.  In some ways, the ASF is a “do-ocracy”. You can make all the 
recommendations you want, but ultimately it is up to whoever implements it.
Take a look at http://www.apache.org/foundation/how-it-works.html.
Ralph



On Sep 18, 2015, at 7:32 AM, Nicholas Duane <nic...@msn.com> wrote:I looked 
over the thread you included below.  I can't tell from that whether the 
suggestion was to port log4j2.  Not sure if the comment about starting log4net 
2.0 "from scratch" is an indication of having it be a port of log4j2.

In my mind the biggest benefit would be to have the same architecture/feature 
set running on both linux and windows.  Of course it would also be great if the 
releases were synchronized.  I know a big gripe of log4net is that it's not 
getting rev'd.

I would be interested in helping if the goal is to bring log4net in sync with 
log4j2.  And by this I guess I mean port as that would seem the easiest and 
safest path to the goal.

I haven't worked on any open source project in the past.  I'm curious, how does 
this work?  Who's coordinating and making the decisions?

Thanks,
Nick

From: bode...@apache.org
To: log4j-user@logging.apache.org; log4net-u...@logging.apache.org
Subject: Re: Why is log4net not more similar to log4j(2)?
Date: Fri, 18 Sep 2015 09:25:00 +0200

On 2015-09-17, Gary Gregory wrote:

"Patches welcome" is my motto :-)

Gary

On Wed, Sep 16, 2015 at 2:42 PM, Nicholas Duane <nic...@msn.com> wrote:

Sending to both the log4j and log4net mailing lists.

I'm curious why log4net is not more similar to log4j(2)?  Is it because
there is less development work being done on log4net and log4j had
significant changes in the 2.0 version?

I think I read somewhere that log4net was a port of log4j 1.

This is certainly part of the reason.  log4net was started as a port of
1.x a long time ago.  The developers (long before I joined) added some
deviations that look closer to what log4j 2 is doing (XML
configuration).

Incidently Dominik started a discussion about log4net 2.0 on the dev
list[1] and some people expressed interest.  Any hand that can offer
some help is more than welcome, so please come over and join.

[1] thread starting with 
http://mail-archives.apache.org/mod_mbox/logging-log4net-dev/201508.mbox/%3C03be01d0da4f%24a85aaa10%24f90ffe30%24%40apache.org%3E

Stefan

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

  
  

RE: markers

[Nicholas Duane]

I was hoping on getting some replies to my last message as I'm trying to figure 
out the best way to utilize the existing logging frameworks, log4j(2) and 
log4net in our case, to log our business events and ensure the business events 
flow to the correct destination.

I think the two main suggestions were to either use markers or a separate "well 
known" logger.

As I mentioned in the previous message, I was about to write a sample which 
used markers just to better understand how they work.  The first road block I 
ran into is that log4net does not support markers, as far as I can tell.  Now 
the implementation doesn't have to be the same on both windows and linux, but 
that would certainly be a plus if it was.  Also, it doesn't look like markers 
have been heavily adopted by many logging frameworks.  The one article I read 
only listed log4j2 and logback.

In addition, while markers seem like they would be better at indicating the 
type or category of event as opposed to using a level, you still have to define 
a marker for each type I guess.  I could either define a custom level or a 
custom marker.  Since markers are not available in log4net and custom levels 
are, a custom level might work out better for us.

Using a "well known" logger to log business events seems like a reasonable 
approach.  And while I don't see any major downsides with going this route, it 
seems that a piece of code which is logging using their own logger should be 
able to log a business event with that same logger.  It was stated previously 
that the level indicates the importance of the event and the logger indicates 
the types of events, or why someone might want to look at the events.  The 
example given was some market data code which used its own logger to log market 
data information.  That seems totally reasonable, however, it doesn't seem to 
fit my example.  In our case any component can emit a business event.

I then thought that maybe I could use the EventLogger, which I think someone 
might have mentioned along the way.  I was hoping to try that out also, 
assuming that allowed me to pass a marker in whatever methods it exposed.  
However, I only see a static marker property on the EventLogger class.

The other option which I'm considering is exposing a property on my event 
object which indicates the category of event.  At the moment I have a "type" 
property which, of course, indicates the event type.  However, this will be 
different for every different business event and thus I need another property 
which tells me that the event is a "business" event.  Then I was thinking I 
could write a filter which checks the message object to see if it's one of my 
events and if so use the "category" to forward to the appropriate destination.

Am I missing any other viable solutions?

Thanks,
Nick

> From: nic...@msn.com
> To: log4j-user@logging.apache.org
> Subject: markers
> Date: Tue, 15 Sep 2015 22:25:37 -0400
> 
> 
> 
> 
> I was about to starting writing a sample to see how markers work and to see 
> if they could be used for logging business events instead of using a custom 
> level.  While I might have mentioned log4net in passing, we're trying to 
> capture these business events using existing logging frameworks.  The 
> thinking is that we'd use log4net on windows and log4j(2) on linux (no 
> facade).  Ideally the design would be similar across both platforms.  That 
> being said, I'm surprised at how different log4net is from log4j(2).  It 
> appears log4net doesn't support markers.  While we don't have to have the 
> same solution for both platforms, it would be nice if the solutions were the 
> same or similar.
> 
> I also looked at the EventLogger and that class doesn't have any overloads 
> which take a marker, just a static marker property.  I guess the EventLogger 
> can be assigned only a single marker?
> 
> Thanks,
> Nick
> 
> 
> 
> 
  

Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

Sending to both the log4j and log4net mailing lists.

I'm curious why log4net is not more similar to log4j(2)?  Is it because there 
is less development work being done on log4net and log4j had significant 
changes in the 2.0 version?  Any chance log4net might become more of a "port" 
of log4j(2) and thus be more similar?

Thanks,
Nick
  

RE: markers

[Nicholas Duane]

First of all let me say that I'm not trying to keep posing the same question 
until you guys agree with me.  I'm just trying to make sure I've done my due 
diligence to root out all possible options so that I can pick the one which 
ends up working out the best for our needs.

That being said, while I agree that a "Business" level doesn't quite fit the 
existing level vernacular, as was stated before, it does seem like having a 
level might help.  If all the methods which could be used to log the event take 
a level, I'm going to need to choose one.  Choosing INFO or ERROR or FATAL, 
etc., for logging a "Business" event seems a bit odd.  And while I said we want 
to make it such that you can't turn off these events, that's probably not 
correct.  If for some reason something goes wrong and we start flooding the 
system with business events we may need to turn them off.  However, we'll still 
probably want to capture INFO, ERROR, WARN and FATAL events from a systems 
management perspective.  This is where I was thinking having level be an 
enumeration as opposed to a scale might come in handy.  I could enumerate the 
exact levels I want and where I want them to go as opposed to level being a 
gauge where everything at that level and more specific match.

Your example below is good.  I'm not sure how closely it matches with a 
"business" level as the custom levels you chose do see to fit better within the 
currently defined levels.

I was really thinking that maybe the EventLogger() with a marker might work out 
well.  The reason is that the EventLogger() has an overload which doesn't take 
a level, I guess the default level is "OFF" which means it's always logged?  
However, it appears I can't pass a marker to the EventLogger() log() method.  
That in addition to log4net not supporting markers is making this a less viable 
option.

Thanks,
Nick

> Date: Wed, 16 Sep 2015 15:24:20 -0700
> Subject: Re: markers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> At first I was going to strongly recommend against using a custom level
> called BUSINESS. Custom levels have been a problem in the past at my work
> (IMO). Markers are really a perfect fit for this use-case. That got me to
> thinking about my previous idea on this of adding more levels to Log4j.
> Please bear with me. Today we have:
> 
> OFF
> FATAL
> ERROR
> WARN
> INFO
> DEBUG
> TRACE
> ALL
> 
> What I could use today are *these* levels too:
> 
> OFF
> *EXIT*
> FATAL
> ERROR
> WARN
> *HEADLINE*
> INFO
> *VERBOSE*
> DEBUG
> TRACE
> ALL
> 
> (EXIT is called when you System.exit(), which might not be loggable
> depending on I don't know what, HEADLINE is a lame name but I can't think
> of anything better, VERBOSE is obvious IMO)
> 
> Which made me wonder if your BUSINESS level could fit in like this:
> 
> OFF
> FATAL
> ERROR
> WARN
> *BUSINESS*
> INFO
> DEBUG
> TRACE
> ALL
> 
> So maybe, just maybe, I could see that a BUSINESS level makes sense instead
> of a marker.
> 
> Gary
> 
> 
> On Wed, Sep 16, 2015 at 2:34 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > I was hoping on getting some replies to my last message as I'm trying to
> > figure out the best way to utilize the existing logging frameworks,
> > log4j(2) and log4net in our case, to log our business events and ensure the
> > business events flow to the correct destination.
> >
> > I think the two main suggestions were to either use markers or a separate
> > "well known" logger.
> >
> > As I mentioned in the previous message, I was about to write a sample
> > which used markers just to better understand how they work.  The first road
> > block I ran into is that log4net does not support markers, as far as I can
> > tell.  Now the implementation doesn't have to be the same on both windows
> > and linux, but that would certainly be a plus if it was.  Also, it doesn't
> > look like markers have been heavily adopted by many logging frameworks.
> > The one article I read only listed log4j2 and logback.
> >
> > In addition, while markers seem like they would be better at indicating
> > the type or category of event as opposed to using a level, you still have
> > to define a marker for each type I guess.  I could either define a custom
> > level or a custom marker.  Since markers are not available in log4net and
> > custom levels are, a custom level might work out better for us.
> >
> > Using a "well known" logger to log business events seems like a reasonable
> > approach.  And while I don't see any major downsides with going this route,
> > it seems that a piece of code which is logging usi

RE: Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

I was debating offering to help.  Not that I wouldn't be interested, just don't 
know how much time I could commit.  Also, not sure I would be interested in 
"patching" log4net.  In my mind the best approach would be to port log4j2.  I 
would like the two to be very similar, down to the level values, configuration 
syntax, appenders, filters and extensibility.

Thanks,
Nick

Date: Wed, 16 Sep 2015 15:25:19 -0700
Subject: Re: Why is log4net not more similar to log4j(2)?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
CC: log4net-u...@logging.apache.org

I think I read somewhere that log4net was a port of log4j 1.
"Patches welcome" is my motto :-)
Gary
On Wed, Sep 16, 2015 at 2:42 PM, Nicholas Duane <nic...@msn.com> wrote:
Sending to both the log4j and log4net mailing lists.



I'm curious why log4net is not more similar to log4j(2)?  Is it because there 
is less development work being done on log4net and log4j had significant 
changes in the 2.0 version?  Any chance log4net might become more of a "port" 
of log4j(2) and thus be more similar?



Thanks,

Nick

  

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

RE: Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

Not sure.  I was going to ask what a guess on the effort might be.  I wasn't 
expecting *huge*.  And I guess *huge* is still your guess if we only consider 
the "core" and maybe a single file appender just as a starting point?

Thanks,
Nick

Date: Wed, 16 Sep 2015 15:49:22 -0700
Subject: Re: Why is log4net not more similar to log4j(2)?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
CC: log4net-u...@logging.apache.org

Porting Log4j 2 would be a *huge* job. Would you use a translator of some kind?
Gary
On Wed, Sep 16, 2015 at 3:41 PM, Nicholas Duane <nic...@msn.com> wrote:
I was debating offering to help.  Not that I wouldn't be interested, just don't 
know how much time I could commit.  Also, not sure I would be interested in 
"patching" log4net.  In my mind the best approach would be to port log4j2.  I 
would like the two to be very similar, down to the level values, configuration 
syntax, appenders, filters and extensibility.



Thanks,

Nick



Date: Wed, 16 Sep 2015 15:25:19 -0700

Subject: Re: Why is log4net not more similar to log4j(2)?

From: garydgreg...@gmail.com

To: log4j-user@logging.apache.org

CC: log4net-u...@logging.apache.org



I think I read somewhere that log4net was a port of log4j 1.

"Patches welcome" is my motto :-)

Gary

On Wed, Sep 16, 2015 at 2:42 PM, Nicholas Duane <nic...@msn.com> wrote:

Sending to both the log4j and log4net mailing lists.







I'm curious why log4net is not more similar to log4j(2)?  Is it because there 
is less development work being done on log4net and log4j had significant 
changes in the 2.0 version?  Any chance log4net might become more of a "port" 
of log4j(2) and thus be more similar?







Thanks,



Nick







--

E-Mail: garydgreg...@gmail.com | ggreg...@apache.org

Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition

Spring Batch in Action

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
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com 
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
  

RE: Why is log4net not more similar to log4j(2)?

[Nicholas Duane]

I was thinking maybe the sheer number of appenders/filters would make it a lot 
of effort to port the entire list and just porting the core infrastructure and 
maybe one appender just so that you could see something working might 
something, while a large effort, wouldn't be huge.  But I guess you're saying 
it would be a huge effort.

Not sure if there are good java to c# translators and even if there is what 
other hurdles you might run into trying to port via a translator, e.g. platform 
specific code.

I was assuming you could do it in phases.  Maybe the code is somewhat layered 
so that the "core" could be ported without too much difficulty.

Thanks,
Nick

> Date: Wed, 16 Sep 2015 17:19:24 -0700
> Subject: Re: Why is log4net not more similar to log4j(2)?
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> CC: log4net-u...@logging.apache.org
> 
> It's not so much that one appender is more code than another. It's all the
> infrastructure underneath it all...
> 
> Gary
> 
> On Wed, Sep 16, 2015 at 5:06 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > Not sure.  I was going to ask what a guess on the effort might be.  I
> > wasn't expecting *huge*.  And I guess *huge* is still your guess if we only
> > consider the "core" and maybe a single file appender just as a starting
> > point?
> >
> > Thanks,
> > Nick
> >
> > Date: Wed, 16 Sep 2015 15:49:22 -0700
> > Subject: Re: Why is log4net not more similar to log4j(2)?
> > From: garydgreg...@gmail.com
> > To: log4j-user@logging.apache.org
> > CC: log4net-u...@logging.apache.org
> >
> > Porting Log4j 2 would be a *huge* job. Would you use a translator of some
> > kind?
> > Gary
> > On Wed, Sep 16, 2015 at 3:41 PM, Nicholas Duane <nic...@msn.com> wrote:
> > I was debating offering to help.  Not that I wouldn't be interested, just
> > don't know how much time I could commit.  Also, not sure I would be
> > interested in "patching" log4net.  In my mind the best approach would be to
> > port log4j2.  I would like the two to be very similar, down to the level
> > values, configuration syntax, appenders, filters and extensibility.
> >
> >
> >
> > Thanks,
> >
> > Nick
> >
> >
> >
> > Date: Wed, 16 Sep 2015 15:25:19 -0700
> >
> > Subject: Re: Why is log4net not more similar to log4j(2)?
> >
> > From: garydgreg...@gmail.com
> >
> > To: log4j-user@logging.apache.org
> >
> > CC: log4net-u...@logging.apache.org
> >
> >
> >
> > I think I read somewhere that log4net was a port of log4j 1.
> >
> > "Patches welcome" is my motto :-)
> >
> > Gary
> >
> > On Wed, Sep 16, 2015 at 2:42 PM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > Sending to both the log4j and log4net mailing lists.
> >
> >
> >
> >
> >
> >
> >
> > I'm curious why log4net is not more similar to log4j(2)?  Is it because
> > there is less development work being done on log4net and log4j had
> > significant changes in the 2.0 version?  Any chance log4net might become
> > more of a "port" of log4j(2) and thus be more similar?
> >
> >
> >
> >
> >
> >
> >
> > Thanks,
> >
> >
> >
> > Nick
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >
> > Java Persistence with Hibernate, Second Edition
> >
> > JUnit in Action, Second Edition
> >
> > Spring Batch in Action
> >
> > 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
> > JUnit in Action, Second Edition
> > Spring Batch in Action
> > 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
  

markers

[Nicholas Duane]

I was about to starting writing a sample to see how markers work and to see if 
they could be used for logging business events instead of using a custom level. 
 While I might have mentioned log4net in passing, we're trying to capture these 
business events using existing logging frameworks.  The thinking is that we'd 
use log4net on windows and log4j(2) on linux (no facade).  Ideally the design 
would be similar across both platforms.  That being said, I'm surprised at how 
different log4net is from log4j(2).  It appears log4net doesn't support 
markers.  While we don't have to have the same solution for both platforms, it 
would be nice if the solutions were the same or similar.

I also looked at the EventLogger and that class doesn't have any overloads 
which take a marker, just a static marker property.  I guess the EventLogger 
can be assigned only a single marker?

Thanks,
Nick



  

RE: approach for defining loggers

[Nicholas Duane]

I think it's great that you took the time and effort to put this together.  
Hopefully it will help guide people in the correct direction as they work 
through these issues.  Hopefully this link is found when they google 'log4j log 
levels' or 'log4j loggers' etc..

1. While your level examples elude to this you don't, as far as I can tell, 
specifically spell this out.  I guess you're always assuming that level is a 
gradient or scale.  Meaning if I turn on a specific level I will get events for 
that level and any level more specific.  Would it be invalid to make level an 
enumeration and thus level would 'kind of' indicate event 'type'.

2. Wording problems maybe:

"What if others log from a third party library log"

"Now, I can configure Log4j to log only all events"

3. In the part about markers you indicate that with a marker you can enable 
logging for an event no matter what level the event was logged at.  In that 
case the below statement seems to contradict:

"Here, start by setting the root logger to WARN, then we set the oven to 
log at DEBUG because the oven logs door events at the DEBUG level, and 
the garage to log at INFO because the garage logs door events at the 
INFO level."

I thought it shouldn't matter if the over door logs at DEBUG level.  Can't I 
still set everything to WARN and use a marker to get the event logged?

4. Your markers section seems geared toward showing how to enable logging of 
events even if the level is off.  In my specific case, while I would of course 
need the event to be logged, I want to route specific types (/levels?) of 
events to specific appenders because different events are going to different 
locations.

Thanks,
Nick

> Date: Thu, 10 Sep 2015 21:21:09 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> This thread inspired me to explain logging concepts:
> 
> https://garygregory.wordpress.com/2015/09/10/the-art-of-test-driven-development-understanding-logging/
> 
> I hope it helps!
> 
> Gary
> 
> On Wed, Sep 9, 2015 at 12:47 AM, Mikael Ståldal <mikael.stal...@magine.com>
> wrote:
> 
> > Then perhaps you should create your own facade for doing business event
> > logging, which could then forward them to Log4j in an appropriate way.
> >
> > On Wed, Sep 9, 2015 at 4:49 AM, Nicholas Duane <nic...@msn.com> wrote:
> >
> > > I was just about to reply to your previous email about using a single
> > > "business" logger, or some hierarchy of business loggers, to log business
> > > events and say that we might go that route.  However, now that you
> > brought
> > > up the post from Ralph, which I just replied to, I'm thinking a logger
> > > won't work either for the same reason I listed in my reply to Ralph's
> > post.
> > >
> > > You could do:
> > >
> > > logger.info("Hello");
> > > logger.fatal("Hello");
> > > logger.error("Hello");
> > > ...
> > >
> > > It's confusing as there are n ways to log a business event that way and
> > > they will all do the same thing.  Which one should a developer choose.
> > > Should I say pick any one, it doesn't matter?
> > >
> > > Thanks,
> > > Nick
> > >
> > > > Date: Tue, 8 Sep 2015 19:28:21 -0700
> > > > Subject: Re: approach for defining loggers
> > > > From: garydgreg...@gmail.com
> > > > To: log4j-user@logging.apache.org
> > > >
> > > > Or
> > > > Logger logger = LogManager.getLogger("Business");
> > > > ...
> > > > logger.info("Hello");
> > > >
> > > > Gary
> > > >
> > > > On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <
> > ralph.go...@dslextreme.com>
> > > > wrote:
> > > >
> > > > > Can you please clarify, “If we had some way to know an event is a
> > > business
> > > > > event we wouldn’t need level”?  I do not understand how you can code
> > > > > logger.log(BUSINESS, msg)  but you cannot code logger.info(BUSINESS,
> > > msg).
> > > > >
> > > > > Ralph
> > > > >
> > > > > > On Sep 8, 2015, at 6:09 PM, Nicholas Duane <nic...@msn.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > I looked over that stackoverflow post and I'm still not seeing a
> > good
> > > > > match as a way for us to log our business events.
> > > > > &

RE: approach for defining loggers

[Nicholas Duane]

I am a bit confused now.  Previously someone said that if we used markers the 
level used in the log statement would be irrelevant.  However, based on this 
thread it looks like that's not the case.  Can someone give a definitive answer 
on what determines whether an event makes it to an appender?

Thanks,
Nick

> Date: Fri, 11 Sep 2015 16:46:14 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> On Fri, Sep 11, 2015 at 4:23 PM, Ralph Goers 
> wrote:
> 
> >
> > > On Sep 11, 2015, at 3:50 PM, Gary Gregory 
> > wrote:
> > >
> > >
> > > This updated text I hope will help:
> > >
> > > "No new loggers needed, just an additional parameter to your log call,
> > > regardless of the level API used.
> > >
> > > Now, I can configure Log4j to log only events that contain the marker
> > DOOR
> > > (if that level is enabled).”
> >
> > This isn’t necessarily true.  If you have a global filter that accepts the
> > event then the log level of the appropriate logger will not be checked.
> > However, other filters on the AppenderRef and Appenders will still be
> > checked.
> >
> 
> Hm, OK, but I am not sure I want to make that part of the article more
> complicated. I could say "if that level is enabled and a global filter did
> not accepts the event".
> 
> Gary
> 
> >
> > Ralph
> >
> >
> 
> 
> -- 
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> Java Persistence with Hibernate, Second Edition
> 
> JUnit in Action, Second Edition 
> Spring Batch in Action 
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
  

RE: approach for defining loggers

[Nicholas Duane]

I looked over that stackoverflow post and I'm still not seeing a good match as 
a way for us to log our business events.

A business event I guess is an event which extends whatever schema we come up 
with for a business event.  While an instance of this schema could be logged at 
any level, that really doesn't make sense in our scenario, regardless of 
whether some marker was supplied.  If we had some way to know an event is a 
business event we wouldn't need level.  We could of course add some property to 
our schema which indicates the 'category' of the event, 'business' being one 
such category.  Instead we were thinking we could just use level to indicate 
that an event is a business event.

As I mentioned, we're looking to capture 'trace' level events to one store, 
'info' - 'fatal' level events to another store, and 'business' events to yet 
another store.  For 'trace' and 'info' - 'fatal' it seems reasonable to filter 
on level within the appender to get those events to the appropriate location.  
It seemed reasonable to do something similar for 'business'.

I also looked into the EventLogger but not sure that's appropriate.  For one we 
lose the granularity to control a specific piece of code from generating 
business events.  This is most likely a non-issue as I have mentioned that we 
don't want to turn business logging off.  The other is that we lose the name of 
the logger as it would be the same for everyone.  Not sure this is that big a 
deal either as I guess you might be able to capture component name, though I 
would rather distinguish using logger name.

Thanks,
Nick

> From: ralph.go...@dslextreme.com
> Subject: Re: approach for defining loggers
> Date: Mon, 7 Sep 2015 20:39:11 -0700
> To: log4j-user@logging.apache.org
> 
> I still don’t understand why you don’t want to use Markers. They were 
> designed exactly for the use case you are describing.  
> 
> You might set retention policies for debug vs info, error and fatal, but a 
> BUSINESS marker could cross-cut them all.  That is exactly why it is NOT a 
> level. IOW, it gives you a second dimension for filtering. Ceki invented 
> Markers when he created SLF4J. For his point of view see 
> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
>  
> <http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>.
> 
> Ralph
> 
> 
> 
> 
> > On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > If I'm attempting to control all the logging from the configuration and I 
> > don't know the complete set of loggers in my application as there could be 
> > 100's or 1000's, wouldn't it be hard to separate events based on loggers?  
> > It would seem much easier to separate events based on level.  In addition, 
> > level might be a more reasonable approach for separating.  For example, if 
> > I want to send all events to some big-data backend I might want to separate 
> > out traces and debug from info to fatal as traces and debug are most likely 
> > less important from a systems management aspect.  My retention period for 
> > traces and debug might be just a couple days.  The retention period for 
> > info to fatal could be 30 days.  Business level might be 2 years.  Any 
> > system management notifications would probably be driven off of info to 
> > fatal events and not trace and debug events, which is another reason you 
> > might want to separate by level.  
> > 
> > Thanks,
> > Nick
> > 
> >> Subject: Re: approach for defining loggers
> >> From: ralph.go...@dslextreme.com
> >> Date: Mon, 31 Aug 2015 08:50:58 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> A logging “Level” is a level of importance. That is why there is a 
> >> hierarchy. If you want informational messages then you also would want 
> >> warnings and errors.
> >> 
> >> “BUSINESS” does not convey the same meaning.  Rather, it is some sort of 
> >> category, which is what Markers are for.
> >> 
> >> Using the class name as the logger name is a convention. If you really 
> >> want the class name, method name or line number then you should be 
> >> specifying that you want those from the logging event, rather than the 
> >> logger name.  Unless location information is disabled you always have 
> >> access to that information.
> >> 
> >> In short, different loggers are used primarily as a way of grouping sets 
> >> of messages - for example all org.hibernate events can be routed to a 
> >> specific appender or turned off en masse. Levels are used to

RE: approach for defining loggers

[Nicholas Duane]

Let's say we have a schema where one of the properties is "category".  
"category" could be "info", "warn", "business", "audit", etc.  I could use that 
property to forward the events to the appropriate places.  We don't have that 
property because I guess we don't think we need it.  The current thinking is 
that level will tell us whether an event is a business event or some other type 
of event.

The problem with:

logger.info(BUSINESS, msg)

is that you could also do:

logger.debug(BUSINESS, msg);
logger.fatal(BUSINESS, msg);
logger.error(BUSINESS, msg);

the users will ask us which one they should use.  If they are all going to do 
the same thing then that's a problem.  You don't want n ways to do the same 
thing as that will just cause confusion.

Thanks,
Nick

> Subject: Re: approach for defining loggers
> From: ralph.go...@dslextreme.com
> Date: Tue, 8 Sep 2015 19:24:32 -0700
> To: log4j-user@logging.apache.org
> 
> Can you please clarify, “If we had some way to know an event is a business 
> event we wouldn’t need level”?  I do not understand how you can code 
> logger.log(BUSINESS, msg)  but you cannot code logger.info(BUSINESS, msg).
> 
> Ralph
> 
> > On Sep 8, 2015, at 6:09 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > 
> > 
> > 
> > I looked over that stackoverflow post and I'm still not seeing a good match 
> > as a way for us to log our business events.
> > 
> > A business event I guess is an event which extends whatever schema we come 
> > up with for a business event.  While an instance of this schema could be 
> > logged at any level, that really doesn't make sense in our scenario, 
> > regardless of whether some marker was supplied.  If we had some way to know 
> > an event is a business event we wouldn't need level.  We could of course 
> > add some property to our schema which indicates the 'category' of the 
> > event, 'business' being one such category.  Instead we were thinking we 
> > could just use level to indicate that an event is a business event.
> > 
> > As I mentioned, we're looking to capture 'trace' level events to one store, 
> > 'info' - 'fatal' level events to another store, and 'business' events to 
> > yet another store.  For 'trace' and 'info' - 'fatal' it seems reasonable to 
> > filter on level within the appender to get those events to the appropriate 
> > location.  It seemed reasonable to do something similar for 'business'.
> > 
> > I also looked into the EventLogger but not sure that's appropriate.  For 
> > one we lose the granularity to control a specific piece of code from 
> > generating business events.  This is most likely a non-issue as I have 
> > mentioned that we don't want to turn business logging off.  The other is 
> > that we lose the name of the logger as it would be the same for everyone.  
> > Not sure this is that big a deal either as I guess you might be able to 
> > capture component name, though I would rather distinguish using logger name.
> > 
> > Thanks,
> > Nick
> > 
> >> From: ralph.go...@dslextreme.com
> >> Subject: Re: approach for defining loggers
> >> Date: Mon, 7 Sep 2015 20:39:11 -0700
> >> To: log4j-user@logging.apache.org
> >> 
> >> I still don’t understand why you don’t want to use Markers. They were 
> >> designed exactly for the use case you are describing.  
> >> 
> >> You might set retention policies for debug vs info, error and fatal, but a 
> >> BUSINESS marker could cross-cut them all.  That is exactly why it is NOT a 
> >> level. IOW, it gives you a second dimension for filtering. Ceki invented 
> >> Markers when he created SLF4J. For his point of view see 
> >> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >>  
> >> <http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>.
> >> 
> >> Ralph
> >> 
> >> 
> >> 
> >> 
> >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> If I'm attempting to control all the logging from the configuration and I 
> >>> don't know the complete set of loggers in my application as there could 
> >>> be 100's or 1000's, wouldn't it be hard to separate events based on 
> >>> loggers?  It would seem much easier to separate events based on level.  
> >>> In addition, level might be a more reasonable approach for separating.  
> >>> F

RE: approach for defining loggers

[Nicholas Duane]

I was just about to reply to your previous email about using a single 
"business" logger, or some hierarchy of business loggers, to log business 
events and say that we might go that route.  However, now that you brought up 
the post from Ralph, which I just replied to, I'm thinking a logger won't work 
either for the same reason I listed in my reply to Ralph's post.

You could do:

logger.info("Hello");
logger.fatal("Hello");
logger.error("Hello");
...

It's confusing as there are n ways to log a business event that way and they 
will all do the same thing.  Which one should a developer choose.  Should I say 
pick any one, it doesn't matter?

Thanks,
Nick

> Date: Tue, 8 Sep 2015 19:28:21 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> Or
> Logger logger = LogManager.getLogger("Business");
> ...
> logger.info("Hello");
> 
> Gary
> 
> On Tue, Sep 8, 2015 at 7:24 PM, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> 
> > Can you please clarify, “If we had some way to know an event is a business
> > event we wouldn’t need level”?  I do not understand how you can code
> > logger.log(BUSINESS, msg)  but you cannot code logger.info(BUSINESS, msg).
> >
> > Ralph
> >
> > > On Sep 8, 2015, at 6:09 PM, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > >
> > >
> > >
> > > I looked over that stackoverflow post and I'm still not seeing a good
> > match as a way for us to log our business events.
> > >
> > > A business event I guess is an event which extends whatever schema we
> > come up with for a business event.  While an instance of this schema could
> > be logged at any level, that really doesn't make sense in our scenario,
> > regardless of whether some marker was supplied.  If we had some way to know
> > an event is a business event we wouldn't need level.  We could of course
> > add some property to our schema which indicates the 'category' of the
> > event, 'business' being one such category.  Instead we were thinking we
> > could just use level to indicate that an event is a business event.
> > >
> > > As I mentioned, we're looking to capture 'trace' level events to one
> > store, 'info' - 'fatal' level events to another store, and 'business'
> > events to yet another store.  For 'trace' and 'info' - 'fatal' it seems
> > reasonable to filter on level within the appender to get those events to
> > the appropriate location.  It seemed reasonable to do something similar for
> > 'business'.
> > >
> > > I also looked into the EventLogger but not sure that's appropriate.  For
> > one we lose the granularity to control a specific piece of code from
> > generating business events.  This is most likely a non-issue as I have
> > mentioned that we don't want to turn business logging off.  The other is
> > that we lose the name of the logger as it would be the same for everyone.
> > Not sure this is that big a deal either as I guess you might be able to
> > capture component name, though I would rather distinguish using logger name.
> > >
> > > Thanks,
> > > Nick
> > >
> > >> From: ralph.go...@dslextreme.com
> > >> Subject: Re: approach for defining loggers
> > >> Date: Mon, 7 Sep 2015 20:39:11 -0700
> > >> To: log4j-user@logging.apache.org
> > >>
> > >> I still don’t understand why you don’t want to use Markers. They were
> > designed exactly for the use case you are describing.
> > >>
> > >> You might set retention policies for debug vs info, error and fatal,
> > but a BUSINESS marker could cross-cut them all.  That is exactly why it is
> > NOT a level. IOW, it gives you a second dimension for filtering. Ceki
> > invented Markers when he created SLF4J. For his point of view see
> > http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > <
> > http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > >.
> > >>
> > >> Ralph
> > >>
> > >>
> > >>
> > >>
> > >>> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote:
> > >>>
> > >>> If I'm attempting to control all the logging from the configuration
> > and I don't know the complete set of loggers in my application as there
> > could be 100's or 1000's, wouldn't it be 

RE: approach for defining loggers

[Nicholas Duane]

I will certainly look them over again.
Thanks,Nick

 Original message 
From: Ralph Goers <ralph.go...@dslextreme.com>
Date: 09/07/2015  9:39 PM  (GMT-07:00)
To: Log4J Users List <log4j-user@logging.apache.org>
Subject: Re: approach for defining loggers

I still don’t understand why you don’t want to use Markers. They were designed 
exactly for the use case you are describing.

You might set retention policies for debug vs info, error and fatal, but a 
BUSINESS marker could cross-cut them all.  That is exactly why it is NOT a 
level. IOW, it gives you a second dimension for filtering. Ceki invented 
Markers when he created SLF4J. For his point of view see 
http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
 
<http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them>.

Ralph




> On Sep 7, 2015, at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote:
>
> If I'm attempting to control all the logging from the configuration and I 
> don't know the complete set of loggers in my application as there could be 
> 100's or 1000's, wouldn't it be hard to separate events based on loggers?  It 
> would seem much easier to separate events based on level.  In addition, level 
> might be a more reasonable approach for separating.  For example, if I want 
> to send all events to some big-data backend I might want to separate out 
> traces and debug from info to fatal as traces and debug are most likely less 
> important from a systems management aspect.  My retention period for traces 
> and debug might be just a couple days.  The retention period for info to 
> fatal could be 30 days.  Business level might be 2 years.  Any system 
> management notifications would probably be driven off of info to fatal events 
> and not trace and debug events, which is another reason you might want to 
> separate by level.
>
> Thanks,
> Nick
>
>> Subject: Re: approach for defining loggers
>> From: ralph.go...@dslextreme.com
>> Date: Mon, 31 Aug 2015 08:50:58 -0700
>> To: log4j-user@logging.apache.org
>>
>> A logging “Level” is a level of importance. That is why there is a 
>> hierarchy. If you want informational messages then you also would want 
>> warnings and errors.
>>
>> “BUSINESS” does not convey the same meaning.  Rather, it is some sort of 
>> category, which is what Markers are for.
>>
>> Using the class name as the logger name is a convention. If you really want 
>> the class name, method name or line number then you should be specifying 
>> that you want those from the logging event, rather than the logger name.  
>> Unless location information is disabled you always have access to that 
>> information.
>>
>> In short, different loggers are used primarily as a way of grouping sets of 
>> messages - for example all org.hibernate events can be routed to a specific 
>> appender or turned off en masse. Levels are used to filter out noise across 
>> a set of logging events. Markers are used to categorize logging events by 
>> arbitrary attributes.
>>
>> Ralph
>>
>>
>>> On Aug 31, 2015, at 8:10 AM, Nicholas Duane <nic...@msn.com> wrote:
>>>
>>> Thanks for the feedback.  I will look into Markers and MDC.
>>>
>>> With respect to using a separate logger, it would seem I would lose the 
>>> information about what application code, eg. the class logger, is sourcing 
>>> the event.  We would like to have this information.  On top of that, it 
>>> seems odd, maybe to me only, that for this new level we have our own 
>>> logger.  It seemed reasonable to me that this new event we want to capture 
>>> is just a new level.  Just like a DEBUG event is different from an INFO 
>>> event.  If I define a BUSINESS level why would that not follow the same 
>>> design as the current levels?  You wouldn't suggest having different 
>>> loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you?  I think one of 
>>> the reasons someone on our side is suggesting I have separate loggers is 
>>> that they think the overhead of filtering at the appender is going to have 
>>> a noticeable impact.  Our plan, at least the one I have now in my head, is 
>>> that we'll have some number of appenders in the root.  We'll then filter x 
>>> < INFO events to a tracing appender, INFO <= x <= FATAL to a logging 
>>> appender, and our custom level will go to another appender.  Thoughts?
>>>
>>> Thanks,
>>> Nick
>>>
>>>> Subject: Re: approach for definin

RE: approach for defining loggers

[Nicholas Duane]

Yeah, I'm aware of that feature in log4j/log4net.  Very nice one by the way.  
One of the big pluses in my mind.  Makes it very easy to control a while slew 
of loggers based on name.
 
Though in our case we probably won't know many, if any, of the logger names.  
We basically want to direct all traces to one location, all info to fatal to 
another location and business events to yet a third location.
 
Thanks,
Nick
 
> Date: Mon, 7 Sep 2015 18:35:13 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> Don't forget that loggers can be controlled by their hierarchical names:
> com.example = DEBUG, usually sets all levels below it to DEBUG, like
> com.example.feature1.sub1, com.example.feature1.sub2, com.example.feature2,
> and so on.
> 
> Gary
> 
> On Mon, Sep 7, 2015 at 5:54 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > If I'm attempting to control all the logging from the configuration and I
> > don't know the complete set of loggers in my application as there could be
> > 100's or 1000's, wouldn't it be hard to separate events based on loggers?
> > It would seem much easier to separate events based on level.  In addition,
> > level might be a more reasonable approach for separating.  For example, if
> > I want to send all events to some big-data backend I might want to separate
> > out traces and debug from info to fatal as traces and debug are most likely
> > less important from a systems management aspect.  My retention period for
> > traces and debug might be just a couple days.  The retention period for
> > info to fatal could be 30 days.  Business level might be 2 years.  Any
> > system management notifications would probably be driven off of info to
> > fatal events and not trace and debug events, which is another reason you
> > might want to separate by level.
> >
> > Thanks,
> > Nick
> >
> > > Subject: Re: approach for defining loggers
> > > From: ralph.go...@dslextreme.com
> > > Date: Mon, 31 Aug 2015 08:50:58 -0700
> > > To: log4j-user@logging.apache.org
> > >
> > > A logging “Level” is a level of importance. That is why there is a
> > hierarchy. If you want informational messages then you also would want
> > warnings and errors.
> > >
> > > “BUSINESS” does not convey the same meaning.  Rather, it is some sort of
> > category, which is what Markers are for.
> > >
> > > Using the class name as the logger name is a convention. If you really
> > want the class name, method name or line number then you should be
> > specifying that you want those from the logging event, rather than the
> > logger name.  Unless location information is disabled you always have
> > access to that information.
> > >
> > > In short, different loggers are used primarily as a way of grouping sets
> > of messages - for example all org.hibernate events can be routed to a
> > specific appender or turned off en masse. Levels are used to filter out
> > noise across a set of logging events. Markers are used to categorize
> > logging events by arbitrary attributes.
> > >
> > > Ralph
> > >
> > >
> > > > On Aug 31, 2015, at 8:10 AM, Nicholas Duane <nic...@msn.com> wrote:
> > > >
> > > > Thanks for the feedback.  I will look into Markers and MDC.
> > > >
> > > > With respect to using a separate logger, it would seem I would lose
> > the information about what application code, eg. the class logger, is
> > sourcing the event.  We would like to have this information.  On top of
> > that, it seems odd, maybe to me only, that for this new level we have our
> > own logger.  It seemed reasonable to me that this new event we want to
> > capture is just a new level.  Just like a DEBUG event is different from an
> > INFO event.  If I define a BUSINESS level why would that not follow the
> > same design as the current levels?  You wouldn't suggest having different
> > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you?  I think one of
> > the reasons someone on our side is suggesting I have separate loggers is
> > that they think the overhead of filtering at the appender is going to have
> > a noticeable impact.  Our plan, at least the one I have now in my head, is
> > that we'll have some number of appenders in the root.  We'll then filter x
> > < INFO events to a tracing appender, INFO <= x <= FATAL to a logging
> > appender, and our custom level will go to another appender.  Thoughts?
> > > >
> > > > Thanks,
> > >

RE: approach for defining loggers

[Nicholas Duane]

I was re-reading this and thought I should respond.  You mentioned that levels 
are used to indicate the importance of what you logged.  The logger helps you 
with "what is it that I'm trying to tell" the audience, if I have that correct. 
 Which I kind of agree.  The logger, in my mind, indicates the "area" of code 
which is sourcing the events.  In your example you have an authentication 
module which has its own logger.  All events (hopefully using the terms events 
is ok) logged from that logger has to do with authentication.  The 
authentication module uses its logger to log events at different levels.  So in 
my scenario, the authentication module might want to log a "Business" event.  
In reality this probably would not happen as the business events would most 
likely be sourced from LOB application code.  However, each component of LOB 
application code might have its own logger and if it needs to log a business 
event it should do so from its logger.
 
I did look at markers and it would seem if I used them for these business 
events I would still be logging the business events at some level and would 
include a marker.  This seems odd to me as the level would seem pointless and 
thus picking one would be arbitrary.
 
Someone had mentioned using the EventLogger.  I still have to look into that, 
but that sounds like a single logger which I initially thought was not required 
and instead the advice would be to log via whatever logger you're using for 
your other events.  However, maybe the EventLogger will work.
 
Thanks,
Nick

 
> Date: Mon, 31 Aug 2015 15:16:49 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > All sounds reasonable to me.  I'm not sure any of the statements you made
> > go against anything I have stated.  Please let me know if you think
> > otherwise.
> >
> > In your authentication module, you log all levels through its logger,
> > right?
> 
> 
> Yes.
> 
> 
> > You don't use separate loggers to log different levels do you?
> >
> 
> No separate loggers per levels.
> 
> Gary
> 
> 
> >
> > Thanks,
> > Nick
> >
> > > Date: Mon, 31 Aug 2015 15:02:09 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgreg...@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > I think of levels as "how important is this" and "who needs to know
> > this".
> > > Some of the art of logging is deciding who you audience is. To help your
> > > development team chase down a bug, you want to make sure that the app
> > logs
> > > interesting events at the DEBUG and TRACE level. This is different that
> > > "what it is I am telling this audience", which is where I use loggers. To
> > > tell who comes in and out of the system, I have logging in the
> > > authentication module. To tell what kind of SQL goes to the database, I
> > > have DEBUG logging in my DB interface code.
> > >
> > > I think that once you start chasing down issues and bugs, and writing
> > code
> > > to help you do that, then it might become more obvious, as to what to do.
> > >
> > > Gary
> > >
> > > On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > > > I did look through a bit of documentation on markers:
> > > >
> > > > https://logging.apache.org/log4j/2.0/manual/markers.html
> > > >
> > > >
> > http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > > >
> > > > My initial impression is that I don't want to use markers.  What I'd
> > like
> > > > to be able to say is:
> > > >
> > > > "log the way you have been logging in the past.  You don't need to know
> > > > about any special loggers.  Use your own.  Here is a new level for our
> > new
> > > > type of "event".  Use that to log this new event."
> > > >
> > > > I guess I'm not understanding your vernacular in terms of levels.  In
> > my
> > > > mind the different levels also define different "types" of events.  For
> > > > instance, DEBUG and less specific I would see as tracing type events
> > which
> > > > are non-functional in nature.  They are purely for understanding the
> > call
> > > > flow, or for performance gathering, or det

RE: approach for defining loggers

[Nicholas Duane]

Thanks for the feedback.  I will look into Markers and MDC.
 
With respect to using a separate logger, it would seem I would lose the 
information about what application code, eg. the class logger, is sourcing the 
event.  We would like to have this information.  On top of that, it seems odd, 
maybe to me only, that for this new level we have our own logger.  It seemed 
reasonable to me that this new event we want to capture is just a new level.  
Just like a DEBUG event is different from an INFO event.  If I define a 
BUSINESS level why would that not follow the same design as the current levels? 
 You wouldn't suggest having different loggers for TRACE DEBUG INFO WARN ERROR 
FATAL, would you?  I think one of the reasons someone on our side is suggesting 
I have separate loggers is that they think the overhead of filtering at the 
appender is going to have a noticeable impact.  Our plan, at least the one I 
have now in my head, is that we'll have some number of appenders in the root.  
We'll then filter x < INFO events to a tracing appender, INFO <= x <= FATAL to 
a logging appender, and our custom level will go to another appender.  Thoughts?
 
Thanks,
Nick
 
> Subject: Re: approach for defining loggers
> From: ralph.go...@dslextreme.com
> Date: Sat, 29 Aug 2015 20:59:36 -0700
> To: log4j-user@logging.apache.org
> 
> 
> > On Aug 29, 2015, at 7:44 PM, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > I'm curious if there is a prescribed approach to defining loggers.  Let me 
> > state what my assumption is.  I assume that normally if some piece of code 
> > wants to log events/messages that it should create a logger for itself.  I 
> > guess a reasonable name to use is the class name itself.  In terms of 
> > logger configuration I would expect that no loggers are specified in the 
> > log4j configuration UNLESS is needs settings other than the default.  The 
> > root logger would specify the default settings, eg. level and appenders.  
> > If some piece of code tied to a logger needs to enable tracing in order to 
> > debug an issue then you would add that logger to the configuration and set 
> > the level less specific for that logger.  Is this a typical and reasonable 
> > approach?
> 
> What you describe here is the common convention. It is a reasonable approach.
> 
> > 
> > I asked because we have the need for a new type of event.  To have this 
> > event flow to where we want it to flow the plan is to have a custom level 
> > and have all events at that level captured by a specific appender.  My 
> > assumption was that for existing applications we'd just need to add our 
> > appender to the root and add our custom level.  The app would need to be 
> > modified to log our new event at the custom level.  However, someone 
> > suggested that we could also create a separate logger for this event.  My 
> > thinking is that while we don't ever want to turn off logging of this 
> > event, loggers represent "event sources", e.g the code raising the events 
> > and thus having multiple different pieces of code use the same logger 
> > wouldn't allow you to turn on/off logging from those different sections of 
> > code independently.  I think the current configuration includes all the 
> > loggers.  Normally I would expect there to be many, on the order of 10's or 
> > 100's, loggers within an application.  However, in the case I was given 
> > there were only a handful because I think this handful is shared.  So as I 
> > mentioned, this doesn't sound like an ideal design as you have less 
> > granularity on what you can turn on/off.
> 
> You have a few options. Using a CustomLevel would not be the option I would 
> choose.  Creating a custom Logger will certainly work and makes routing the 
> message to the appropriate appender rather easy.  Another approach is to use 
> Markers.  Markers are somewhat hierarchical so you can use them for a variety 
> of purposes.  If you look at how Log4j handles event logging it actually does 
> both - it specifies EventLogger as the name of the logger to use and it uses 
> Markers to identify the kind of event.
> 
> A third option is to use the MDC or Logger properties. If you do that then 
> you can have information included in the actual logging event that can affect 
> how it is routed. I also built a system that uses the RFC5424 format so that 
> the event could have lots of key/value pairs to identify the events.
> 
> Unfortunately, without knowing more details I don’t know that I can give you 
> a better idea on how I would implement it.
> 
> Ralph
> 
> -
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
  

RE: approach for defining loggers

[Nicholas Duane]

All sounds reasonable to me.  I'm not sure any of the statements you made go 
against anything I have stated.  Please let me know if you think otherwise.
 
In your authentication module, you log all levels through its logger, right?  
You don't use separate loggers to log different levels do you?
 
Thanks,
Nick
 
> Date: Mon, 31 Aug 2015 15:02:09 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> I think of levels as "how important is this" and "who needs to know this".
> Some of the art of logging is deciding who you audience is. To help your
> development team chase down a bug, you want to make sure that the app logs
> interesting events at the DEBUG and TRACE level. This is different that
> "what it is I am telling this audience", which is where I use loggers. To
> tell who comes in and out of the system, I have logging in the
> authentication module. To tell what kind of SQL goes to the database, I
> have DEBUG logging in my DB interface code.
> 
> I think that once you start chasing down issues and bugs, and writing code
> to help you do that, then it might become more obvious, as to what to do.
> 
> Gary
> 
> On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > I did look through a bit of documentation on markers:
> >
> > https://logging.apache.org/log4j/2.0/manual/markers.html
> >
> > http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >
> > My initial impression is that I don't want to use markers.  What I'd like
> > to be able to say is:
> >
> > "log the way you have been logging in the past.  You don't need to know
> > about any special loggers.  Use your own.  Here is a new level for our new
> > type of "event".  Use that to log this new event."
> >
> > I guess I'm not understanding your vernacular in terms of levels.  In my
> > mind the different levels also define different "types" of events.  For
> > instance, DEBUG and less specific I would see as tracing type events which
> > are non-functional in nature.  They are purely for understanding the call
> > flow, or for performance gathering, or detailed diagnosis.  Those could be
> > turned off totally without having much impact on system management.  The
> > same can't be said for FATAL to INFO.  These levels should always be on so
> > that you can properly manage the system.
> >
> > Thanks,
> > Nick
> >
> > > Date: Mon, 31 Aug 2015 08:37:25 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgreg...@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > Hi Nick,
> > >
> > > Creating a single new level is seldom the right solution IMO. It's not
> > like
> > > you are missing a level of granularity (we have custom level examples
> > that
> > > demonstrate that, like a VERBOSE level that sits between INFO and DEBUG).
> > > It sounds like you need to use _hierarchical_ loggers and/or markers.
> > >
> > > The fact that the level is called BUSINESS is also a hint that a level is
> > > not quite right because it does not fit in the Level vernacular (INFO,
> > > WARN, and so on).
> > >
> > > If you needed a different set of levels, that would be another story
> > (like
> > > the DEFCON levels example).
> > >
> > > Gary
> > >
> > > On Mon, Aug 31, 2015 at 8:10 AM, Nicholas Duane <nic...@msn.com> wrote:
> > >
> > > > Thanks for the feedback.  I will look into Markers and MDC.
> > > >
> > > > With respect to using a separate logger, it would seem I would lose the
> > > > information about what application code, eg. the class logger, is
> > sourcing
> > > > the event.  We would like to have this information.  On top of that, it
> > > > seems odd, maybe to me only, that for this new level we have our own
> > > > logger.  It seemed reasonable to me that this new event we want to
> > capture
> > > > is just a new level.  Just like a DEBUG event is different from an INFO
> > > > event.  If I define a BUSINESS level why would that not follow the same
> > > > design as the current levels?  You wouldn't suggest having different
> > > > loggers for TRACE DEBUG INFO WARN ERROR FATAL, would you?  I think one
> > of
> > > > the reasons someone on our side is suggesting I have s

RE: approach for defining loggers

[Nicholas Duane]

While I'm new to log4j I would say I'm not new to logging.  We've written our 
own logging framework 14 or so years ago.  It was on the Microsoft platform and 
was originally targeting the unmanaged world.  We later wrote a managed wrapper 
on it so we could use it from .NET.  Most of the events flow through ETW and 
end up in log files which are then Ftp'd to a central location.
 
Thanks,
Nick
 
> Date: Mon, 31 Aug 2015 15:38:55 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> All of this makes me think we need docs for users new to logging...
> 
> Gary
> 
> On Mon, Aug 31, 2015 at 3:16 PM, Gary Gregory <garydgreg...@gmail.com>
> wrote:
> 
> > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <nic...@msn.com> wrote:
> >
> >> All sounds reasonable to me.  I'm not sure any of the statements you made
> >> go against anything I have stated.  Please let me know if you think
> >> otherwise.
> >>
> >> In your authentication module, you log all levels through its logger,
> >> right?
> >
> >
> > Yes.
> >
> >
> >> You don't use separate loggers to log different levels do you?
> >>
> >
> > No separate loggers per levels.
> >
> > Gary
> >
> >
> >>
> >> Thanks,
> >> Nick
> >>
> >> > Date: Mon, 31 Aug 2015 15:02:09 -0700
> >> > Subject: Re: approach for defining loggers
> >> > From: garydgreg...@gmail.com
> >> > To: log4j-user@logging.apache.org
> >> >
> >> > I think of levels as "how important is this" and "who needs to know
> >> this".
> >> > Some of the art of logging is deciding who you audience is. To help your
> >> > development team chase down a bug, you want to make sure that the app
> >> logs
> >> > interesting events at the DEBUG and TRACE level. This is different that
> >> > "what it is I am telling this audience", which is where I use loggers.
> >> To
> >> > tell who comes in and out of the system, I have logging in the
> >> > authentication module. To tell what kind of SQL goes to the database, I
> >> > have DEBUG logging in my DB interface code.
> >> >
> >> > I think that once you start chasing down issues and bugs, and writing
> >> code
> >> > to help you do that, then it might become more obvious, as to what to
> >> do.
> >> >
> >> > Gary
> >> >
> >> > On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote:
> >> >
> >> > > I did look through a bit of documentation on markers:
> >> > >
> >> > > https://logging.apache.org/log4j/2.0/manual/markers.html
> >> > >
> >> > >
> >> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >> > >
> >> > > My initial impression is that I don't want to use markers.  What I'd
> >> like
> >> > > to be able to say is:
> >> > >
> >> > > "log the way you have been logging in the past.  You don't need to
> >> know
> >> > > about any special loggers.  Use your own.  Here is a new level for
> >> our new
> >> > > type of "event".  Use that to log this new event."
> >> > >
> >> > > I guess I'm not understanding your vernacular in terms of levels.  In
> >> my
> >> > > mind the different levels also define different "types" of events.
> >> For
> >> > > instance, DEBUG and less specific I would see as tracing type events
> >> which
> >> > > are non-functional in nature.  They are purely for understanding the
> >> call
> >> > > flow, or for performance gathering, or detailed diagnosis.  Those
> >> could be
> >> > > turned off totally without having much impact on system management.
> >> The
> >> > > same can't be said for FATAL to INFO.  These levels should always be
> >> on so
> >> > > that you can properly manage the system.
> >> > >
> >> > > Thanks,
> >> > > Nick
> >> > >
> >> > > > Date: Mon, 31 Aug 2015 08:37:25 -0700
> >> > > > Subject: Re: approach for defining loggers
> >> > > > From: garydgreg...@gmail.com
> >

RE: approach for defining loggers

[Nicholas Duane]

Your example sounds reasonable.
 
Thanks,
Nick
 
> Subject: Re: approach for defining loggers
> From: remko.po...@gmail.com
> Date: Tue, 1 Sep 2015 07:57:57 +0900
> To: log4j-user@logging.apache.org
> 
> Not sure that I understand your use case, so let me give a concrete example 
> of how I use loggers. 
> 
> At work I have a component that is responsible for handling marketdata. 
> This component has two loggers: one that uses the component class name as its 
> name, another called "RAW_FEED". The first logs stuff about initialization 
> and for example when another component subscribes to market data. The second 
> (RAW_FEED) one logs every market data event as it comes off the wire to a 
> separate file (via a separate appender). 
> 
> This allows us to switch the RAW_FEED off on some systems and on on others. 
> 
> I suggest you simply do what achieves your goals. If there are multiple 
> options then choose the one that is easiest for your team to maintain. 
> 
> Sent from my iPhone
> 
> > On 2015/09/01, at 7:07, Nicholas Duane <nic...@msn.com> wrote:
> > 
> > All sounds reasonable to me.  I'm not sure any of the statements you made 
> > go against anything I have stated.  Please let me know if you think 
> > otherwise.
> > 
> > In your authentication module, you log all levels through its logger, 
> > right?  You don't use separate loggers to log different levels do you?
> > 
> > Thanks,
> > Nick
> > 
> >> Date: Mon, 31 Aug 2015 15:02:09 -0700
> >> Subject: Re: approach for defining loggers
> >> From: garydgreg...@gmail.com
> >> To: log4j-user@logging.apache.org
> >> 
> >> I think of levels as "how important is this" and "who needs to know this".
> >> Some of the art of logging is deciding who you audience is. To help your
> >> development team chase down a bug, you want to make sure that the app logs
> >> interesting events at the DEBUG and TRACE level. This is different that
> >> "what it is I am telling this audience", which is where I use loggers. To
> >> tell who comes in and out of the system, I have logging in the
> >> authentication module. To tell what kind of SQL goes to the database, I
> >> have DEBUG logging in my DB interface code.
> >> 
> >> I think that once you start chasing down issues and bugs, and writing code
> >> to help you do that, then it might become more obvious, as to what to do.
> >> 
> >> Gary
> >> 
> >>> On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com> wrote:
> >>> 
> >>> I did look through a bit of documentation on markers:
> >>> 
> >>> https://logging.apache.org/log4j/2.0/manual/markers.html
> >>> 
> >>> http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> >>> 
> >>> My initial impression is that I don't want to use markers.  What I'd like
> >>> to be able to say is:
> >>> 
> >>> "log the way you have been logging in the past.  You don't need to know
> >>> about any special loggers.  Use your own.  Here is a new level for our new
> >>> type of "event".  Use that to log this new event."
> >>> 
> >>> I guess I'm not understanding your vernacular in terms of levels.  In my
> >>> mind the different levels also define different "types" of events.  For
> >>> instance, DEBUG and less specific I would see as tracing type events which
> >>> are non-functional in nature.  They are purely for understanding the call
> >>> flow, or for performance gathering, or detailed diagnosis.  Those could be
> >>> turned off totally without having much impact on system management.  The
> >>> same can't be said for FATAL to INFO.  These levels should always be on so
> >>> that you can properly manage the system.
> >>> 
> >>> Thanks,
> >>> Nick
> >>> 
> >>>> Date: Mon, 31 Aug 2015 08:37:25 -0700
> >>>> Subject: Re: approach for defining loggers
> >>>> From: garydgreg...@gmail.com
> >>>> To: log4j-user@logging.apache.org
> >>>> 
> >>>> Hi Nick,
> >>>> 
> >>>> Creating a single new level is seldom the right solution IMO. It's not
> >>> like
> >>>> you are missing a level of granularity (we have custom level examples
> >>> that
> >>>> demons

RE: approach for defining loggers

[Nicholas Duane]

And I agree.  Just letting you know I'm not a total noob when it comes to 
logging, just log4j and log4net are new to me.
 
Thanks,
Nick
 
> Date: Mon, 31 Aug 2015 15:56:40 -0700
> Subject: Re: approach for defining loggers
> From: garydgreg...@gmail.com
> To: log4j-user@logging.apache.org
> 
> Roger that. I'm just wondering how we can better serve visitors to the
> site...
> 
> Gary
> 
> On Mon, Aug 31, 2015 at 3:47 PM, Nicholas Duane <nic...@msn.com> wrote:
> 
> > While I'm new to log4j I would say I'm not new to logging.  We've written
> > our own logging framework 14 or so years ago.  It was on the Microsoft
> > platform and was originally targeting the unmanaged world.  We later wrote
> > a managed wrapper on it so we could use it from .NET.  Most of the events
> > flow through ETW and end up in log files which are then Ftp'd to a central
> > location.
> >
> > Thanks,
> > Nick
> >
> > > Date: Mon, 31 Aug 2015 15:38:55 -0700
> > > Subject: Re: approach for defining loggers
> > > From: garydgreg...@gmail.com
> > > To: log4j-user@logging.apache.org
> > >
> > > All of this makes me think we need docs for users new to logging...
> > >
> > > Gary
> > >
> > > On Mon, Aug 31, 2015 at 3:16 PM, Gary Gregory <garydgreg...@gmail.com>
> > > wrote:
> > >
> > > > On Mon, Aug 31, 2015 at 3:07 PM, Nicholas Duane <nic...@msn.com>
> > wrote:
> > > >
> > > >> All sounds reasonable to me.  I'm not sure any of the statements you
> > made
> > > >> go against anything I have stated.  Please let me know if you think
> > > >> otherwise.
> > > >>
> > > >> In your authentication module, you log all levels through its logger,
> > > >> right?
> > > >
> > > >
> > > > Yes.
> > > >
> > > >
> > > >> You don't use separate loggers to log different levels do you?
> > > >>
> > > >
> > > > No separate loggers per levels.
> > > >
> > > > Gary
> > > >
> > > >
> > > >>
> > > >> Thanks,
> > > >> Nick
> > > >>
> > > >> > Date: Mon, 31 Aug 2015 15:02:09 -0700
> > > >> > Subject: Re: approach for defining loggers
> > > >> > From: garydgreg...@gmail.com
> > > >> > To: log4j-user@logging.apache.org
> > > >> >
> > > >> > I think of levels as "how important is this" and "who needs to know
> > > >> this".
> > > >> > Some of the art of logging is deciding who you audience is. To help
> > your
> > > >> > development team chase down a bug, you want to make sure that the
> > app
> > > >> logs
> > > >> > interesting events at the DEBUG and TRACE level. This is different
> > that
> > > >> > "what it is I am telling this audience", which is where I use
> > loggers.
> > > >> To
> > > >> > tell who comes in and out of the system, I have logging in the
> > > >> > authentication module. To tell what kind of SQL goes to the
> > database, I
> > > >> > have DEBUG logging in my DB interface code.
> > > >> >
> > > >> > I think that once you start chasing down issues and bugs, and
> > writing
> > > >> code
> > > >> > to help you do that, then it might become more obvious, as to what
> > to
> > > >> do.
> > > >> >
> > > >> > Gary
> > > >> >
> > > >> > On Mon, Aug 31, 2015 at 2:51 PM, Nicholas Duane <nic...@msn.com>
> > wrote:
> > > >> >
> > > >> > > I did look through a bit of documentation on markers:
> > > >> > >
> > > >> > > https://logging.apache.org/log4j/2.0/manual/markers.html
> > > >> > >
> > > >> > >
> > > >>
> > http://stackoverflow.com/questions/16813032/what-is-markers-in-java-logging-frameworks-and-that-is-a-reason-to-use-them
> > > >> > >
> > > >> > > My initial impression is that I don't want to use markers.  What
> > I'd
> > > >> like
> > > >> > > to be able to say is:
> > > >> > >
> > > >> > > "log the way you ha

approach for defining loggers

[Nicholas Duane]

I'm curious if there is a prescribed approach to defining loggers.  Let me 
state what my assumption is.  I assume that normally if some piece of code 
wants to log events/messages that it should create a logger for itself.  I 
guess a reasonable name to use is the class name itself.  In terms of logger 
configuration I would expect that no loggers are specified in the log4j 
configuration UNLESS is needs settings other than the default.  The root logger 
would specify the default settings, eg. level and appenders.  If some piece of 
code tied to a logger needs to enable tracing in order to debug an issue then 
you would add that logger to the configuration and set the level less specific 
for that logger.  Is this a typical and reasonable approach?

I asked because we have the need for a new type of event.  To have this event 
flow to where we want it to flow the plan is to have a custom level and have 
all events at that level captured by a specific appender.  My assumption was 
that for existing applications we'd just need to add our appender to the root 
and add our custom level.  The app would need to be modified to log our new 
event at the custom level.  However, someone suggested that we could also 
create a separate logger for this event.  My thinking is that while we don't 
ever want to turn off logging of this event, loggers represent event sources, 
e.g the code raising the events and thus having multiple different pieces of 
code use the same logger wouldn't allow you to turn on/off logging from those 
different sections of code independently.  I think the current configuration 
includes all the loggers.  Normally I would expect there to be many, on the 
order of 10's or 100's, loggers within an application.  However, in the case I 
was given there were only a handful because I think this handful is shared.  So 
as I mentioned, this doesn't sound like an ideal design as you have less 
granularity on what you can turn on/off.

Thanks,
Nick
  

RE: custom levels via configuration

[Nicholas Duane]

I got log4j 2.3 installed and verified that custom levels are working for me 
now.  However, I did noticed you can't set the intValue to a negative number.  
Is that by design?

Thanks,
Nick

 From: nic...@msn.com
 To: log4j-user@logging.apache.org
 Subject: RE: custom levels via configuration
 Date: Wed, 26 Aug 2015 20:34:13 -0400
 
 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

RE: custom levels via configuration

[Nicholas Duane]

Ideally that I couldn't turn it off.
Thanks,Nick

 Original message 
From: Ralph Goers ralph.go...@dslextreme.com
Date: 08/29/2015  9:51 PM  (GMT-07:00)
To: Log4J Users List log4j-user@logging.apache.org
Subject: Re: custom levels via configuration

OFF has a value of 0. What would it mean to have a value less than that?

Ralph

 On Aug 29, 2015, at 7:22 PM, Nicholas Duane nic...@msn.com wrote:

 I got log4j 2.3 installed and verified that custom levels are working for me 
 now.  However, I did noticed you can't set the intValue to a negative number. 
  Is that by design?

 Thanks,
 Nick

 From: nic...@msn.com
 To: log4j-user@logging.apache.org
 Subject: RE: custom levels via configuration
 Date: Wed, 26 Aug 2015 20:34:13 -0400

 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

plugins

[Nicholas Duane]

I've got a couple questions regarding plugins I'm hoping someone might be able 
to help me with.  I checked the docs and it's still not quite clear.
 
1. I'm unsure what to set printObject to in my Plugin annotation.  From 
http://logging.apache.org/log4j/2.x/manual/extending.html it says:
 
Specifying the printObject attribute with a value of true indicates that a 
call to toString will format the arguments to the filter as the configuration 
is being processed.
 
which unfortunately doesn't clear things up any.  I looked at the docs for 
printObject and that doesn't say anything other than it's a Boolean and its 
default is false.
 
2. I created a LevelRangeFiler and I'm trying to figure out how to get it 
loaded by log4j.  I read over the instructions on plugins located at 
http://logging.apache.org/log4j/2.x/manual/plugins.html but since I'm a java 
noob I'm still a bit lost.  I'm wondering, if I just have a .java class which I 
compile to a .class file, can that be used?  If so, how?
 
Below is the filter I wrote based on looking at the threshold filter example at 
http://logging.apache.org/log4j/2.x/manual/extending.html.

import org.apache.logging.log4j.core.filter.AbstractFilter;
import org.apache.logging.log4j.core.Filter;
import org.apache.logging.log4j.core.config.plugins.Plugin;
import org.apache.logging.log4j.core.config.plugins.PluginAttribute;
import org.apache.logging.log4j.core.config.plugins.PluginFactory;
import org.apache.logging.log4j.Level;
import org.apache.logging.log4j.core.LogEvent;
import org.apache.logging.log4j.core.Logger;
import org.apache.logging.log4j.Marker;
import org.apache.logging.log4j.message.Message;

@Plugin(name=LevelRangeFilter, category=Core, elementType=filter,
printObject=true)
public class LevelRangeFilter extends AbstractFilter
{
private final Level minLevel;
private final Level maxLevel;

public LevelRangeFilter(Level minLevel, Level maxLevel,
Filter.Result onMatch, Filter.Result onMismatch)
{
super(onMatch, onMismatch);
this.minLevel = minLevel;
this.maxLevel = maxLevel;
}

private Result filter(Level level)
{
if (level.isMoreSpecificThan(this.minLevel) 
level.isLessSpecificThan(this.maxLevel))
{
return this.onMatch;
}
return this.onMismatch;
}

public Filter.Result filter(Logger logger, Level level,
Marker marker, String msg, Object[] params)
{
return filter(level);
}

public Filter.Result filter(Logger logger, Level level,
Marker marker, Object msg, Throwable t)
{
return filter(level);
}

public Filter.Result filter(Logger logger, Level level,
Marker marker, Message msg, Throwable t)
{
return filter(level);
}

public Filter.Result filter(LogEvent event)
{
return filter(event.getLevel());
}

@PluginFactory
public static LevelRangeFilter createFilter(
@PluginAttribute(value=minLevel,
defaultString=DEBUG) Level minLevel,
@PluginAttribute(value=maxLevel,
defaultString=FATAL) Level maxLevel,
@PluginAttribute(value=onMatch,
defaultString=NEUTRAL) Result onMatch,
@PluginAttribute(value=onMismatch,
defaultString=DENY) Result onMismatch)
{
return new LevelRangeFilter(minLevel, maxLevel, onMatch, onMismatch);
}
}

Thanks,
Nick


  

RE: plugins

[Nicholas Duane]

Based on your previous comments I assume one would show up out-of-the-box at 
some point.  Of course I need mine now so unfortunately I have to write one.
 
Any input on my questions below?
 
Thanks,
Nick
 
 Date: Thu, 27 Aug 2015 12:20:07 -0700
 Subject: Re: plugins
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 Note that I wrote such a filter, which is under review ATM here:
 
 - https://issues.apache.org/jira/browse/LOG4J2-1106
 - https://issues.apache.org/jira/browse/LOG4J2-1105
 
 Gary
 
 On Thu, Aug 27, 2015 at 11:51 AM, Nicholas Duane nic...@msn.com wrote:
 
 
 
 
  I've got a couple questions regarding plugins I'm hoping someone might be
  able to help me with.  I checked the docs and it's still not quite clear.
 
  1. I'm unsure what to set printObject to in my Plugin annotation.  From
  http://logging.apache.org/log4j/2.x/manual/extending.html it says:
 
  Specifying the printObject attribute with a value of true indicates
  that a call to toString will format the arguments to the filter as the
  configuration is being processed.
 
  which unfortunately doesn't clear things up any.  I looked at the docs for
  printObject and that doesn't say anything other than it's a Boolean and its
  default is false.
 
  2. I created a LevelRangeFiler and I'm trying to figure out how to get it
  loaded by log4j.  I read over the instructions on plugins located at
  http://logging.apache.org/log4j/2.x/manual/plugins.html but since I'm a
  java noob I'm still a bit lost.  I'm wondering, if I just have a .java
  class which I compile to a .class file, can that be used?  If so, how?
 
  Below is the filter I wrote based on looking at the threshold filter
  example at http://logging.apache.org/log4j/2.x/manual/extending.html.
 
  import org.apache.logging.log4j.core.filter.AbstractFilter;
  import org.apache.logging.log4j.core.Filter;
  import org.apache.logging.log4j.core.config.plugins.Plugin;
  import org.apache.logging.log4j.core.config.plugins.PluginAttribute;
  import org.apache.logging.log4j.core.config.plugins.PluginFactory;
  import org.apache.logging.log4j.Level;
  import org.apache.logging.log4j.core.LogEvent;
  import org.apache.logging.log4j.core.Logger;
  import org.apache.logging.log4j.Marker;
  import org.apache.logging.log4j.message.Message;
 
  @Plugin(name=LevelRangeFilter, category=Core, elementType=filter,
  printObject=true)
  public class LevelRangeFilter extends AbstractFilter
  {
  private final Level minLevel;
  private final Level maxLevel;
 
  public LevelRangeFilter(Level minLevel, Level maxLevel,
  Filter.Result onMatch, Filter.Result onMismatch)
  {
  super(onMatch, onMismatch);
  this.minLevel = minLevel;
  this.maxLevel = maxLevel;
  }
 
  private Result filter(Level level)
  {
  if (level.isMoreSpecificThan(this.minLevel) 
  level.isLessSpecificThan(this.maxLevel))
  {
  return this.onMatch;
  }
  return this.onMismatch;
  }
 
  public Filter.Result filter(Logger logger, Level level,
  Marker marker, String msg, Object[] params)
  {
  return filter(level);
  }
 
  public Filter.Result filter(Logger logger, Level level,
  Marker marker, Object msg, Throwable t)
  {
  return filter(level);
  }
 
  public Filter.Result filter(Logger logger, Level level,
  Marker marker, Message msg, Throwable t)
  {
  return filter(level);
  }
 
  public Filter.Result filter(LogEvent event)
  {
  return filter(event.getLevel());
  }
 
  @PluginFactory
  public static LevelRangeFilter createFilter(
  @PluginAttribute(value=minLevel,
  defaultString=DEBUG) Level minLevel,
  @PluginAttribute(value=maxLevel,
  defaultString=FATAL) Level maxLevel,
  @PluginAttribute(value=onMatch,
  defaultString=NEUTRAL) Result onMatch,
  @PluginAttribute(value=onMismatch,
  defaultString=DENY) Result onMismatch)
  {
  return new LevelRangeFilter(minLevel, maxLevel, onMatch, onMismatch);
  }
  }
 
  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: plugins

[Nicholas Duane]

I don't think the implementation is the issue, though if/when I get my plugin 
loading and it doesn't work I will certainly try to compare against what Gary 
wrote.  Right now I'm just trying to figure out how to get my plugin loaded.  
I've got my class file, LevelRangeFilter.java which I compiled to a .class 
file.  It resides in the same directory as my HelloWorld.class file which 
contains my main.  I was hoping my plugin would get loaded but it doesn't 
seem to be.  What's the easiest way for me to get it loaded?  Right now when I 
run my program I'm seeing the following error from log4net:
 
2015-08-27 15:23:09,682 ERROR File contains an invalid element or attribute 
LevelRangeFilter

Here is my config:

?xml version=1.0 encoding=UTF-8?
Configuration status=trace verbose=true packages=LevelRangeFilter
  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
  LevelRangeFilter minLevel=INFO maxLevel=INFO onMatch=ACCEPT/
/File
  /Appenders
  Loggers
Logger name=HelloWorld level=ALL
  AppenderRef ref=info/
/Logger
Root
/Root
  /Loggers
/Configuration

Thanks,
Nick
 
 Subject: Re: plugins
 From: ralph.go...@dslextreme.com
 Date: Thu, 27 Aug 2015 14:20:28 -0700
 To: log4j-user@logging.apache.org
 
 Can’t you just compare what you wrote to what Gary wrote?  If you build your 
 project then it should get packaged in a jar and automatically have the file 
 Log4j uses to quickly load the plugin.
 
 Ralph
 
  On Aug 27, 2015, at 12:50 PM, Nicholas Duane nic...@msn.com wrote:
  
  Based on your previous comments I assume one would show up out-of-the-box 
  at some point.  Of course I need mine now so unfortunately I have to write 
  one.
  
  Any input on my questions below?
  
  Thanks,
  Nick
  
  Date: Thu, 27 Aug 2015 12:20:07 -0700
  Subject: Re: plugins
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
  
  Note that I wrote such a filter, which is under review ATM here:
  
  - https://issues.apache.org/jira/browse/LOG4J2-1106
  - https://issues.apache.org/jira/browse/LOG4J2-1105
  
  Gary
  
  On Thu, Aug 27, 2015 at 11:51 AM, Nicholas Duane nic...@msn.com wrote:
  
  
  
  
  I've got a couple questions regarding plugins I'm hoping someone might be
  able to help me with.  I checked the docs and it's still not quite clear.
  
  1. I'm unsure what to set printObject to in my Plugin annotation.  From
  http://logging.apache.org/log4j/2.x/manual/extending.html it says:
  
  Specifying the printObject attribute with a value of true indicates
  that a call to toString will format the arguments to the filter as the
  configuration is being processed.
  
  which unfortunately doesn't clear things up any.  I looked at the docs for
  printObject and that doesn't say anything other than it's a Boolean and 
  its
  default is false.
  
  2. I created a LevelRangeFiler and I'm trying to figure out how to get it
  loaded by log4j.  I read over the instructions on plugins located at
  http://logging.apache.org/log4j/2.x/manual/plugins.html but since I'm a
  java noob I'm still a bit lost.  I'm wondering, if I just have a .java
  class which I compile to a .class file, can that be used?  If so, how?
  
  Below is the filter I wrote based on looking at the threshold filter
  example at http://logging.apache.org/log4j/2.x/manual/extending.html.
  
  import org.apache.logging.log4j.core.filter.AbstractFilter;
  import org.apache.logging.log4j.core.Filter;
  import org.apache.logging.log4j.core.config.plugins.Plugin;
  import org.apache.logging.log4j.core.config.plugins.PluginAttribute;
  import org.apache.logging.log4j.core.config.plugins.PluginFactory;
  import org.apache.logging.log4j.Level;
  import org.apache.logging.log4j.core.LogEvent;
  import org.apache.logging.log4j.core.Logger;
  import org.apache.logging.log4j.Marker;
  import org.apache.logging.log4j.message.Message;
  
  @Plugin(name=LevelRangeFilter, category=Core, elementType=filter,
 printObject=true)
  public class LevelRangeFilter extends AbstractFilter
  {
 private final Level minLevel;
 private final Level maxLevel;
  
 public LevelRangeFilter(Level minLevel, Level maxLevel,
 Filter.Result onMatch, Filter.Result onMismatch)
 {
 super(onMatch, onMismatch);
 this.minLevel = minLevel;
 this.maxLevel = maxLevel;
 }
  
 private Result filter(Level level)
 {
 if (level.isMoreSpecificThan(this.minLevel) 
 level.isLessSpecificThan(this.maxLevel))
 {
 return this.onMatch;
 }
 return this.onMismatch;
 }
  
 public Filter.Result filter(Logger logger, Level level,
 Marker marker, String msg, Object[] params)
 {
 return filter(level);
 }
  
 public Filter.Result filter(Logger logger, Level

RE: plugins

[Nicholas Duane]

Awesome, thanks.  I needed a little bit more because of my java noobness, but I 
was able to figure that out.  Looks like I needed the -d on the javac command 
so that it created the appropriate directory structure for my .class file based 
on the package name.  Then things started working!!
 
Now I can filter on just a single level with my LevelRangeFilter.
 
Thanks for all the help.  Next I have to get the latest log4j installed on 
fedora 21 so that I can verify custom levels work.
 
Nick
 
 Date: Fri, 28 Aug 2015 07:51:32 +0900
 Subject: Re: plugins
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org
 
 I think you made a mistake there: your config says
 
 Configuration status=trace verbose=true packages=LevelRangeFilter
 
 
 But your code does not have a package declaration at the top. This means it
 is in the default (nameless) package.
 Change your code to start with:
 
 package com.mycomp.pluginpackage;
 import ...
 
 And change your config to
 Configuration status=trace packages=com.mycomp.pluginpackage
 
 Using the plugin class name in the packages attribute won't work.
 
 On Friday, August 28, 2015, Nicholas Duane nic...@msn.com wrote:
 
  I tried that.  I created a jar, I think correctly, from my
  LevelRangeFilter.class file.  I added that to the packages attribute, as
  you can see in the config I previously sent.  It still doesn't work.
 
  Thanks,
  Nick
 
   Subject: Re: plugins
   From: remko.po...@gmail.com javascript:;
   Date: Fri, 28 Aug 2015 07:25:35 +0900
   To: log4j-user@logging.apache.org javascript:;
  
   Perhaps the simplest thing to do is to add the packages attribute to
  your log4j2.xml configuration file. Set the value to the package of your
  custom plugin.
  
   Configuration status=trace packages=com.mycomp.pluginpackage
   ...
  
   Remko
  
   Sent from my iPhone
  
On 2015/08/28, at 6:42, Nicholas Duane nic...@msn.com javascript:;
  wrote:
   
   
   
   
I don't think the implementation is the issue, though if/when I get my
  plugin loading and it doesn't work I will certainly try to compare against
  what Gary wrote.  Right now I'm just trying to figure out how to get my
  plugin loaded.  I've got my class file, LevelRangeFilter.java which I
  compiled to a .class file.  It resides in the same directory as my
  HelloWorld.class file which contains my main.  I was hoping my plugin
  would get loaded but it doesn't seem to be.  What's the easiest way for me
  to get it loaded?  Right now when I run my program I'm seeing the following
  error from log4net:
   
2015-08-27 15:23:09,682 ERROR File contains an invalid element or
  attribute LevelRangeFilter
   
Here is my config:
   
?xml version=1.0 encoding=UTF-8?
Configuration status=trace verbose=true
  packages=LevelRangeFilter
 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
 LevelRangeFilter minLevel=INFO maxLevel=INFO
  onMatch=ACCEPT/
   /File
 /Appenders
 Loggers
   Logger name=HelloWorld level=ALL
 AppenderRef ref=info/
   /Logger
   Root
   /Root
 /Loggers
/Configuration
   
Thanks,
Nick
   
Subject: Re: plugins
From: ralph.go...@dslextreme.com javascript:;
Date: Thu, 27 Aug 2015 14:20:28 -0700
To: log4j-user@logging.apache.org javascript:;
   
Can’t you just compare what you wrote to what Gary wrote?  If you
  build your project then it should get packaged in a jar and automatically
  have the file Log4j uses to quickly load the plugin.
   
Ralph
   
On Aug 27, 2015, at 12:50 PM, Nicholas Duane nic...@msn.com
  javascript:; wrote:
   
Based on your previous comments I assume one would show up
  out-of-the-box at some point.  Of course I need mine now so unfortunately I
  have to write one.
   
Any input on my questions below?
   
Thanks,
Nick
   
Date: Thu, 27 Aug 2015 12:20:07 -0700
Subject: Re: plugins
From: garydgreg...@gmail.com javascript:;
To: log4j-user@logging.apache.org javascript:;
   
Note that I wrote such a filter, which is under review ATM here:
   
- https://issues.apache.org/jira/browse/LOG4J2-1106
- https://issues.apache.org/jira/browse/LOG4J2-1105
   
Gary
   
On Thu, Aug 27, 2015 at 11:51 AM, Nicholas Duane nic...@msn.com
  javascript:; wrote:
   
   
   
   
I've got a couple questions regarding plugins I'm hoping someone
  might be
able to help me with.  I checked the docs and it's still not quite
  clear.
   
1. I'm unsure what to set printObject to in my Plugin annotation.
  From
http://logging.apache.org/log4j/2.x/manual/extending.html it says:
   
Specifying the printObject attribute with a value of true
  indicates
that a call to toString will format the arguments

RE: range filter?

[Nicholas Duane]

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

custom levels via configuration

[Nicholas Duane]

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

[Nicholas Duane]

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: custom levels via configuration

[Nicholas Duane]

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?

[Nicholas Duane]

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?

[Nicholas Duane]

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
 
 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

RE: redefining existing levels?

[Nicholas Duane]

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?

[Nicholas Duane]

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

RE: redefining existing levels?

[Nicholas Duane]

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?

[Nicholas Duane]

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: range filter?

[Nicholas Duane]

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?

[Nicholas Duane]

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: custom levels via configuration

[Nicholas Duane]

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

[Nicholas Duane]

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

[Nicholas Duane]

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

[Nicholas Duane]

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 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

RE: range filter?

[Nicholas Duane]

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 defined any custom levels which are maybe just 1 
 away from WARN in either direction that those don't make it in the appender. 
  How would you do that?

 

 How I did this with the log4net LevelRangeFilter was to set the levelMin and 
 levelMax to the same value.

 

 Thanks,

 Nick

 

 Subject: Re: range filter?

 From: remko.po...@gmail.com

 Date: Wed, 26 Aug 2015 09:12:29 +0900

 To: log4j-user@logging.apache.org

 

 You misread the comment. The commentor basically told me the answer works 
 with a minor change, and that he would mark the question as done if I 
 would edit my answer (which I did).  

 

 So the answer works and seems to apply to your use case, no? The question 
 is if it also works with custom levels. 

 

 Sent from my iPhone

 

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

 

 Thanks.  I checked out the link.  It seems they were trying to do 
 something similar to me.  I see the last comment on that is that it 
 doesn't work.

 

 There is another post afterwards which uses the ThresholdFilter.  However 
 the ThresholdFilter won't work as that allows, or denys, all levels 
 greater than or equal to or less than or equal to the level.  I need to 
 filter a specific range of levels.

 

 Thanks,

 Nick

 

 Date: Wed, 26 Aug 2015 08:27:04 +0900

 Subject: Re: range filter?

 From: remko.po...@gmail.com

 To: log4j-user@logging.apache.org

 

 Can you try something similar to this

 http://stackoverflow.com/questions/24695133/log4j2-filter-particular-level-in-apender/24697002#24697002

 and see if that works with custom levels as well?

 

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

 

 I've tried a couple different combinations and so far no luck.  Here's

 the current configuration I tested with which doesn't work:

 

 File ...

 PatternLayout

    ...

 /PatternLayout

 Filters

    ThresholdFilter level=INFO onMatch=DENY/

    ThresholdFilter level=DEBUG onMatch=ACCEPT/

 /Filters

 /File

 

 The

 use case for why I want such a filter is to forward a range of events

 to an appender.  The threshold filter won't work

RE: redefining existing levels?

[Nicholas Duane]

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 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

RE: redefining existing levels?

[Nicholas Duane]

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 say
  that DEBUG is set to 500, so me setting OFF to 500 and then setting the
  level on my logger to OFF should have allowed the debug events to flow to
  the log file, correct?
 
  Thanks,
  Nick
 
   Date: Tue, 25 Aug 2015 12:50:32 -0700
   Subject: Re: redefining existing levels?
   From: garydgreg...@gmail.com
   To: log4j-user@logging.apache.org
  
   Nicholas,
  
   Yes, please see
   https://logging.apache.org/log4j/2.x/manual/customloglevels.html
  
   If the documentation can be improved, please let us know how.
  
   Gary
  
   On Tue, Aug 25, 2015 at 12:42 PM, Nicholas Duane nic...@msn.com wrote:
  
Can existing log4j2 levels be redefined?  I'm able to do this in
  log4net.
I have yet to see any documentation telling me that I can do it,
  however,
there was none telling me I could do it for .NET either.  I just
  happen to
stumble upon a post which eluded to it.  Here is what I've done in a
log4net config file:
   
configuration
   .
   .
   .
   log4net
  level
 name value=Off/
 value value=4/
  level
  level
 name value=Business/
 value value=13/
  level
  .
  .
  .
   /log4net
   .
   .
   .
/configuration
   
As you can see I created my own 'Business' level.  I also redefined
  Off to
4 which happens to be the INFO level.  This makes it such that if
  they
set the level to Off they will still receive INFO and higher level
  events.
   
Can the same thing be done in log4j2?
   
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
  

range filter?

[Nicholas Duane]

I'm looking for a range filter in log4j2.  I see there is on in log4net and it 
appears there was one written by someone for log4j 1.  Just wondering if there 
is something 'out of the box' in log4j2 that will accomplish the same?  I was 
wondering whether this could be accomplished with the CompositeFilter with two 
ThresholdFilter?

Thanks,
Nick
  

redefining existing levels?

[Nicholas Duane]

Can existing log4j2 levels be redefined?  I'm able to do this in log4net.  I 
have yet to see any documentation telling me that I can do it, however, there 
was none telling me I could do it for .NET either.  I just happen to stumble 
upon a post which eluded to it.  Here is what I've done in a log4net config 
file:

configuration
   .
   .
   .
   log4net
  level
 name value=Off/
 value value=4/
  level
  level
 name value=Business/
 value value=13/
  level
  .
  .
  .
   /log4net
   .
   .
   .
/configuration

As you can see I created my own 'Business' level.  I also redefined Off to 
4 which happens to be the INFO level.  This makes it such that if they set 
the level to Off they will still receive INFO and higher level events.

Can the same thing be done in log4j2?

Thanks,
Nick
  

RE: redefining existing levels?

[Nicholas Duane]

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
  say
that DEBUG is set to 500, so me setting OFF to 500 and then setting the
level on my logger to OFF should have allowed the debug events to flow
  to
the log file, correct?
   
Thanks,
Nick
   
 Date: Tue, 25 Aug 2015 12:50:32 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org

 Nicholas,

 Yes, please see
 https://logging.apache.org/log4j/2.x/manual/customloglevels.html

 If the documentation can be improved, please let us know how.

 Gary

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

  Can existing log4j2 levels be redefined?  I'm able to do this in
log4net.
  I have yet to see any documentation telling me that I can do it,
however,
  there was none telling me I could do it for .NET either.  I just
happen to
  stumble upon a post which eluded to it.  Here is what I've done in
  a
  log4net config file:
 
  configuration
 .
 .
 .
 log4net
level
   name value=Off/
   value value=4/
level
level
   name value=Business/
   value value=13/
level
.
.
.
 /log4net
 .
 .
 .
  /configuration
 
  As you can see I created my own 'Business' level.  I also redefined
Off to
  4 which happens to be the INFO level.  This makes it such that
  if
they
  set the level to Off they will still receive INFO and higher level
events.
 
  Can the same thing be done in log4j2?
 
  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

RE: redefining existing levels?

[Nicholas Duane]

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
 say
   that DEBUG is set to 500, so me setting OFF to 500 and then
   setting the
   level on my logger to OFF should have allowed the debug events to
   flow
 to
   the log file, correct?
  
   Thanks,
   Nick
  
Date: Tue, 25 Aug 2015 12:50:32 -0700
Subject: Re: redefining existing levels?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
   
Nicholas,
   
Yes, please see
   
  https://logging.apache.org/log4j/2.x/manual/customloglevels.html
   
If the documentation can be improved, please let us know how.
   
Gary
   
On Tue, Aug 25, 2015 at 12:42 PM, Nicholas Duane 
  nic...@msn.com
   
 wrote:
   
 Can existing log4j2 levels be redefined?  I'm able to do this
   in
   log4net.
 I have yet

RE: range filter?

[Nicholas Duane]

Thanks.  I checked out the link.  It seems they were trying to do something 
similar to me.  I see the last comment on that is that it doesn't work.
 
There is another post afterwards which uses the ThresholdFilter.  However the 
ThresholdFilter won't work as that allows, or denys, all levels greater than or 
equal to or less than or equal to the level.  I need to filter a specific range 
of levels.
 
Thanks,
Nick
 
 Date: Wed, 26 Aug 2015 08:27:04 +0900
 Subject: Re: range filter?
 From: remko.po...@gmail.com
 To: log4j-user@logging.apache.org
 
 Can you try something similar to this
 http://stackoverflow.com/questions/24695133/log4j2-filter-particular-level-in-apender/24697002#24697002
 and see if that works with custom levels as well?
 
 On Wed, Aug 26, 2015 at 6:04 AM, Nicholas Duane nic...@msn.com wrote:
 
  I've tried a couple different combinations and so far no luck.  Here's
  the current configuration I tested with which doesn't work:
 
  File ...
PatternLayout
...
 /PatternLayout
 Filters
ThresholdFilter level=INFO onMatch=DENY/
ThresholdFilter level=DEBUG onMatch=ACCEPT/
 /Filters
  /File
 
  The
   use case for why I want such a filter is to forward a range of events
  to an appender.  The threshold filter won't work because it will send
  all events matching a certain level and lower to the appender.  For
  instance, 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.
 
  Thanks,
  Nick
 
   Date: Tue, 25 Aug 2015 13:17:44 -0700
   Subject: Re: range filter?
   From: garydgreg...@gmail.com
   To: log4j-user@logging.apache.org
  
   When you get it working, it sounds like it would make a nice addition to
   the FAQ with a description of your use case.
  
   Gary
  
   On Tue, Aug 25, 2015 at 1:11 PM, Ralph Goers ralph.go...@dslextreme.com
  
   wrote:
  
I believe two threshold filters inside a composite filter should should
work provided you have the onMatch and onMismatch set appropriately.
   
Ralph
   
   
 On Aug 25, 2015, at 12:36 PM, Nicholas Duane nic...@msn.com wrote:

 I'm looking for a range filter in log4j2.  I see there is on in
  log4net
and it appears there was one written by someone for log4j 1.  Just
wondering if there is something 'out of the box' in log4j2 that will
accomplish the same?  I was wondering whether this could be
  accomplished
with the CompositeFilter with two ThresholdFilter?

 Thanks,
 Nick

   
   
   
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
   
   
  
  
   --
   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: range filter?

[Nicholas Duane]

Basically I need the same functionality of the LevelRangeFilter in log4net, but 
of course in log4j2.
 
Thanks,
Nick
 
 From: nic...@msn.com
 To: log4j-user@logging.apache.org
 Subject: RE: range filter?
 Date: Tue, 25 Aug 2015 19:49:48 -0400
 
 Thanks.  I checked out the link.  It seems they were trying to do something 
 similar to me.  I see the last comment on that is that it doesn't work.
  
 There is another post afterwards which uses the ThresholdFilter.  However the 
 ThresholdFilter won't work as that allows, or denys, all levels greater than 
 or equal to or less than or equal to the level.  I need to filter a specific 
 range of levels.
  
 Thanks,
 Nick
  
  Date: Wed, 26 Aug 2015 08:27:04 +0900
  Subject: Re: range filter?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
  
  Can you try something similar to this
  http://stackoverflow.com/questions/24695133/log4j2-filter-particular-level-in-apender/24697002#24697002
  and see if that works with custom levels as well?
  
  On Wed, Aug 26, 2015 at 6:04 AM, Nicholas Duane nic...@msn.com wrote:
  
   I've tried a couple different combinations and so far no luck.  Here's
   the current configuration I tested with which doesn't work:
  
   File ...
 PatternLayout
 ...
  /PatternLayout
  Filters
 ThresholdFilter level=INFO onMatch=DENY/
 ThresholdFilter level=DEBUG onMatch=ACCEPT/
  /Filters
   /File
  
   The
use case for why I want such a filter is to forward a range of events
   to an appender.  The threshold filter won't work because it will send
   all events matching a certain level and lower to the appender.  For
   instance, 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.
  
   Thanks,
   Nick
  
Date: Tue, 25 Aug 2015 13:17:44 -0700
Subject: Re: range filter?
From: garydgreg...@gmail.com
To: log4j-user@logging.apache.org
   
When you get it working, it sounds like it would make a nice addition to
the FAQ with a description of your use case.
   
Gary
   
On Tue, Aug 25, 2015 at 1:11 PM, Ralph Goers ralph.go...@dslextreme.com
   
wrote:
   
 I believe two threshold filters inside a composite filter should 
 should
 work provided you have the onMatch and onMismatch set appropriately.

 Ralph


  On Aug 25, 2015, at 12:36 PM, Nicholas Duane nic...@msn.com wrote:
 
  I'm looking for a range filter in log4j2.  I see there is on in
   log4net
 and it appears there was one written by someone for log4j 1.  Just
 wondering if there is something 'out of the box' in log4j2 that will
 accomplish the same?  I was wondering whether this could be
   accomplished
 with the CompositeFilter with two ThresholdFilter?
 
  Thanks,
  Nick
 



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


   
   
--
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: range filter?

[Nicholas Duane]

I've tried a couple different combinations and so far no luck.  Here's 
the current configuration I tested with which doesn't work:

File ...
  PatternLayout
  ...
   /PatternLayout
   Filters
  ThresholdFilter level=INFO onMatch=DENY/
  ThresholdFilter level=DEBUG onMatch=ACCEPT/
   /Filters
/File

The
 use case for why I want such a filter is to forward a range of events 
to an appender.  The threshold filter won't work because it will send 
all events matching a certain level and lower to the appender.  For 
instance, 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.

Thanks,
Nick

 Date: Tue, 25 Aug 2015 13:17:44 -0700
 Subject: Re: range filter?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 When you get it working, it sounds like it would make a nice addition to
 the FAQ with a description of your use case.
 
 Gary
 
 On Tue, Aug 25, 2015 at 1:11 PM, Ralph Goers ralph.go...@dslextreme.com
 wrote:
 
  I believe two threshold filters inside a composite filter should should
  work provided you have the onMatch and onMismatch set appropriately.
 
  Ralph
 
 
   On Aug 25, 2015, at 12:36 PM, Nicholas Duane nic...@msn.com wrote:
  
   I'm looking for a range filter in log4j2.  I see there is on in log4net
  and it appears there was one written by someone for log4j 1.  Just
  wondering if there is something 'out of the box' in log4j2 that will
  accomplish the same?  I was wondering whether this could be accomplished
  with the CompositeFilter with two ThresholdFilter?
  
   Thanks,
   Nick
  
 
 
 
  -
  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
  For additional commands, e-mail: log4j-user-h...@logging.apache.org
 
 
 
 
 -- 
 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?

[Nicholas Duane]

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 say that DEBUG 
is set to 500, so me setting OFF to 500 and then setting the level on my logger 
to OFF should have allowed the debug events to flow to the log file, correct?

Thanks,
Nick

 Date: Tue, 25 Aug 2015 12:50:32 -0700
 Subject: Re: redefining existing levels?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 Nicholas,
 
 Yes, please see
 https://logging.apache.org/log4j/2.x/manual/customloglevels.html
 
 If the documentation can be improved, please let us know how.
 
 Gary
 
 On Tue, Aug 25, 2015 at 12:42 PM, Nicholas Duane nic...@msn.com wrote:
 
  Can existing log4j2 levels be redefined?  I'm able to do this in log4net.
  I have yet to see any documentation telling me that I can do it, however,
  there was none telling me I could do it for .NET either.  I just happen to
  stumble upon a post which eluded to it.  Here is what I've done in a
  log4net config file:
 
  configuration
 .
 .
 .
 log4net
level
   name value=Off/
   value value=4/
level
level
   name value=Business/
   value value=13/
level
.
.
.
 /log4net
 .
 .
 .
  /configuration
 
  As you can see I created my own 'Business' level.  I also redefined Off to
  4 which happens to be the INFO level.  This makes it such that if they
  set the level to Off they will still receive INFO and higher level events.
 
  Can the same thing be done in log4j2?
 
  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: range filter?

[Nicholas Duane]

By the way, let me say that I'm surprisingly delighted by the quickness of 
responses and level of interest in solving these issues.  THANK YOU.  I guess 
after posting a few messages on the log4net mailing list and getting no 
responses I wasn't too hopeful about getting responses to my log4j questions.  
I guess there is a big difference in support between the two products?
 
Thanks,
Nick
 
 Date: Tue, 25 Aug 2015 17:37:18 -0700
 Subject: Re: range filter?
 From: garydgreg...@gmail.com
 To: log4j-user@logging.apache.org
 
 Ah, yes, sorry, I had not read it in detail. It would be nice to expand the
 unit test I just committed with a more complex scenario.
 
 Could this use better docs or a FAQ entry?
 
 Gary
 
 On Tue, Aug 25, 2015 at 5:12 PM, Remko Popma remko.po...@gmail.com wrote:
 
  You misread the comment. The commentor basically told me the answer works
  with a minor change, and that he would mark the question as done if I
  would edit my answer (which I did).
 
  So the answer works and seems to apply to your use case, no? The question
  is if it also works with custom levels.
 
  Sent from my iPhone
 
   On 2015/08/26, at 8:49, Nicholas Duane nic...@msn.com wrote:
  
   Thanks.  I checked out the link.  It seems they were trying to do
  something similar to me.  I see the last comment on that is that it doesn't
  work.
  
   There is another post afterwards which uses the ThresholdFilter.
  However the ThresholdFilter won't work as that allows, or denys, all levels
  greater than or equal to or less than or equal to the level.  I need to
  filter a specific range of levels.
  
   Thanks,
   Nick
  
   Date: Wed, 26 Aug 2015 08:27:04 +0900
   Subject: Re: range filter?
   From: remko.po...@gmail.com
   To: log4j-user@logging.apache.org
  
   Can you try something similar to this
  
  http://stackoverflow.com/questions/24695133/log4j2-filter-particular-level-in-apender/24697002#24697002
   and see if that works with custom levels as well?
  
   On Wed, Aug 26, 2015 at 6:04 AM, Nicholas Duane nic...@msn.com
  wrote:
  
   I've tried a couple different combinations and so far no luck.  Here's
   the current configuration I tested with which doesn't work:
  
   File ...
PatternLayout
...
 /PatternLayout
 Filters
ThresholdFilter level=INFO onMatch=DENY/
ThresholdFilter level=DEBUG onMatch=ACCEPT/
 /Filters
   /File
  
   The
   use case for why I want such a filter is to forward a range of events
   to an appender.  The threshold filter won't work because it will send
   all events matching a certain level and lower to the appender.  For
   instance, 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.
  
   Thanks,
   Nick
  
   Date: Tue, 25 Aug 2015 13:17:44 -0700
   Subject: Re: range filter?
   From: garydgreg...@gmail.com
   To: log4j-user@logging.apache.org
  
   When you get it working, it sounds like it would make a nice addition
  to
   the FAQ with a description of your use case.
  
   Gary
  
   On Tue, Aug 25, 2015 at 1:11 PM, Ralph Goers 
  ralph.go...@dslextreme.com
  
   wrote:
  
   I believe two threshold filters inside a composite filter should
  should
   work provided you have the onMatch and onMismatch set appropriately.
  
   Ralph
  
  
   On Aug 25, 2015, at 12:36 PM, Nicholas Duane nic...@msn.com
  wrote:
  
   I'm looking for a range filter in log4j2.  I see there is on in
   log4net
   and it appears there was one written by someone for log4j 1.  Just
   wondering if there is something 'out of the box' in log4j2 that will
   accomplish the same?  I was wondering whether this could be
   accomplished
   with the CompositeFilter with two ThresholdFilter?
  
   Thanks,
   Nick
  
  
  
   -
   To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
   For additional commands, e-mail: log4j-user-h...@logging.apache.org
  
  
   --
   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
  
 
  -
  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
  For additional commands, e-mail: log4j-user-h...@logging.apache.org
 
 
 
 
 -- 
 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

RE: range filter?

[Nicholas Duane]

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 defined any custom levels which are maybe just 1 
away from WARN in either direction that those don't make it in the appender.  
How would you do that?
 
How I did this with the log4net LevelRangeFilter was to set the levelMin and 
levelMax to the same value.
 
Thanks,
Nick
 
 Subject: Re: range filter?
 From: remko.po...@gmail.com
 Date: Wed, 26 Aug 2015 09:12:29 +0900
 To: log4j-user@logging.apache.org
 
 You misread the comment. The commentor basically told me the answer works 
 with a minor change, and that he would mark the question as done if I would 
 edit my answer (which I did).  
 
 So the answer works and seems to apply to your use case, no? The question is 
 if it also works with custom levels. 
 
 Sent from my iPhone
 
  On 2015/08/26, at 8:49, Nicholas Duane nic...@msn.com wrote:
  
  Thanks.  I checked out the link.  It seems they were trying to do something 
  similar to me.  I see the last comment on that is that it doesn't work.
  
  There is another post afterwards which uses the ThresholdFilter.  However 
  the ThresholdFilter won't work as that allows, or denys, all levels greater 
  than or equal to or less than or equal to the level.  I need to filter a 
  specific range of levels.
  
  Thanks,
  Nick
  
  Date: Wed, 26 Aug 2015 08:27:04 +0900
  Subject: Re: range filter?
  From: remko.po...@gmail.com
  To: log4j-user@logging.apache.org
  
  Can you try something similar to this
  http://stackoverflow.com/questions/24695133/log4j2-filter-particular-level-in-apender/24697002#24697002
  and see if that works with custom levels as well?
  
  On Wed, Aug 26, 2015 at 6:04 AM, Nicholas Duane nic...@msn.com wrote:
  
  I've tried a couple different combinations and so far no luck.  Here's
  the current configuration I tested with which doesn't work:
  
  File ...
   PatternLayout
   ...
/PatternLayout
Filters
   ThresholdFilter level=INFO onMatch=DENY/
   ThresholdFilter level=DEBUG onMatch=ACCEPT/
/Filters
  /File
  
  The
  use case for why I want such a filter is to forward a range of events
  to an appender.  The threshold filter won't work because it will send
  all events matching a certain level and lower to the appender.  For
  instance, 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.
  
  Thanks,
  Nick
  
  Date: Tue, 25 Aug 2015 13:17:44 -0700
  Subject: Re: range filter?
  From: garydgreg...@gmail.com
  To: log4j-user@logging.apache.org
  
  When you get it working, it sounds like it would make a nice addition to
  the FAQ with a description of your use case.
  
  Gary
  
  On Tue, Aug 25, 2015 at 1:11 PM, Ralph Goers ralph.go...@dslextreme.com
  
  wrote:
  
  I believe two threshold filters inside a composite filter should should
  work provided you have the onMatch and onMismatch set appropriately.
  
  Ralph
  
  
  On Aug 25, 2015, at 12:36 PM, Nicholas Duane nic...@msn.com wrote:
  
  I'm looking for a range filter in log4j2.  I see there is on in
  log4net
  and it appears there was one written by someone for log4j 1.  Just
  wondering if there is something 'out of the box' in log4j2 that will
  accomplish the same?  I was wondering whether this could be
  accomplished
  with the CompositeFilter with two ThresholdFilter?
  
  Thanks,
  Nick
  
  
  
  -
  To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
  For additional commands, e-mail: log4j-user-h...@logging.apache.org
  
  
  --
  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