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: Mon, 28 Jan 2013 14:47:13 +0000 (UTC)
From: "Remko Popma (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12627569.1358215243877.200976.1359384433214@arcas>
In-Reply-To: <JIRA.12627569.1358215243877@arcas>
References: <JIRA.12627569.1358215243877@arcas>
Subject: [jira] [Updated] (LOG4J2-151) Please facilitate subclassing Logger
 and LoggerContext (in org.apache.logging.log4j.core)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Remko Popma updated LOG4J2-151:
-------------------------------

    Attachment: LOG4J2-151-patch-LoggerContext.txt
                LOG4J2-151-patch-Logger.txt

attached patches are based on trunk.
                
> Please facilitate subclassing Logger and LoggerContext (in org.apache.logging.log4j.core)
> -----------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-151
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-151
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 2.0-beta3
>            Reporter: Remko Popma
>         Attachments: FastLog4j.zip, LOG4J2-151-patch-LoggerContext.txt, LOG4J2-151-patch-Logger.txt
>
>
> I would like to create a custom logger, while reusing the org.apache.logging.log4j.core.Logger functionality.
> The following two changes would make subclassing possible:
> * change visibility of method Logger$PrivateConfig#logEvent(LogEvent) (line 265) from protected to public
> * change visibility of method LoggerContext#newInstance(LoggerContext, String) (line 310) from private to protected
> My use case is that I want to create an asynchronous Logger for low latency logging.
> This custom logger hands off control to a separate thread as early as possible. In my case, AsynchAppender is not a good match for my requirements, as with that approach (a) the logging call still needs to flow down the hierarchy to the appender, doing synchronization and creating objects at various points on the way, and (b) when serializing the LogEvent, the getSource() method is always called, which is expensive.

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

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