[
https://issues.apache.org/jira/browse/LOG4J2-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-596.
------------------------------
Resolution: Implemented
Assignee: Gary Gregory
Gary completed this recently.
> 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
> Assignee: Gary Gregory
> Labels: api, core, lifecycle
> Attachments: Proposed_lifecycle_refactor.patch,
> Proposed_lifecycle_refactor1.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
