[
https://issues.apache.org/jira/browse/SOLR-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018913#comment-15018913
]
Shawn Heisey commented on SOLR-8324:
------------------------------------
If there is a legitimate reason to share loggers, then there's no reason that
the logger can't be created as it is now with the class name, but the majority
of classes could use the utility method. We wouldn't necessarily need to use
the utility for them all, but it would be a helpful pattern to use for the
general case.
Yes, devs will still have to self-enforce the use of "private static final" for
the logger objects. I don't think there's anything that can be done to require
it.
> Logger Untanglement
> -------------------
>
> Key: SOLR-8324
> URL: https://issues.apache.org/jira/browse/SOLR-8324
> Project: Solr
> Issue Type: Improvement
> Reporter: Mike Drob
> Fix For: Trunk
>
>
> I propose that we do a thorough examination of how we use loggers over the
> whole project. There are many instances of loggers being shared between
> classes that make troubleshooting difficult, and we can probably clean up
> some of the usage that has accumulated over numerous code moves and
> refactorings.
> Because this has the potential to scope wildly out of control, I would like
> to break the work down into several subtasks.
> * Loggers should be declared all three of {{private static final}} when
> possible. This both helps avoid the situations described in later bullets,
> and might provide a very minor performance improvement.
> * Distinct classes should not use loggers from other classes, unless they are
> explicitly delegated to do so.
> * Subclasses should declare their own loggers instead of relying on loggers
> from parent classes.
> * Examine if forbidden-api or some other tool(s) can help maintain this, once
> we reach a desired state.
> Each bullet might turn into one or more tasks, depending on how invasive
> individual changes become.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
