You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2020/11/16 22:14:00 UTC

[jira] [Commented] (SOLR-15005) RequestHandlerBase's logger name should point to the implementation class

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

Chris M. Hostetter commented on SOLR-15005:
-------------------------------------------

I'm not sure i really follow the rationale/suggestion being made here ... even after reading hte recent comment in SOLR-8330.

In my personal opinion: If I'm reading a log message, i would much rather know the *code* that's logging the message, then what particular subclass that called  the method that ran that code ... it does not make sense to me that the same block of code in RequestHandlerBase might use one Logger when subclassed by SearchHandler, and a differnet Logger when subclassed by UpdateRequestHandler.

In general, the suggestion that if {{Foo extends Bar}} means that any code path through _an instance of Foo_ should use Foo's logger -- even inside a method implemented in Bar that Foo inherits -- seems just as weird to me as suggesting that if my Foo instance calls out to some static method in YakUtils, that the YakUtils method should (somehow) also use my Foo logger.  For that matter: what logger should be used if an _instance_ of Foo calls a static method in Bar?  what if a _static_ method in Foo calls a static method in Bar? ... all of these permutations make me very very scared of how confusing it would be if _soemtimes_ code in Bar used it's own logger, but other times it used some other caller specific logger.

Going back to the specific context of this jira: If you care _which_ handler is logging that message, then changing the Logger used based on the class doesn't really help you anyway -- there can/will be many isntances of SearchHandler -- this is what MDC values are for, and we could (should?) certainly put the "name" of the heandler (ie: {{/update}} vs {{/select}} vs {{/query}} in the MDC context for logging if folks find that useful.  Allthough i would suggest that at a certain point, instead of putting tons of info in the MDC, it makes sense to keep the MDC small, and mainly focus on having a UUID logged that can be used to corrolate different log entries (i think not too long back jason added a UUID that was included for distributed request tracing, but IDK if it's part of the MDC as well)



> RequestHandlerBase's logger name should point to the implementation class
> -------------------------------------------------------------------------
>
>                 Key: SOLR-15005
>                 URL: https://issues.apache.org/jira/browse/SOLR-15005
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: logging
>            Reporter: David Smiley
>            Priority: Minor
>
> RequestHandlerBase is an abstract class that defines a private static Logger with a logger name of this very class.  I think it should point to the implementing class (getClass()).  This would require it be non-static.  It's used in just one spot, from a method that isn't static, so this will work.
> Do we go farther and declare as protected and remove static loggers in all subclasses, so long as they aren't being referenced from static methods there?
> See recent comments at the end of SOLR-8330



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org