-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] @Log(accessLevel) #2280
Comments
exporting your logger would presuppose that you name or categorize the logger in a way that is different from categorizing it according to class names, because, it makes no sense for code in class X to send log statements to a logger it got from elsewhere; a logger named 'class Y'. Hence, this feature makes no sense to me. When do you want to have an 'exported' logger that nevertheless should have the name of the class it is from? |
What we want to do is to be able to define a logger in a superclass and have it shared among all subclasses. While this isn't the typical use case, I feel it is perfectly valid. Part of what we're trying to achieve is, ironically, to avoid having "boilerplate" Lombok annotations. We are not "exporting" it publicly, but to subclasses. (And potentially other things in the same package). |
I really think this is a bad idea. For instance, if you configure your output to contain the line in the source code, this will result in maximum confusion if someone is later trying to find the source location of a log line. Having a static logger field will have almost no effect on initialisation performance and memory footprint, and no effect on runtime performance. Am I missing another reason why you would want this? |
@janrieke The purpose here is not to minimize runtime performance. The goal, as I said before, is to minimize “boilerplate code” in this case, a set of “boilerplate” annotations and bean properties on methods. The particular use cases here are controller and service layer classes which for our app tend to be very very small. So the real goal here is to minimize to have the code in each concrete subclass be highly focused on things that are SPECIFIC to that subclass and not things that every sibling subclass does (define loggers, etc.) |
The problem isn't your use case, @DaBlick. It's the logger's "topic". If you do want to 'export' them to your subclasses, DONT name your logger
Unfortunately, that is not really any shorter compared to:
The primary reason we even have the annotation is because having to 'copy/paste' your class's own name into the annotation (for the more common That's why I don't think this feature is a good idea. |
I checked the Wiki to see if this is a duplciate but to me, the wiki seems empty. Apologies if this is a duplicate.
Describe the Feature
I would like to be able to choose some alternative access level modifiers to
private
when I define a logger.This might be done with something like
Target Audience
While I won't claim that something other than
private
is always a best practice, I do feel like there are a few common scenarios (such as choosingprotected
in aabstract
base class) where it's quite defensible.Writing an abstract base class that provides a shared logger to subclasses
Exporting a class logger via a public getter either
public
or to other members of apackage
The text was updated successfully, but these errors were encountered: