I'll try it again tonight.

thanks,
-Mark

> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@;qos.ch]
> 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: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>
> 

--
To unsubscribe, e-mail:   <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>

Reply via email to