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: Fri, 31 Jan 2014 19:08:11 +0000 (UTC)
From: "Nick Williams (JIRA)" <jira@apache.org>
To: log4j-dev@logging.apache.org
Message-ID: <JIRA.12688506.1389600539023.18834.1391195291134@arcas>
In-Reply-To: <JIRA.12688506.1389600539023@arcas>
References: <JIRA.12688506.1389600539023@arcas>
Subject: [jira] [Commented] (LOG4J2-500) Unloading one webapp unloads JMX
 MBeans for all webapps
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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