Problems adding new listener interfaces

[mw...@apache.org]

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

Re: Problems adding new listener interfaces

[Ceki Gülcü <ce...@qos.ch>]

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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>