Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Wed, 20 Feb 2013 09:15:12 +0000 (UTC)
From: "Thomas Neidhart (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12342443.1123397113000.309615.1361351712582@arcas>
In-Reply-To: <JIRA.12342443.1123397113000@arcas>
References: <JIRA.12342443.1123397113000@arcas>
Subject: [jira] [Updated] (LOGGING-95) [logging] extended API:
 getChildLogger(String)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/LOGGING-95?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Neidhart updated LOGGING-95:
-----------------------------------

    Fix Version/s: 2.0
   =20
> [logging] 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=C3=B6rg Hohwiller
>            Priority: Minor
>             Fix For: 2.0
>
>         Attachments: ASF.LICENSE.NOT.GRANTED--getChildLogger.diff, ASF.LI=
CENSE.NOT.GRANTED--Logger.java
>
>
> This is a feature request for the commons-logging API already discussed o=
n the
> mailing list. The idea is to have an extended interface rather than Log t=
hat
> adds additional methods (getChildLogger and getName) that have already be=
en
> requested for a long while. The suggested approach does not break compati=
bility
> 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 prev=
ent
> 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 imp=
lement
> 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 le=
ave it
> untouched (except for javadoc updates). Further I recomment to add an abs=
tract
> class to the "impl" package that implements the Logger interface but does=
 not
> implement any methods. The Logger interface may then recommend in its jav=
adoc to=20
> extend the abstract class rather than directly implementing the interface=
. This
> would allow to have less trouble if -however- in future an additional fea=
ture
> request for the Logger API arises.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs
For more information on JIRA, see: http://www.atlassian.com/software/jira