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>
