On Feb 22, 2005, at 2:50 PM, Curt Arnold wrote:
On Feb 22, 2005, at 2:30 PM, Ceki G�lc� wrote:
Bad timing, I just reverted it. I wanted to make sure it was live for the next Gump iteration and I assumed that there was not going to be a response from you given the late time.
Fortunately, it was very localized at this point, all that was required to be reverted was Appender and AbstractAppenderTest. I had also left an import of SMTPAppenderTest in AbstractAppenderTest which was causing the continued failure of logging-log4j-tests. I think this is a reasonable state to hold and work through the issues.
logging-log4j-tests was successful.
hivemind (http://brutus.apache.org/gump/public/jakarta-hivemind/jakarta- hivemind/gump_work/build_jakarta-hivemind_jakarta-hivemind.txt) appeared to fail due the following check in AppenderSkeleton:
public
synchronized
void doAppend(LoggingEvent event) {
..
if (!this.active) {
getNonFloodingLogger().error(
"Attempted to log with inactive appender named [{}].", name);
return;
}
What I'm inferring from this is that the recent changes made it mandatory to call activate in any client code that explicitly configured AppenderSkeleton derived appenders. I couldn't find anything in the framework that would trigger a call to activate on adding an Appender to a repository (especially since that method doesn't exist on Appender anymore).
I haven't looked at the Hivemind code, but I assumed that it implemented an appender without using AppenderSkeleton since the interface change broke it, but this problem suggests that they have an appender that did extend AppenderSkeleton. Maybe they have one of each, or maybe my analysis was off.
It would be good to at least let the reversion stay in place through the Gump cycle. The breaking of HiveMind wasn't obviously a log4j issue when I reviewed their Gump logs and there were several other Gump projects (jug, jakarta-hivemind, jakarta-cactus-sample-servlet-12, jakarta-cactus-sample-servlet-13, jakarta-cactus-sample-jetty-13) that had also been broken for the same number of builds. Letting the reversion stay in place at least for tonight will allow us to know whether all those projects were broken by the interface change.
The Cactus builds that started failing on the same iteration as Hivemind are still failing. There had been no discussion on cactus-dev on the Gump failures but there has been no CVS activity since several days prior to our changes. I'm dropping a message to the cactus-dev list to see if they think we broke them.
On another note: Looking at the output for the Cactus builds (http://brutus.apache.org/gump/public/jakarta-cactus/jakarta-cactus- sample-servlet-12/gump_work/build_jakarta-cactus_jakarta-cactus-sample- servlet-12.txt) shows a huge number of internal log4j log messages appearing like:
[cactus] log4j:INFO Creating new logger [org.apache.cactus.internal.configuration.ConfigurationInitializer] in repository [default].
[cactus] log4j:INFO Creating new logger [org.apache.cactus.internal.server.ServerTestCaseCaller] in repository [default].
[cactus] log4j:INFO Creating new logger [org.apache.cactus.internal.util.TestCaseImplementChecker] in repository [default].
[cactus] log4j:INFO Creating new logger [org.apache.cactus.internal.util.JUnitVersionHelper] in repository [default].
[cactus] log4j:INFO Creating new logger [org.apache.cactus.internal.client.ClientTestCaseCaller] in repository [default].
I've got to think that LogLog was not that chatty.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
