logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject activateOptions pattern not desirable
Date Fri, 18 Feb 2005 18:03:03 GMT
I obviously haven't reviewed your last commit, but you did appear to 
tweak with activateOptions in a few classes and mention appender 
lifecycle which brought the topic to mind.

A very common pattern in log4j is to have a class that operates in a 
configuration mode early in its lifetime and then after a call to 
activate or activateOptions is ready for use.  Unfortunately this 
pattern implies objects that are not inherently immutable.  See 
"Effective Java", item 13 for the benefits of immutable classes.  Since 
the objects using the activateOptions pattern are subject to change 
early in the object's lifetime, it is only developer etiquette and 
self-preservation that enforces the object does not change during use.  
It would be better (in a perfect world) if distinct objects were used 
for the mutable configuration and immutable run-time behavior.

I don't have a path forward to move to greater use of immutable objects 
in log4j.  However, I think it should be seriously considered on any 
substantial rework.  When I finally get to my long standing date with 
LoggingEvent, it is likely to come out immutable.

When looking at appenders that change state over time, such as a 
database appender that can go into a failsafe mode if it can't connect, 
it would be preferable that these modes be represented by distinct 
immutable objects.  So you would have an object that forever 
represented a working database and an object that forever represented 
the failover mode and the failover transition was accomplished by 
switching these objects out instead of changing an object that has 
potentially been shared.

One pattern that might allow a transition is to have 
activateOptions-like methods return an object pointer which is used 
from then on.  Mutable objects could just return "this" since they 
don't change object identity when activating.  However, if one wanted 
to have an immutable implementation, the initial instance could be of a 
"Configurator" or "Builder" variant and the value returned from 
activateOptions would be immutable.  For example, an immutable 
FileAppender could be implemented with two classes: an immutable 
FileAppender and a FileAppenderBuilder, which allows setFile and the 
like, and would return a FileAppender on the call to activateOptions.

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

View raw message