Menu
I'm the only maintainer on a codebase where logging is done using Apache commons logging.
All classes contains these two imports:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
Then a lot of classes contains non static log instantiation like this:
/** The log. */
private Log log = LogFactory.getLog(Xyz.class);
Can this be justified?
Can I safely change all these to static calls?
EDIT Regarding the special cases where it can (apparently) be handy: my question is really more "Can non static log all over the codebase be justified?"
696
Thus, When you are creating a logger for a singleton, you don't need to make it static. Because there will be only one instance thus one logger. On the other hand, if you are creating a logger for a model or entity class, you should make it static not to create duplicated loggers.
Non-static method: Any method whose definition doesn’t contain the static keyword is a non-static method. In the non-static method, the method can access static data members and static methods as well as non-static members and method of another class or same class, also can change the values of any static data member.
I.e. jcabi-log impedes the "high-performance" aspect of high-performance loggers. static means that you only create one Logger per class, not one logger per instance of your class. Generally, this is what you want - as the loggers tend to vary solely based on class. final means that you're not going to change the value of the logger variable.
The final comes from the point that you normally don't change the Logger during the execution -- so once initialized you never "re-configured" it -- in which case it makes sense to make it final to ensure no one can change it (by mistake or otherwise).
It depends. This is from the documentation:
Note that for application code, declaring the log member as "static" is more efficient as one Log object is created per class, and is recommended. However this is not safe to do for a class which may be deployed via a "shared" classloader in a servlet or j2ee container or similar environment. If the class may end up invoked with different thread-context-classloader values set then the member must not be declared static. The use of "static" should therefore be avoided in code within any "library" type project.
102
You have to be extra careful with having non-static loggers initialised the way your code snippet is doing in Serializable classes.
Firstly because Log isn't serializable, so any attempt of serializing your class will fail too. If you declare your logger transient then, as is the logical thing to do, your log field will not be initialised after deserialization, so you'll get an NPE while trying to log stuff. Not a very nice situation.
So to sum it up, you can have non-static loggers if you prefer, but make sure they are initialised before you use them. But apart from that, I wouldn't worry much about non-static loggers, most logging implementations will always return the same logger object anyway (log4j definitely does).
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
