logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] Updated: (LOG4J2-39) Logger in rgoers/log4j2-api is too complicated.
Date Sun, 30 May 2010 07:09:36 GMT

     [ https://issues.apache.org/jira/browse/LOG4J2-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Ralph Goers updated LOG4J2-39:
------------------------------

    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.

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


> Logger in rgoers/log4j2-api is too complicated.
> -----------------------------------------------
>
>                 Key: LOG4J2-39
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-39
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>            Reporter: Ralph Goers
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message