Announcement Announcement Module
Collapse
No announcement yet.
Simpler way to exlude commons-logging in Spring Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Simpler way to exlude commons-logging in Spring

    Chapter 1 of the Spring documentation, more precisely section 1.3.2.1, describes a strategy of replacing commons-logging with slf4j. The described strategy uses maven exclusions. I think a considerably simpler and more robust strategy is to declare commons-logging in the provided scope. The actual commons-logging classes would be provided by jcl-over-slf4j. This translates into the following pom file snippet:

    <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1.1</version>
    <scope>provided</scope>
    </dependency>

    <dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>jcl-over-slf4j</artifactId>
    <version>1.6.1</version>
    </dependency>

    The first dependency declaration essentially states that commons-logging will be "somehow" provided by the user's environment. The second declaration includes jcl-over-slf4j into your project. As jcl-over-slf4j is a perfect binary-compatible replacement for commons-logging, the first assertion becomes true.

    This approach covers all dependencies using commons-logging with just one declaration whereas with the explicit exclusion approach commons-logging needs to be explicitly excluded in every dependency depending on common-logging.
    Last edited by Ceki Gülcü; Nov 10th, 2010, 01:28 AM.

  • #2
    If one wants to use single logging API, and slf4j-api to be it, IMO better approach is to have commons-logging excluded from dependencies, and jcl-over-slf4j defined as runtime dependency. As a result compilation of new classes that make use of commons-logging api by mistake will fail.

    Comment


    • #3
      Declaring commons-logging in the provided scope as described above nicely solves an extremely common problem. In contrast, explicitly excluding common-logging is an error-prone and cumbersome process.

      What you are describing seems to address a different problem than the one I am trying to solve.

      Originally posted by sslavic View Post
      If one wants to use single logging API, and slf4j-api to be it, IMO better approach is to have commons-logging excluded from dependencies, and jcl-over-slf4j defined as runtime dependency. As a result compilation of new classes that make use of commons-logging api by mistake will fail.

      Comment


      • #4
        Hi Ceki. sslavic has a point here. But then you are right that it is simpler to set the scope of commons-logging to provided, rather than having to add exclusion in all library that has dependency on commons-logging.

        BTW, how come you are a junior here in spring forum. You are the famous Ceki Gülcü

        Comment


        • #5
          Yes, there's a choice here between being efficient and effective.

          Comment


          • #6
            Originally posted by sslavic View Post
            Yes, there's a choice here between being efficient and effective.
            Spring-core will probably continue to use commons-logging as its logging API. As far as I know, spring-core has not expressed an intention to use SLF4J as a logging API. So, my proposal address an existing problem not a hypothetical one.

            Comment

            Working...
            X