logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mariano Gonzalez (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-998) Make org.apache.logging.log4j.core.Logger#updateConfiguration protected
Date Fri, 24 Apr 2015 14:01:38 GMT

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

Mariano Gonzalez commented on LOG4J2-998:
-----------------------------------------

Hello Ralph, thanks for your answer.

I'll try to explain my use case. This will be an oversimplification but I hope it's descriptive
enough.

Basically I'm using log4j2 as the core of the logging mechanism of the Mule ESB. The ESB works
as an application contain in which you deploy applications. So there's a "container ClassLoader"
which holds the classes of the ESB itself, and per each deployed application a child classloader
is created. Each child classloader contains the classes of resources of the applications and
the classes of the container since there's a parent-child relationship.

As per logging, you can configure logging at a container level,but also each application can
have its own logging configuration. So, there's one LoggerContext for the container and one
per each deployed application. 

The reason for the DispatchingLogger wrapper to exist, is that because an application can
create an instance of a class defined in the container classloader. If such instance logs
a message, that message has to run through the correct application's LoggerContext (or maybe
even the container one). However, if the logger happens to be defined on a static field, then
the same logger can be used by many applications and we need a way to route it through the
correct LoggerContext.

As you say, I do have a custom selector which you can look at here: https://github.com/mulesoft/mule/blob/mule-3.x/modules/launcher/src/main/java/org/mule/module/launcher/log4j2/ArtifactAwareContextSelector.java#L66-66.

Also, you're right about  contextSelector.getContext(getName(), currentClassLoader, true).getLogger(getName(),
getMessageFactory()) being an expensive operation. But the performance improvement we got
from switching from synchronous log4j 1.2 to asynchronous log4j2 was so huge that we can live
with it (check the performance charts at http://blogs.mulesoft.org/mule-3-6-asynchronous-logging/

I know that this is not the average requirements and I might be forcing the boundaries of
the framework here. If you have any suggestion on how to improve this solution I'd be more
than open to it and grateful.

> Make org.apache.logging.log4j.core.Logger#updateConfiguration protected
> -----------------------------------------------------------------------
>
>                 Key: LOG4J2-998
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-998
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.1
>            Reporter: Mariano Gonzalez
>             Fix For: 2.3
>
>
> Hello,
> I'm using log4j2 as the foundation for a centralized logging infrastructure inside an
application container. For such requirement, I need to be able to override the org.apache.logging.log4j.core.Logger#updateConfiguration
method. However, that method has package visibility and thus cannot be gracefully overriden.
> It'd be great if that method could be protected so that subclasses can redefine it. 
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message