[
https://issues.apache.org/jira/browse/LOGGING-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated LOGGING-95:
----------------------------------
Summary: Extended API: getChildLogger(String) (was: [logging] extended
API: getChildLogger(String))
> 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)
