[jira] [Created] (LOG4J2-596) Core should consistently use the Lifecycle class and Status enum

["Matt Sicker (JIRA)" <ji...@apache.org>]

Matt Sicker created LOG4J2-596:
----------------------------------

             Summary: Core should consistently use the Lifecycle class and Status enum
                 Key: LOG4J2-596
                 URL: https://issues.apache.org/jira/browse/LOG4J2-596
             Project: Log4j 2
          Issue Type: Improvement
          Components: Core
    Affects Versions: 2.0-rc1
            Reporter: Matt Sicker


Appenders, Filters, and LoggerContext already use the LifeCycle interface, but only LoggerContext has the idea of a volatile enum for its status. I think this would be a good idiom to use throughout all the LifeCycle implementations. There are other interfaces that would make sense to use the LifeCycle interface for as well:

* Configuration (it already uses two of the three methods using the same exact signature)
* Log4jWebInitializer (although the equivalent start() method here can throw an UnavailableException, this could be changed to a RuntimeException of some sort; it's already re-wrapped in one in the ServletContextListener implementation)
* Possibly some other areas if applicable.

The bigger refactoring I think would be useful really is the status enum usage. It would make things a bit more consistent. To compare this to OSGi, it has the lifecycle states: installed, resolved, starting, active, stopping, and uninstalled. A nice diagram [can be found here|http://docs.spring.io/osgi/docs/2.0.0.M1/reference/html/images/bundle-states.png] describing the OSGi lifecycle. I think this could be a good way to implement generic lifecycle state in the relevant classes. This way, it will also make it simpler to use appenders, filters, etc., as OSGi declarative services (which doesn't require breaking everything up into bundles) which would help reduce the need for class loading hacks in OSGi.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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