Shale
  1. Shale
  2. SHALE-281

Eliminate direct dependencies on Commons Logging

    Details

      Description

      Since we depend on JDK 1.4 or later anyway, and since the logging requirements of the framework itself are minial, update the framework classes from dependency on Commons Logging to use JDK 1.4 logging instead. This does not necessarily need to apply to example applications. The focus is on minimizing dependencies for the framework itself.

        Activity

        Hide
        Ed Burns added a comment -

        I would really like to see this dependency removed.

        Show
        Ed Burns added a comment - I would really like to see this dependency removed.
        Hide
        Craig McClanahan added a comment -

        Thank you for the suggestion, Andres ... but as far as I can tell, the approach POI takes will have the same problem as the one I identified if you actually do route your log messages through the CommonsLogger implementation of POILogger.

        The adapter approach works fine for actually getting the logging output piped through, and you can indeed make Commons Logging not required if you're really using JDK 1.4 logging instead. The problem, though, is in how the logging systems display the name of the class and method from which the message was logged – they go up one level on the call stack, and extract the class and method names from that. The problem is, when you use an adapter, that all messages appear to come from the log() method of the adapter class, not from the method that called the adapter. To get the display right, we'd need to teach the logging implementation to go one level further up the call stack than it normally would.

        For the purposes that the POI website claims you would ever use logging in POI (just for debugging POI itself, not for production tracing) this is probably not a big deal ... you're probably staring directly at the source code, or using the system out logger (which doesn't do this at all) anyway. It matters more for a webapp where you want the INFO and WARN type messages to be logged to the same place as all the other messages from your webapp, with correct descriptions of where the logged messages come from.

        Show
        Craig McClanahan added a comment - Thank you for the suggestion, Andres ... but as far as I can tell, the approach POI takes will have the same problem as the one I identified if you actually do route your log messages through the CommonsLogger implementation of POILogger. The adapter approach works fine for actually getting the logging output piped through, and you can indeed make Commons Logging not required if you're really using JDK 1.4 logging instead. The problem, though, is in how the logging systems display the name of the class and method from which the message was logged – they go up one level on the call stack, and extract the class and method names from that. The problem is, when you use an adapter, that all messages appear to come from the log() method of the adapter class, not from the method that called the adapter. To get the display right, we'd need to teach the logging implementation to go one level further up the call stack than it normally would. For the purposes that the POI website claims you would ever use logging in POI (just for debugging POI itself, not for production tracing) this is probably not a big deal ... you're probably staring directly at the source code, or using the system out logger (which doesn't do this at all) anyway. It matters more for a webapp where you want the INFO and WARN type messages to be logged to the same place as all the other messages from your webapp, with correct descriptions of where the logged messages come from.
        Hide
        Andres Almiray added a comment -

        Craig, perhaps the approach taken by POI Utils logging will help.
        http://jakarta.apache.org/poi/utils/logging.html

        Show
        Andres Almiray added a comment - Craig, perhaps the approach taken by POI Utils logging will help. http://jakarta.apache.org/poi/utils/logging.html
        Hide
        Craig McClanahan added a comment -

        Alas, an attempted workaround for this that I tried with Shale Remoting, with the goal to make the Commons Logging dependency optional, is not going to work out easily. It's not problem to create an adapter class that uses either Commons Logging or JDK Logging, depending on whether C-L is present. The problem is that the presence of this adapter class messes up the way that both logging environments determine the name of the calling class and method. Both of them go up only one level on the stack, where the presence of the adapter class would want them to go up two levels.

        I do not see any current way to break the required dependency on C-L without biting the bullet and switching to JDK logging unconditionally.

        Show
        Craig McClanahan added a comment - Alas, an attempted workaround for this that I tried with Shale Remoting, with the goal to make the Commons Logging dependency optional, is not going to work out easily. It's not problem to create an adapter class that uses either Commons Logging or JDK Logging, depending on whether C-L is present. The problem is that the presence of this adapter class messes up the way that both logging environments determine the name of the calling class and method. Both of them go up only one level on the stack, where the presence of the adapter class would want them to go up two levels. I do not see any current way to break the required dependency on C-L without biting the bullet and switching to JDK logging unconditionally.

          People

          • Assignee:
            Unassigned
            Reporter:
            Craig McClanahan
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development