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>
