This Nuun plugin provides an easy way to inject SLF4J loggers, or to create your own logger annotation.
Add the dependency to your pom.xml:
<dependency>
<groupId>io.nuun</groupId>
<artifactId>nuun-log-plugin</artifactId>
<version>1.0.M2-SNAPSHOT</version>
</dependency>
Then, directly use it in your project.
public class MyClass {
@NuunLog
private Logger logger;
...
}
Our if you are building a framework and you don't want your user to directly dependend on Nuun API, you can create your own logger annotation as follows:
@Scope
@Documented
@Retention(RUNTIME)
@Target({FIELD})
@NuunLog
public @interface AnnoCustomLog {
}
This annotation can now be used in the same way as the NuunLog
annotation.
public class MyClass {
@AnnoCustomLog
private Logger logger;
...
}
There is no global response. SLF4J doesn't recommand any of the solution.
We used to recommend that loggers members be declared as instance variables instead of static. After further analysis, we no longer recommend one approach over the other.
If you want more detail about when use static field or instance field see the SLF4J documentation on the subject.
Here is the pros and cons of using instance over static field (Taken from the above page).
Possible to take advantage of repository selectors even for libraries shared between applications. However, repository selectors only work if the underlying logging system is logback-classic. Repository selectors do not work for the SLF4J+log4j combination. IOC-friendly
Less common idiom than declaring loggers as static variables higher CPU overhead: loggers are retrieved and assigned for each instance of the hosting class higher memory overhead: logger declaration will consume one reference per instance of the hosting class