[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-dev
Subject:    [jira] [Commented] (LOG4J2-500) Unloading one webapp unloads JMX MBeans for all webapps
From:       "Nick Williams (JIRA)" <jira () apache ! org>
Date:       2014-01-31 19:08:11
Message-ID: JIRA.12688506.1389600539023.18834.1391195291134 () arcas
[Download RAW message or body]


    [ 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, LoggerContext).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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


[prev in list] [next in list] [prev in thread] [next in thread]