[LOG4J2-596] Core should consistently use the Lifecycle class and Status enum

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Implemented
• Affects Version/s: 2.0-rc1
• Component/s: Core
• Labels: api core lifecycle
• Assignee: Gary D. Gregory
• Reporter: Matt Sicker
• Created: 06/Apr/14 15:05
• Updated: 24/May/14 03:18
• Resolved: 23/May/14 15:51

Description

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 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.

Issue Links

• relates to: LOG4J2-40 Lifecycle management should be orthogonal.
• links to: Bundle API docs
• links to: BundleEvent API docs