[
https://issues.apache.org/jira/browse/LOGGING-135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13557156#comment-13557156
]
Thomas Neidhart commented on LOGGING-135:
-----------------------------------------
Looking at the Log4JLogger, wouldn't it be better to always set the underlying
logger in the constructor, and change the getLogger method in a way to just
return the logger (similar to the AvalonLogger)?
The null check looks unnecessary, as it should always be set in the constructor
(its missing in the standard ctor, but could be added there too).
The only thing that comes to my mind is that at creation time, the underlying
log system may return null, but this would be odd anyway.
> Thread-safety improvements
> --------------------------
>
> Key: LOGGING-135
> URL: https://issues.apache.org/jira/browse/LOGGING-135
> Project: Commons Logging
> Issue Type: Bug
> Reporter: Sebb
>
> The LogKitLogger.logger field is not final or volatile so changes are not
> guaranteed to be published.
> This includes calls to getLogger(), so two different threads using the same
> instance can theoretically both create the logger.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
