Lombok: [FEATURE] @Log(accessLevel)

[DaBlick]

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 privatewhen I define a logger.
This might be done with something like

    @Log( accessLevel = "protected")

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 choosing protectedin a abstractbase 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 publicor to other members of a package

[rzwitserloot]

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?

[DaBlick]

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).

[janrieke]

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?

[DaBlick]

@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.)

[rzwitserloot]

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 com.foo.MyParentClass, that's the confusing bit. We COULD update lombok and allow you to do, say:

@lombok.extern.slf4j.Logger(access = AccessLevel.PROTECTED, topic="some_name_appropriate_to_cover_the_entire_concept")

Unfortunately, that is not really any shorter compared to:

protected static final Log log = LogFactory.getLog("some_name_appropriate_to_cover_the_entire_concept")

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 LogFactory.getLog(MyClass.class) variant) is sufficiently annoying to warrant a lombok solution to this problem, but that exact thing is a bad idea when you have a non-private logger.

That's why I don't think this feature is a good idea.