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/24 17:24:02 UTC
Gump issues
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. 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Gump issues
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:47 PM 2/24/2005, Ceki Gülcü wrote:
>That makes sense because the recent additions are compile-time compatible
>with existing appenders.
The above statement is true for any appender extending AppenderSkeleton
because AppenderSkeleton implements the methods newly added to the Appender
interface, namely activate(), isClosed() and isActive(). Thus, the changes
should not affect compile-time compatibility of existing appenders. They
should be added back to the Appender interface as soon as the issues
affecting Cactus are resolved/clarified.
--
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
Re: Gump issues
Posted by Ceki Gülcü <ce...@qos.ch>.
Curt,
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