logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: activateOptions pattern not desirable
Date Fri, 18 Feb 2005 20:35:03 GMT

On Feb 18, 2005, at 1:30 PM, Ceki Gülcü wrote:

> I don't think Appenders can be completely immutable. For one, you can 
> invoke the close() method on an appender. You can also add remove 
> filters or change the threshold of an active appender. The only 
> appender which should be immutable is a closed appender.
> It does not make much sense to me to harden appenders when one can 
> easily yank out any appender from a logger and replace it with a 
> different one...

I was suggesting that if a substantial part of the framework is being 
refactored, trying to make the objects immutable should be considered 
as part of the refactoring.  Maybe Appenders aren't a good fit with the 
pattern, maybe they are but it just isn't obvious.  I wasn't suggesting 
that we try to refactor them now.

However, the state changes that you mentioned could be represented by a 
series of immutable objects.  The advantage is that you would not need 
to synchronize the state changes only the swap of the new appender with 
the old appender.  For example, if I'm removing one filter and adding 
another filter and I'm changing the object in place, the appender with 
just the first filter removed could be visible to other threads for a 
period of time.  With immutable objects, I could do the state changes 
in isolation and then swap out the new appender for the old one as an 
atomic operation.  It also can reduce the number of code points that 
you have to worry about synchronization.  With immutable objects, you 
only have to synchronize the replacement of one object with another.  
With mutable objects, you have to synchronize every method that might 
be affected by the contents of a mutable field.

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

View raw message