logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: Gump issues
Date Thu, 24 Feb 2005 16:47:41 GMT

Thanks for following up on this!

At 05:24 PM 2/24/2005, Curt Arnold wrote:
>Commenting out
>       if (!this.active) {
>         getNonFloodingLogger().error(
>             "Attempted to log with inactive appender named [{}].", name);
>         return;
>       }
>from AppenderSkeleton.doAppend was sufficient to get hivemind building again.

That makes sense because the recent additions are compile-time compatible 
with existing appenders. The new !this.active check in AppenderSkeleton 
makes sure that the appender is in working state and that activate() (or 
activateOptions()) has been called on the appender.

As I understand it, Hivemind tests that its own appender works properly. If 
that is the case, clearly log4j related tests performed outside log4j 
should keep us, log4j developers, from doing the right thing, e.g. adding 
the !this.active check in AppenderSkeleton. In other words, for this 
particular case, Hivemind should align its appenders with log4j 1.3 
behavior or it binds against the log4j 1.2 branch.

>Setting up a Hivemind build was sufficiently complex that I abandoned the 
>attempt and just took a stab.
>The cactus related items are still broken and I'll see if I can analyze 
>their issues but the circumstantial evidence suggest that we broke them too.

Let me have a closer look and get back to you. :-)

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

View raw message