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>
