StatusLogger isn’t meant to be a full blown logging system. It is a tool to diagnose problems in Log4j or the configuration. So my opinion is that all of these are not things to lose sleep over. To be honest I never really considered logging to anything but stdout for this stuff and letting Tomcat or whatever take care of rolling, encoding, or any other fancy stuff. I’m not sure what changes to a configuration have to do with status logging though.
Also, currently the StatusLogger is created very early - way before a configuration takes place and it doesn’t change during a reconfiguration - only the Listener could possibly be impacted. I would expect trying to hook up an Appender to a Listener is going to be very messy and full of problems. For example, you can pass an Appender the current Configuration object. I think making the status logger more complicated is just asking for trouble. Ralph On May 19, 2014, at 7:33 PM, Bruce Brouwer <bruce.brou...@gmail.com> wrote: > So, I haven't forgotten about this item. There are a number of other issues > that this current solution suffers from. Issues that other features of log4j > already solves. > > 1) If writing status logs to a file, what if I want a different encoding than > the system default? > 2) What if this log file starts to get too big and I want to roll it? > 3) What if I want these logs to go someplace completely different that the > console or a file? > 4) What if one XMLConfiguration targeting the console wants to filter on > different criteria than a previously registered XMLConfiguration? > > What if instead of providing a destination name for the status logs we > instead provided an appender name. The upsides give a lot more flexibility. > The biggest downside that I see is that it would delay (potentially > significantly) when status logs actually start showing up. The StatusLogger > will queue up these messages (up to 200 by default) until a listener is > actually attached. > > So in a normal situation, XMLConfiguration would have to wait until the > start() method is called, rather than in the constructor as it is done today, > before a user started to see any status logs showing. > > In a failure situation (e.g. some RuntimeException occurs in the > XMLConfiguration constructor), there is a good chance that we won't see those > status logs show up ever. Of course that is not acceptable. What if instead > of having StatusLogger queue up status messages, we had XMLConfiguration > queue up its own status messages. If an uncaught exception occurred in the > constructor, the caller would simply send the queued logs to a default > StatusLogger, which would sending it to System.out or System.err (maybe > configured by a property from log4j2.StatusLogger.properties). Now, we'll at > least have status logs showing up somewhere. > > The final point is preventing console messages being logged repeatedly from > multiple XMLConfiguration instances. This is probably the more invasive > change. Could we change StatusLogger to no longer be a global singleton, but > rather have a StatusLogger associated with each LoggerContext? This would > solve the problem of preventing multiple XMLConfiguration instances writing > the same message to the console multiple times. It would also solve any issue > of one XMLConfiguration wanting different filter criteria from another. We > could probably get rid of the whole notion of registering listeners as > everything has a pointer back to a LoggerContext and could therefore write > directly to the status logger referenced by the LoggerContext. > > Remember that XMLConfiguration can keep a queue of messages. Once it becomes > associated with the LoggerContext, at that point it could write its queued up > status messages to the StatusLogger. > > This isn't all 100% clear in my mind, but I wanted to get some feedback > before I spent a ton of time trying to do this. Maybe this proposal is just > too big of a change. > > > On Thu, May 1, 2014 at 10:04 AM, Bruce Brouwer (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/LOG4J2-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13986604#comment-13986604 > ] > > Bruce Brouwer commented on LOG4J2-609: > -------------------------------------- > > Ah yes, I wasn't thinking about that. I'll have to come up with a different > solution then. > > > StatusConfiguration doesn't close files > > --------------------------------------- > > > > Key: LOG4J2-609 > > URL: https://issues.apache.org/jira/browse/LOG4J2-609 > > Project: Log4j 2 > > Issue Type: Bug > > Components: Core > > Affects Versions: 2.0-rc1 > > Reporter: Bruce Brouwer > > Assignee: Ralph Goers > > Attachments: log4j2-609.patch > > > > > > {{org.apache.logging.log4j.core.config.status.StatusConfiguration}} allows > > you to specify a destination such as "out", "err" or a file name. If > > specifying a file, that file stream is used when creating a > > {{StatusConsoleListener}} that is added to the {{StatusLogger}}. Those > > {{StatusLogger}} listeners are never cleaned up when, for example, the > > {{XmlConfiguration}} is reconfigured or when the {{LoggerContext}} is shut > > down (e.g. in {{InitialLoggerContext.apply()}}). This leaves open file > > handles and is the source of the failing test {{FileOutputTest}} on Windows. > > > > -- > This message was sent by Atlassian JIRA > (v6.2#6252) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-dev-h...@logging.apache.org > > > > > -- > > > Bruce Brouwer > about.me/bruce.brouwer > >
