[
https://issues.apache.org/jira/browse/LOGGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated LOGGING-95:
----------------------------------
Description: This is a feature request for the commons-logging API already
discussed on the mailing list. The idea is to have an extended interface rather
than Log that adds additional methods (getChildLogger and getName) that have
already been requested for a long while. The suggested approach does not break
compatibility of JCL. The existing Log interface is not touched and shall esp.
not be deprecated. The new interface may only be used as needed but aims to
prevent having even more additional logging APIs in future. The suggestion is
to change the implementation in a way that all classes that implement Log shall
implement Logger and fullfill the contract of the additional methods. In my
request I still leave it open what happens to LogFactory but my suggestion is
to leave it untouched (except for javadoc updates). Further I recomment to add
an abstract class to the "impl" package that implements the Logger interface
but does not implement any methods. The Logger interface may then recommend in
its javadoc to extend the abstract class rather than directly implementing the
interface. This would allow to have less trouble if -however- in future an
additional feature request for the Logger API arises. (was: This is a feature
request for the commons-logging API already discussed on the
mailing list. The idea is to have an extended interface rather than Log that
adds additional methods (getChildLogger and getName) that have already been
requested for a long while. The suggested approach does not break compatibility
of JCL. The existing Log interface is not touched and shall esp. not be
deprecated. The new interface may only be used as needed but aims to prevent
having even more additional logging APIs in future. The suggestion is to change
the implementation in a way that all classes that implement Log shall implement
Logger and fullfill the contract of the additional methods. In my request I
still leave it open what happens to LogFactory but my suggestion is to leave it
untouched (except for javadoc updates). Further I recomment to add an abstract
class to the "impl" package that implements the Logger interface but does not
implement any methods. The Logger interface may then recommend in its javadoc
to
extend the abstract class rather than directly implementing the interface. This
would allow to have less trouble if -however- in future an additional feature
request for the Logger API arises.)
> Extended API: getChildLogger(String)
> ------------------------------------
>
> Key: LOGGING-95
> URL: https://issues.apache.org/jira/browse/LOGGING-95
> Project: Commons Logging
> Issue Type: Improvement
> Environment: Operating System: other
> Platform: Other
> Reporter: Jörg Hohwiller
> Priority: Minor
> Fix For: 2.0
>
> Attachments: ASF.LICENSE.NOT.GRANTED--Logger.java,
> ASF.LICENSE.NOT.GRANTED--getChildLogger.diff
>
>
> This is a feature request for the commons-logging API already discussed on
> the mailing list. The idea is to have an extended interface rather than Log
> that adds additional methods (getChildLogger and getName) that have already
> been requested for a long while. The suggested approach does not break
> compatibility of JCL. The existing Log interface is not touched and shall
> esp. not be deprecated. The new interface may only be used as needed but aims
> to prevent having even more additional logging APIs in future. The suggestion
> is to change the implementation in a way that all classes that implement Log
> shall implement Logger and fullfill the contract of the additional methods.
> In my request I still leave it open what happens to LogFactory but my
> suggestion is to leave it untouched (except for javadoc updates). Further I
> recomment to add an abstract class to the "impl" package that implements the
> Logger interface but does not implement any methods. The Logger interface may
> then recommend in its javadoc to extend the abstract class rather than
> directly implementing the interface. This would allow to have less trouble if
> -however- in future an additional feature request for the Logger API arises.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
