Curt and Ceki,
Curt Arnold <carnold <at> apache.org> writes:
> > Actually, looking at the Gump messages in the Hivemind mailing list > suggest that the problem was all along the lack of an activateOptions > call before adding an appender and was never the addition of > isClosed(), isActive() and activate. >
Yes, calling activateOptions() on the appender would indeed solve the problem,
as activateOptions() in turn calls activate(). But you say the problem was the
lack of a call to this method. I wasn't aware of that this was required since
we don't have any options to activate and further I thought this method was
there to override by subclasses. So should this maybe be noted in the Javadoc?
For all appenders except trivial ones, the activateOptions() method must be called before an appender can be used. This is true for both log4j versions 1.2 as well 1.3.
However, in log4j 1.3, this contract is enforced by run-time checks. Thus, if you forget to call activateOptions() method, AppenderSkeleton will *refuse* to invoke the append() method of its derived classes.
Users who programmatically instantiate appenders, even appenders maintained outside the log4j project, need to call the activateOptions() method after they instantiate and set its options. This will ensure run-time compatibility for log4j 1.2 as well as 1.3.
The same is also explained at the page below:
http://www.qos.ch/logging/preparingFor13.jsp#activateOptions
> Please apply the following patch, this should resolve the problem and > still be compatible with log4j 1.2.x. I'll repost the patch to the > hivemind-dev mailing list if there is not quick response to see if I > can get another committer to get it in before tonights Gump run. >
I will go ahead and apply the patch now. I hope it wasn't too late now.
Thanks Knut.
--knut
-- Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
