My bad. I forgot to check in the modified witness files... I'll do that in a second. Sorry for the hassle.
At 09:48 14.11.2002 +0100, you wrote:
Have you recently updated tests/ from CVS? I made some changes yesterday. At 22:37 13.11.2002 -0800, you wrote:I did the changes noted below, but when I try to run the test cases, I get an error running MinimumTestCase. I'm pretty sure my changes have nothing to do with this, but I am uncomfortable checking in changes when I cannot successfully run the test cases. Will this be resolved soon? Is there something I need to do in my environment?-Mark Minimum: [junit] Running org.apache.log4j.MinimumTestCase [junit] Files [output/filtered] and [witness/simple] differ on line 26 [junit] One reads: [ at org.apache.log4j.MinimumTestCase.common(X)]. [junit] Other reads:[ at org.apache.log4j.MinimumTestCase.common(Minim umTestCase.java:XXX)]. [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.651 sec [junit] Testsuite: org.apache.log4j.MinimumTestCase [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.651 sec [junit] [junit] Testcase: simple took 0.651 sec [junit] FAILED [junit] null [junit] junit.framework.AssertionFailedError [junit] at junit.framework.Assert.fail(Assert.java:51) [junit] at junit.framework.Assert.assertTrue(Assert.java:38) [junit] at junit.framework.Assert.assertTrue(Assert.java:45) [junit] at org.apache.log4j.MinimumTestCase.simple(MinimumTestCase.java: 67) [junit] at java.lang.reflect.Method.invoke(Native Method) [junit] at junit.framework.TestCase.runTest(TestCase.java:166) [junit] at junit.framework.TestCase.runBare(TestCase.java:140) [junit] at junit.framework.TestResult$1.protect(TestResult.java:106) [junit] at junit.framework.TestResult.runProtected(TestResult.java:124) [junit] at junit.framework.TestResult.run(TestResult.java:109) [junit] at junit.framework.TestCase.run(TestCase.java:131) [junit] at junit.framework.TestSuite.runTest(TestSuite.java:173) [junit] at junit.framework.TestSuite.run(TestSuite.java:168) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. run(JUnitTestRunner.java:231) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner. main(JUnitTestRunner.java:409) [junit] BUILD FAILED > -----Original Message----- > From: Mark Womack [mailto:mwomack@;bevocal.com] > Sent: Wednesday, November 13, 2002 9:48 AM > To: 'Log4J Developers List' > Subject: RE: Problems adding new listener interfaces > > > OK. So, I will deprecate the fireAddAppenderEvent(category, appender) and > create a new version fireAddAppenderEvent(logger, appender). > Should we also > add fireRemoveAppenderEvent(category, appender) (and maybe > fireRemoveAllAppendersEvent() and fireLevelChangedEvent()) to > LoggerRepository? Don't the loggers need access to those methods > as well to > report their activity? > > I did not realize that we could cast a Category to Logger and it would > always work in v1.2. That is good news. We should take a pass > through the > interfaces and deprecate methods using Category and replace them with > versions using Logger. At some point Category will be going away, so we > should prepare folks now. > > Regarding the indentation, I am using JCreator for my editor, and it does > not automatically indent files when they are opened. In the > files I sent, I > did some minor cleanup to layout of some of the methods, etc to match the > log4j format. We really should use a style tool to format the existing > source to our chosen format and check in the result. > > I'll be checking more stuff in tonight. > > thanks! > -Mark > > > -----Original Message----- > > From: Ceki Gülcü [mailto:ceki@;qos.ch] > > Sent: Wednesday, November 13, 2002 4:09 AM > > To: Log4J Developers List > > Subject: Re: Problems adding new listener interfaces > > > > > > > > AFAIK, the only place where HierarchyEventListener interface is > > actually used to get work done is in the o.a.l.jmx package. Our > > current JMX support is half-baked. So, I would not have any qualms to > > just remove HierarchyEventListener and by implication change the > > LoggerRepository interface and the Hierarchy class. This should not > > affect any of our users or developers extending log4j. > > > > Now, if you remove the addHierarchyEventLister method in > > LoggerRepository and Hierarchy, the jmx package will no longer > > compile. So for the time being you can leave them in as deprecated (as > > you have already done). I'll remove them later when it is time to work > > on the o.a.l.jmx package. > > > > > Also, fireAddAppenderEvent() is actually defined in the > > > LoggerRepository interface. Why? Seems like that should be a > > > private/protected method of Hierarchy to me. > > > > Good question. The reasons for having fireAddAppenderEvent() in > > LoggerRepository is because for efficiency reasons Loggers do not know > > about HierarchyEventListeners. HierarchyEventListeners are added to a > > LoggerRepository. The logger tells its logger repository to fire an > > event to inform the registered hierarchy event listeners. Otherwise, > > we would have needed to add a HierarchyEventListener to each logger > > which would be quite cumbersome, instead we register a listener with > > just the container (the logger repository). > > > > Have I answered the question? > > > > BTW, which IDE are you using? Does it automatically indent > > files? If it > > does this can be a problem because if many lines are automatically > > indented, then the results of a diff operation are drowned by false > > diffs, that is, lines where just the indentation has changed but not > > contents. This is not a major problem just something to be aware of. > > > > I really appreciate your thoroughness. > > > > One more note. When category class calls fireSomethingEvent it will > > pass itself as parameter. This parameter can be cast to Logger even if > > "this" is seemingly of class Category. Log4j 1.2 will NEVER produce > > pure Category objects, ALL produced categories are actually Logger. > > > > At 22:06 12.11.2002 -0800, you wrote: > > >I created and checked in new listener interfaces > > >LoggerRepositoryEventListener and LoggerEventListener. You > > can review. > > > > > >I then went ahead and modified LoggerRepository to deprecate > > the current > > >addHierarchyEventListener() method and to add new methods to > > add/remove the > > >new listeners. > > > > > >I then went ahead a started to modify Hierarchy to support the new > > >listeners. Everything is straight forward until I get to > > >fireAddAppenderEvent() and fireRemoveAppenderEvent() > > methods. Both of these > > >take Category as input parameters, so I get a compile error > > when I try to > > >pass it to the LoggerEventListener methods that require a > > Logger. Also, > > >fireAddAppenderEvent() is actually defined in the LoggerRepository > > >interface. Why? Seems like that should be a > > private/protected method of > > >Hierarchy to me. > > > > > >Can we look at upgrading Hierarchy to use Logger instead of > > Category? I'm > > >guessing that it will affect the current interface quite a > > bit. Ceki, I > > >think it will require you to look into it as this has the > > potential to > > >break lots of things. > > > > > >I have not checked in my LoggerRepository or Hierarchy > > changes as doing so > > >will break the build. I have enclosed them with this email > > if it will help. > > > > > >stuck, > > >-Mark > > > > > > > > >-- > > >To unsubscribe, e-mail: > > <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> > > >For additional commands, e-mail: > > <mailto:log4j-dev-help@;jakarta.apache.org> > > > > -- > > Ceki > > > > TCP implementations will follow a general principle of robustness: be > > conservative in what you do, be liberal in what you accept from > > others. -- Jon Postel, RFC 793 > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> > > For additional commands, e-mail: > > <mailto:log4j-dev-help@;jakarta.apache.org> > > > > -- > To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>-- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>
-- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>
