[
https://issues.apache.org/jira/browse/LOG4J2-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14060930#comment-14060930
]
Bruce Brouwer edited comment on LOG4J2-609 at 7/14/14 5:50 PM:
---------------------------------------------------------------
# You're right. .getStatusLevel() can remain. The important part was removing
the caching of .getStatusLevel() from StatusLogger. I put that back to the way
it was before. As for .registerListener(...), the code on the branch was
simplified beyond what is identified in this JIRA as a result of the mailing
list discussion. That is why no such parameter is added to
.registerListener(...) on the branch. It isn't necessary on
.registerListener(...) with this simplification.
# I was originally thinking that status listeners might make some decision
based on the Marker. Also, why not include the marker. Every other piece of
information from the logged message is included. I'm guessing nothing that uses
StatusLogger provides a marker so I can see your point from that perspective.
But if we decide to start doing more with StatusLogger and Markers, it is
ready. To prevent the StatusData constructor becoming part of the public API
(and possibly making it harder to add a Marker in the future) I made the
constructor package private. This will allow us to add the Marker back in later
without being considered a breaking API change. What do you think of that?
If people like this, I'm pretty happy with the way it has turned out without
being too impactful.
To recap what has actually changed:
* The StatusLogger no longer maintains a cached copy of the logger level
* StatusConsoleListener was moved to log4j-core with subclasses of
StatusStdErrListener and StatusStdOutListener which correctly track changes to
System.out and System.err
* There is no longer an option in XML or JSON configuration to direct
StatusLogger messages to a file; only System.out and/or System.err
was (Author: bruce.brouwer):
# You're right. .getStatusLevel() can remain. The important part was removing
the caching of .getStatusLevel() from StatusLogger. I put that back to the way
it was before. As for .registerListener(...), the code on the branch was
simplified beyond what is identified in this JIRA as a result of the mailing
list discussion. That is why no such parameter is added to
.registerListener(...) on the branch. It isn't necessary on
.registerListener(...) with this simplification.
# I was originally thinking that status listeners might make some decision
based on the Marker. Also, why not include the marker. Every other piece of
information from the logged message is included. I'm guessing nothing that uses
StatusLogger provides a marker so I can see your point from that perspective.
But if we decide to start doing more with StatusLogger and Markers, it is
ready. To prevent the StatusData constructor becoming part of the public API
(and possibly making it harder to add a Marker in the future) I made the
constructor package private. This will allow us to add the Marker back in later
without being considered a breaking API change. What do you think of that?
If people like this, I'm pretty happy with the way it has turned out without
being too impactful.
To recap what was mentioned on the mailing list,
* The StatusLogger no longer maintains a cached copy of the logger level
* StatusConsoleListener was moved to log4j-core with subclasses of
StatusStdErrListener and StatusStdOutListener which correctly track changes to
System.out and System.err
* There is no longer an option in XML or JSON configuration to direct
StatusLogger messages to a file; only System.out and/or System.err
> 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.unfinished.patch, 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
