Log4j 2
  1. Log4j 2
  2. LOG4J2-39

Logger in rgoers/log4j2-api is too complicated.


    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not A Problem
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: API
    • Labels:


      Curt added a @doubt to Logger that states "interface so complicated indepenent implementation unlikely. Should be refactored." and in AbstractLogger "See comments on Logger, interface is so complex that unlikely to be independently implemented." LogMF/LogSF separates those concerns out of Logger.

      An API is for the convenience of the caller, not the implementor. The API has many variations of the same method for that reason. In addition, many of them exist simply to make the API perform better as varargs, while convenient, perform poorly. In addition, the observation that the interface is "so complex that it is unlikely to be independently implemented" is unfounded. Creating a new implementation requires extending AbstractLogger and implementing the log method and 8 isEnabled methods. That isn't terribly hard at all.

      While LogMF and LogSF "simplify" the Logger interface they complicate life for users of the API by requiring a wrapper API. In fact, the part that makes AbstractLogger "complicated" is that it implements all these public methods so that implementations don't have to. The formatting issues that LogMF and LogSF try to solve are delegated to the Message objects in my implementation - a solution I find much more satisfying.

      In the end, including the methods in the Logger API or in separate static wrapper methods is simply a matter of opinion.


        Ralph Goers added a comment -

        No comments on this issue in a year.

        Ralph Goers added a comment - No comments on this issue in a year.


          • Assignee:
            Ralph Goers
          • Votes:
            0 Vote for this issue
            1 Start watching this issue


            • Created: