[
https://issues.apache.org/jira/browse/LOG4J2-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-577.
------------------------------
Resolution: Not a Problem
This was able to be resolved using a simpler method.
> Refactor LoggerContext initialization/destruction code
> ------------------------------------------------------
>
> Key: LOG4J2-577
> URL: https://issues.apache.org/jira/browse/LOG4J2-577
> Project: Log4j 2
> Issue Type: Task
> Components: Configurators, Core
> Affects Versions: 2.0-rc1
> Environment: Standard JRE, servlet context, and extensible for other
> containers like OSGi
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Labels: initialization, memory-leak, refactor
>
> Currently, the code for initialization is a bit scattered due to the servlet
> context initialization being added far later than the core stuff. The
> LoggerContext initialization code needs to be refactored to allow drop-in
> implementations based on the usage context. For example, the default
> init/destroy path is based in the LoggerContextFactory a shutdown hook thread
> to stop it. The web context uses a ServletContextListener (or more
> specifically, the web initialization class) to construct and destroy the
> LoggerContext. An OSGi bundle might wish to use a BundleActivator to start
> and stop the LoggerContext. There may be other usage scenarios not covered
> such as in an EJB, etc.
> The code for selecting a context is already modular in this way via the
> ContextSelector interface. I'd like to see something similar for the starting
> and stopping of a LoggerContext. See, for example, how it's done in logback
> (or slf4j if that's where it's implemented) or other logging frameworks (if
> any alternatives really exist).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
