Description
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):
...StatusLogger ...ContextSelector ...LoggerContext,ctx=%s ...LoggerConfig,ctx=%s,name=%s ...Appender,ctx=%s,name=%s ...
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:
...StatusLogger,ctx=%s ...ContextSelector,ctx=%s ...LoggerContext,ctx=%s ...LoggerConfig,ctx=%s,name=%s ...Appender,ctx=%s,name=%s ...
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).
Attachments
Issue Links
- depends upon
-
LOG4J2-529 Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
- Closed
- relates to
-
LOG4J2-578 JMX Memory Leak in Servlet Container
- Resolved
-
LOG4J2-406 JMX MBeans are not being unregistered when a tomcat web application that uses log4j is undeployed, leading to a permgen memory leak.
- Resolved
-
LOG4J2-530 JMX Client GUI should dynamically update when LoggerContext MBeans are registered/unregistered in MBean server
- Closed
-
LOG4J2-666 Ability to use a custom MBean domain
- Closed