Spring Logging Beginner Question

[immortal_hero]

I am using Commons Logging over Log4J for logging. I have noticed that I get a logger by default (with out instantiating one). So in any class in Spring I can use logger.[level](). Commons Logging's documentation suggests that I get the log as a private class variable in every class such as:

public class Bob {
     private Log logger = LogFactory.getLog(this.getClass);
     ...
}

I understand that this will retrieve the Log instance for the current class and if there is not an instance of a Log for the class it will be created. Also I understand that there is then a Log instance for every class that is run in my app.

My question is: If I use logger.[level]() without first getting the Log object from the LogFactory what happens? Do I have one instance of the Log class for the entire app? Do I get a new one every time the class is run? Does something else happen?

My next question is which is best practice? Explicitly get a Log class from the factory for each class in my app that needs to log or use use the logger provided?

Thanks in advance...

[denis.zhdanov]

...

My question is: If I use logger.[level]() without first getting the Log object from the LogFactory what happens? Do I have one instance of the Log class for the entire app? Do I get a new one every time the class is run? Does something else happen?
...

What does that mean? You call logging method on a logger object and say that you 'don't get the Log object from the LogFactory'. How do you get the Logger reference then?

...

My next question is which is best practice? Explicitly get a Log class from the factory for each class in my app that needs to log or use use the logger provided?

Thanks in advance...

1. You may create a single logger per class, i.e. declare it as a static variable because logger factory returns the same logger object for subsequent logger retrieval calls with the same class as the argument;
2. I'd recommend avoid using commons-logging. You can read about various sneaky problems with it here - Taxonomy of class loader problems encountered when using Jakarta Commons Logging. You can use a 'raw' log4j logging or SLF4J that links necessary logging implementation statically;

[immortal_hero]

How do I configure Spring to log its messages with Log4J instead of commons logging?

[denis.zhdanov]

How do I configure Spring to log its messages with Log4J instead of commons logging?

You can't do so without spring source code modifying because it's statically linked to the commons-logging classes.

I really don't understand why Spring Source haven't switched the code to the slf4j from the commons-logging.

[immortal_hero]

So all application logs should be written with Log4J or Log4J via SLF4J.

And what about Hibernate? Can it log w/o commons logging?

[denis.zhdanov]

So all application logs should be written with Log4J or Log4J via SLF4J.

Yes

And what about Hibernate?

You can check that from the hibernate documentation easily.

Can it log w/o commons logging?

Afair no, it is statically linked to the commons-logging as well.

[al0]

Because latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them) and allow more flexibility then SLF4J.

You can't do so without spring source code modifying because it's statically linked to the commons-logging classes.

I really don't understand why Spring Source haven't switched the code to the slf4j from the commons-logging.

[denis.zhdanov]

Because latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them) and allow more flexibility then SLF4J.

Any references, comparison docs?

[al0]

No references is required here - JCL gives more flexibility due its nature - as it bind itself to specific logging API dynamically while SLF does it statically, at compilation time. As usually drawbacks are continuation of advantages. SLF win in robustness, especially in complex environments, by giving up some flexibility.
Then everybody may decide for itself what is more important to him.

Myself have not encountered any problems with JCL (which does not mean that they do not exist at all).

Anyway SFL provides jcl-over-slf4j.jar that supposed to be drop-in replacement for commons-logging.jar (have not tested it myself).

As for Hibernate - latest versions (3.3.x) uses has parted with JCL and uses SLF instead.

Regards,
Oleksandr

Any references, comparison docs?

[bdangubic]

No references is required here - JCL gives more flexibility due its nature - as it bind itself to specific logging API dynamically while SLF does it statically, at compilation time.

explain this please. of course SLF4J does not bind itself to a desired logging system a compilation time but at deployment time. not sure what you mean by compilation time binding but that would be very useless to have to re-compile app to switch logging system...

As usually drawbacks are continuation of advantages. SLF win in robustness, especially in complex environments, by giving up some flexibility.

what flexibility are we giving up?

Myself have not encountered any problems with JCL (which does not mean that they do not exist at all).

JCL issues are clear and documented and one of the main reasons for SLF4J existence.