[
https://issues.apache.org/jira/browse/LOG4J2-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13976311#comment-13976311
]
Matt Sicker commented on LOG4J2-609:
------------------------------------
You raise a good point. StatusLogger is a global logger used only within log4j.
What would be the expected behaviour when you have multiple LoggerContexts that
have different configurations for StatusLogger? Maybe each LoggerContext should
have its own StatusListener like you're suggesting.
In regards to the PrintStream, I think that due to how unlikely that is to be
changed, perhaps it could become non-final with a ReadWriteLock on it? I'm not
sure how expensive all that locking and unlocking would be compared to making
it volatile (or if that's even an issue in this case). Then again, if you want
to change the PrintStream being used, you could always add a new
StatusConsoleListener and remove the old one.
> 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
>
> {{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
