[
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: [email protected]
For additional commands, e-mail: [email protected]
