Log4j 2
  1. Log4j 2
  2. LOG4J2-39

Logger in rgoers/log4j2-api is too complicated.

    Details

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

      Description

      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.

        Activity

        Ralph Goers created issue -
        Ralph Goers made changes -
        Field Original Value New Value
        Description 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.
        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 made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Not A Problem [ 8 ]
        Hide
        Ralph Goers added a comment -

        No comments on this issue in a year.

        Show
        Ralph Goers added a comment - No comments on this issue in a year.
        Ralph Goers made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development