[
https://issues.apache.org/jira/browse/SOLR-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030688#comment-15030688
]
Jason Gerlowski commented on SOLR-8330:
---------------------------------------
Upon slightly closer inspection, the two interfaces that contain loggers
({{SolrCache}} and {{SolrEventListener}}) aren't actually used anywhere. So
they could/should be deleted.
With that in mind, do we even want to allow interfaces to have loggers for now?
There's a solid rationale when we move to Java8, sure. But I'd argue that
until then, interface-loggers shouldn't be encouraged/allowed. Changing the
source-check to allow loggers in interfaces could be part of the move-to-Java8
effort (as long as we can make sure this doesn't get lost when the move
actually happens...that's my main qualm).
> Restrict logger visibility throughout the codebase to private so that only
> the file that declares it can use it
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8330
> URL: https://issues.apache.org/jira/browse/SOLR-8330
> Project: Solr
> Issue Type: Sub-task
> Affects Versions: Trunk
> Reporter: Jason Gerlowski
> Assignee: Anshum Gupta
> Labels: logging
> Fix For: Trunk
>
> Attachments: SOLR-8330-detector.patch, SOLR-8330-detector.patch,
> SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch, SOLR-8330.patch,
> SOLR-8330.patch
>
>
> 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]
