Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4J Developers List" <log4j-dev@logging.apache.org>
Date: Sat, 15 Mar 2014 14:49:42 +0000 (UTC)
From: "Bruce Brouwer (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12698650.1393947463749.76202.1394894982693@arcas>
In-Reply-To: <JIRA.12698650.1393947463749@arcas>
References: <JIRA.12698650.1393947463749@arcas>
Subject: [jira] [Commented] (LOG4J2-562) Improve ability to create custom
 extended logger
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LOG4J2-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13936206#comment-13936206 ] 

Bruce Brouwer commented on LOG4J2-562:
--------------------------------------

The one concept that this patch provided (which definitely needs some modification) that I think might have some merit is this LoggerExtension. My patch in LOG4J2-555 adds a bunch of log methods that include the FQCN. These methods end up being public, while the previous functionality was protected. Originally, some extensions of AbstractLogger switched this protected method(s) to public and others did not. If we wanted to keep as much stuff non-public as possible, then this LoggerExtension idea could be useful.

Concerning my patch in LOG4J2-555, it would mean getting rid of all the log(FQCN, ...) methods from LoggerProvider and replacing it with one method called .getExtension(), returning a LoggerExtension. LoggerExtension could then have all the .log(FQCN, ...) methods on it instead. 

If everyone is generally ok with the approach of my patch in LOG4J2-555 where there are more public .log(FQCN, ...) methods on AbstractLogger (essentially abstract methods), then this issue can be closed. I don't care about any of the other stuff presented in the patch I provided here. 

Personally, I'm totally ok with closing this issue that I reported as long as the general direction I proposed in LOG4J2-555 comes through. 

> Improve ability to create custom extended logger
> ------------------------------------------------
>
>                 Key: LOG4J2-562
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-562
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>            Reporter: Bruce Brouwer
>         Attachments: log4j2-loggerExtension.patch
>
>
> Create a LoggerExtension from the original logger which simply remembers the FQCN that will ultimately be the extension. 
> Also by doing this, we can switch a bunch of methods that ended up being public back to protected. I'm guessing they became public so extensions could call them. 
> This can simplify extensions (such as slf4j, jcl, custom extensions, logger streams) so they don't have to pass in the FQCN to that special log method on AbstractLogger anymore. Also, you don't have to wrap every extended log method with a check to see if the logging is enabled. Finally, you don't need to have any access to the MessageFactory. This even has to potential to eliminate AbstractLoggerWrapper.


--
This message was sent by Atlassian JIRA
(v6.2#6252)

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