logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-500) Unloading one webapp unloads JMX MBeans for all webapps
Date Fri, 31 Jan 2014 19:08:11 GMT

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

Nick Williams commented on LOG4J2-500:

It can be both.

If a web application has the Log4j libraries in its {{/WEB-INF/lib}} directory, it ALWAYS
has its own {{StatusLogger}} class that is not the same as the {{StatusLogger}} class of any
application or the container. This is true even if the container also provides Log4j libraries.
However, if the container provides Log4j libraries and the application DOES NOT, then an application
would share the container's {{StatusLogger}} class.

So with all that said, the most complex scenario imaginable is that the container provides
the Log4j libraries, multiple applications are deployed, and some of those applications provide
their own Log4j libraries while others don't. In this case, there will be multiple {{StatusLogger}}
classes, but not necessarily as many as there are applications using Log4j. Fun, huh?

So, in short, the GUI _does_ need to show separate text areas for each StatusLogger.

> Unloading one webapp unloads JMX MBeans for all webapps
> -------------------------------------------------------
>                 Key: LOG4J2-500
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-500
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 2.0-rc1
>            Reporter: Remko Popma
>            Assignee: Remko Popma
> As a stopgap solution for LOG4J2-406, all MBeans are unregistered when a LoggerContext
is stopped. 
> In an application server, multiple web applications can be deployed and undeployed independently
and a better solution would only unregister the MBeans associated with the web application
that is being undeployed.
> Current MBean ObjectNames look like this (simplified):
> {code}
> ...StatusLogger
> ...ContextSelector
> ...LoggerContext,ctx=%s
> ...LoggerConfig,ctx=%s,name=%s
> ...Appender,ctx=%s,name=%s
> ...
> {code}
> Assuming that every web application has a unique name, and this name becomes the name
of the LoggerContext, then one solution would be to create StatusLogger and ContextSelector
MBeans that have the LoggerContext name in their ObjectName:
> {code}
> ...StatusLogger,ctx=%s
> ...ContextSelector,ctx=%s
> ...LoggerContext,ctx=%s
> ...LoggerConfig,ctx=%s,name=%s
> ...Appender,ctx=%s,name=%s
> ...
> {code}
> This way, every web application would have its own StatusLogger and ContextSelector MBeans.
The MBeans may point to the same (shared) underlying StatusLogger and ContextSelector objects.
When a web application is undeployed, unregistering all MBeans associated with the LoggerContext
will not affect any MBeans associated with another web application (which has it own, separate,

This message was sent by Atlassian JIRA

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

View raw message