I haven't had a chance to check in the changes since this fix. I will be doing some tonight.
fyi, -Mark > -----Original Message----- > From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] > Sent: Thursday, November 14, 2002 12:51 AM > To: Log4J Developers List > Subject: RE: Problems adding new listener interfaces > > > > 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:[EMAIL PROTECTED]] > >> > 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:[EMAIL PROTECTED]] > >> > > 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:[EMAIL PROTECTED]> > >> > > >For additional commands, e-mail: > >> > > <mailto:[EMAIL PROTECTED]> > >> > > > >> > > -- > >> > > 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:[EMAIL PROTECTED]> > >> > > For additional commands, e-mail: > >> > > <mailto:[EMAIL PROTECTED]> > >> > > > >> > > >> > -- > >> > To unsubscribe, e-mail: > >><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > >> > >> > >>-- > >>To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > >-- > >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:[EMAIL PROTECTED]> > >For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > 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:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
