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

Shawn Heisey commented on SOLR-8324:
------------------------------------

Thanks, Uwe!

I did try and use MethodHandles when Mike mentioned it, but eclipse didn't 
offer me the option to import the class when I pasted that code in, so I 
thought Java 7 didn't have the option.  Your code example included the import, 
so I pasted that into my test code first, and now it looks good.

That code is compact enough that using a copy of it in every class doesn't 
worry me.  The code using Thread and Stacktrace is quite verbose, and I get 
nervous when I see really long method chains and retrieval of specific array 
elements.  Hearing that the code is slow is another reason to avoid 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]

Reply via email to