Announcement Announcement Module
Collapse
No announcement yet.
Spring Logging Beginner Question Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Logging Beginner Question

    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:

    Code:
    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...

  • #2
    Originally posted by immortal_hero View Post
    ...

    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?



    Originally posted by immortal_hero View Post
    ...

    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;

    Comment


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

      Comment


      • #4
        Originally posted by immortal_hero View Post
        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.

        Comment


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

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

          Comment


          • #6
            Originally posted by immortal_hero View Post
            So all application logs should be written with Log4J or Log4J via SLF4J.
            Yes


            Originally posted by immortal_hero View Post
            And what about Hibernate?
            You can check that from the hibernate documentation easily.


            Originally posted by immortal_hero View Post
            Can it log w/o commons logging?
            Afair no, it is statically linked to the commons-logging as well.

            Comment


            • #7
              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.
              Originally posted by denis.zhdanov View Post
              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.

              Comment


              • #8
                Originally posted by al0 View Post
                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?

                Comment


                • #9
                  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

                  Originally posted by denis.zhdanov View Post
                  Any references, comparison docs?

                  Comment


                  • #10
                    Originally posted by al0 View Post
                    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...

                    Originally posted by al0 View Post
                    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?


                    Originally posted by al0 View Post
                    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.

                    Comment


                    • #11
                      Directly from SLF4J homepage "In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time of each binding."

                      Sure, it does not mean that you need to rempile your application - but you need to replace slf4j implementation jar with different one. Not a big tragedy, but anyway somewhat less flexible then completely dynamic binding.

                      Any may notice I do not try to say which of 2 (SLF4J or JCL) is better and should be used. I just say that both have their pro and cons which should be weighed in each case individually. Especially as it is not very complicated migrate back and force, see http://www.slf4j.org/legacy.html#jcl-over-slf4j

                      Regards,
                      Oleksandr
                      Originally posted by bdangubic View Post
                      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...



                      what flexibility are we giving up?




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

                      Comment


                      • #12
                        Originally posted by al0 View Post
                        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.

                        ...
                        I'm afraid I was not clear enough at the question formulating. It's quite clear that dynamic log system linking gives more flexibility (however, I don't see a real-world situation when dynamic logging implementation discovery is more preferable than the static linking).

                        I posted the link to the description of exact problems that may occur during JCL usage. You said that 'latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them)'. I don't see a possibility to have a protection for the mentioned problems on a framework level due to dynamic framework nature. So, are there any references about that?

                        Comment


                        • #13
                          If I remember properly, along with dynamic discovery you may specify which system to use via configuration settings.
                          And as for problems - even link that you posted contatins remarks like "this problem is fixed in 1.0.4" and "that is fixed in 1.0.5". And well you may take a look on JCL release notes for versions 1.1 and 1.1.1 as well as at following link http://wiki.apache.org/commons/Commons_Logging_FUD

                          Regards,
                          Oleksandr

                          Originally posted by denis.zhdanov View Post
                          I'm afraid I was not clear enough at the question formulating. It's quite clear that dynamic log system linking gives more flexibility (however, I don't see a real-world situation when dynamic logging implementation discovery is more preferable than the static linking).

                          I posted the link to the description of exact problems that may occur during JCL usage. You said that 'latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them)'. I don't see a possibility to have a protection for the mentioned problems on a framework level due to dynamic framework nature. So, are there any references about that?

                          Comment


                          • #14
                            Originally posted by al0 View Post
                            And as for problems - even link that you posted contatins remarks like "this problem is fixed in 1.0.4" and "that is fixed in 1.0.5".
                            There are no such statements at the document I referenced.


                            Originally posted by al0 View Post
                            And well you may take a look on JCL release notes for versions 1.1 and 1.1.1 as well as at following link http://wiki.apache.org/commons/Commons_Logging_FUD

                            Regards,
                            Oleksandr

                            Rather interesting link, thanks. However, I disagree with the JCL purpose stated there:
                            If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you.
                            That obeys 'tiny module' to reference JCL, hence, obeys module clients to include the JCL binaries to the application distribution. I don't see any benefit in comparison with SLF4J usage then.

                            Comment


                            • #15
                              Originally posted by denis.zhdanov View Post
                              There are no such statements at the document I referenced.
                              Sure? One example
                              This limitation will be addressed in JCL version 1.0.5 ....
                              Rather interesting link, thanks. However, I disagree with the JCL purpose stated there:
                              Up to you.

                              Comment

                              Working...
                              X