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 [image: Bruce Brouwer on about.me] <http://about.me/bruce.brouwer>
