[
https://issues.apache.org/jira/browse/SOLR-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15018480#comment-15018480
]
Shawn Heisey commented on SOLR-8324:
------------------------------------
Regarding task #2, making loggers private is one aspect of not using loggers
from other classes, but I don't think there's any way to prevent one class from
creating a logger within itself that is tied to another class. This discussion
leads into something I've been trying to do for a while: Declare a logger with
identical code in every class.
This code works, but creates a logger for each instance of the class, which is
less than ideal, especially for very large installs:
{code:java}
private final Logger log = LoggerFactory.getLogger(this.getClass());
{code}
Every idea I've come up with for creating a static logger without needing the
class name has failed.
> 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]