[ 
https://issues.apache.org/jira/browse/SOLR-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018677#comment-15018677
 ] 

Mike Drob commented on SOLR-8324:
---------------------------------

Using a utility method still wouldn't enforce that the Logger is declared 
private static final, which is the bigger issue, I think.

How does it work with subclassing? I imagine that it still returns a logger for 
the base class, but I'm not 100% sure on that.

I'm currently hesitant about replacing all of the Logger declarations with a 
snippet like this because I'd like to give the benefit of the doubt to the 
existing code. There _might_ be some reason that a few classes currently share 
loggers, and I'd feel more comfortable looking at each of those in turn, rather 
than replacing everything at once.

> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to