Re: approach for defining loggers

[Mikael Ståldal]

You probably want to use INFO level for most of your business events.

I would consider INFO as the "neutral" level. Below INFO (DEBUG, TRACE)
means "can be ignored" and above INFO (WARN, ERROR, FATAL) means "attention
please!".

On Wed, Sep 2, 2015 at 12:26 AM, Nicholas Duane  wrote:

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

Re: Question about RollingFileAppender

[Remko Popma]

Jerry, 
As of now, log4j 2 does not support auto-delete on rollover. However, this is a 
commonly requested feature and is on the todo list. We just haven't gotten 
around to working on it yet. 

The relevant Jira ticket is https://issues.apache.org/jira/browse/LOG4J2-435

Remko

Sent from my iPhone

> On 2015/09/03, at 7:06, "Boyang\(Jerry\) Peng" 
>  wrote:
> 
> Hello,
> I am using RollingFileAppender to limit the number of log files.  Is there a 
> way to use the
> Default Rollover Strategy with a time %d{-MM-dd-HH-mm-ss} with a 
>  and set  max="9"/>?  How can use a time based format for the name of my log but limit 
> the number of logs to a certain number and after the limit is reached the 
> oldest log gets deleted? Is there a way to do this?
> 
> Best,
> Jerry

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

Re: FileAppender append="false" does not truncate the file on startup

[Ralph Goers]

You have both the FileAppender and RollingFileAppender writing to the same 
file. This is certainly going to cause problems. I wouldn't be surprised at all 
if Java causes them to share the same OS  File and stream objects so only one 
of the ones Java requests actually works.  If it didn't do these you would 
almost certainly end up with a corrupted output file.

Ralph

> On Sep 2, 2015, at 12:25 AM, Sharath Gururaj  wrote:
> 
> @Remko, Yes, the actual behaviour is that log4j is appending to end of
> existing file instead of truncating it.
> 
> This is happening only in the presence of another RollingFileAppender which
> sits alongside the FileAppender.
> If only the FileAppender is present, then truncation works as expected.
> 
> Please find my log4j config here
> 
> My log4j config 
> 
> And this is my output from DEBUG on configuration
> DEBUG configuration output 
> 
> If this is indeed a bug, I'd like to try and submit a patch :)
> 
> Regards
> Sharath
> 
> On Wed, Sep 2, 2015 at 10:06 AM, Ralph Goers 
> wrote:
> 
>> Can you also add status=“DEBUG” to your configuration and provide that?
>> I’d like to see what is being passed through the configuration.
>> 
>> Ralph
>> 
>>> On Sep 1, 2015, at 4:41 PM, Remko Popma  wrote:
>>> 
>>> Can you provide your full configuration? (You may want to raise a Jira
>> ticket to track this issue.)
>>> 
>>> To confirm, the actual behaviour is that log4j appends to the end of the
>> existing app.log file, is that correct?
>>> 
>>> Sent from my iPhone
>>> 
 On 2015/09/02, at 2:50, Sharath Gururaj  wrote:
 
  
 
  >>> />
 
  
 
 
 I expect app.log to be truncated on my application startup.
 
 This is not the case. It is never truncated. Please help
 
 
 Thanks
 
 Sharath
>>> 
>>> -
>>> 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
>> 
>> 


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