[
https://issues.apache.org/jira/browse/SOLR-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022696#comment-15022696
]
Yonik Seeley commented on SOLR-8330:
------------------------------------
I was coming from the POV of supporting a user/customer... i.e. "turn on DEBUG
for these loggers and give me back the output to look at."
It just didn't seem nice to have to change which loggers needed configuring
just because some minor refactors had been done.
bq. Anyways, I can avoid touching the particular outer class-logger-used
in-inner-class scenarios exemplified by TransactionLog
Actually, it just occurred to me that we don't have much choice in this case,
as normal inner classes can't have static members.
And even for static inner classes that could have their own logger, it doesn't
seem great because the settings are apparently not inherited?
http://it-demystified.blogspot.com/2014/01/log4j-logger-hierarchies-and-java.html
> Remove unintentionally shared loggers.
> --------------------------------------
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
> Issue Type: Sub-task
> Affects Versions: Trunk
> Reporter: Jason Gerlowski
> Labels: logging
> Fix For: Trunk
>
>
> As Mike Drob pointed out in Solr-8324, many loggers in Solr are
> unintentionally shared between classes. Many instances of this are caused by
> overzealous copy-paste. This can make debugging tougher, as messages appear
> to come from an incorrect location.
> As discussed in the comments on SOLR-8324, there also might be legitimate
> reasons for sharing loggers between classes. Where any ambiguity exists,
> these instances shouldn't be touched.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
