You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Curt Arnold <ca...@apache.org> on 2005/02/18 19:03:03 UTC
activateOptions pattern not desirable
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
Re: activateOptions pattern not desirable
Posted by Curt Arnold <ca...@apache.org>.
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
Re: activateOptions pattern not desirable
Posted by Ceki Gülcü <ce...@qos.ch>.
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...
At 07:03 PM 2/18/2005, Curt Arnold wrote:
>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
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org