logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Gregory (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-596) Core should consistently use the Lifecycle class and Status enum
Date Sat, 24 May 2014 03:20:01 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007984#comment-14007984

Gary Gregory commented on LOG4J2-596:

I believe there are more opportunities for life cycles.

Perhaps org.apache.logging.log4j.core.appender.rolling.action.Action?

Also, this issue should be marked for 2.0-rc2.

> 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

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

View raw message