logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: [POLL] Component and ComponentBase
Date Wed, 05 Jan 2005 11:26:00 GMT


As I understand it, a marker interface does not have methods. Since
Component has one method, namely setLoggerRepository(), it is not a
marker interface by definition.

The Appender interface extends the Component interface. So when you
get a handle on an object implementing the Appender interface, you
know that you can safely invoke setLoggerRepository() on that
object. Had Appender not been an extension of the Component interface
but AppenderSkeleton still extended ComponentBase, the compiler would
not have allowed you to write:

  void foo(String className) {
    Appender appender = (Appender) instantiateByReflection(className);
    appender.setLoggerRepository(repository) <-- would not compile

The Component interface must exist and Appender must extend Component,
so that we can invoke the setLoggerRepository() method on appender
instances, a condition imposed by the Java compiler.

A bunch of log4j classes invoke Component.setLoggerRepository.  To
convince yourself, if you are using Eclipse, select the
setLoggerRepository and right click, and then select
References->Project. You should see about 20 points where the project
references Component.setLoggerRepository().

Previously, appenders did not need to know about their owning
repository because the repository did not provide services beyond
returning logger instances. Appenders did not care about loggers and
hence did not need to hold a reference to their owning repository. In
1.3 however, the repository manages repository-wide properties, it
holds objects shared by embedded components, it holds a reference to
the scheduler, plug-in registry, etc. There is also the question of
self-generated log messages.

Concerning the impact on existing Appenders developed outside Apache
Logging Services, since they all derive from AppenderSkeleton, their
source code will NOT require changes. However, they might need to be
recompiled against 1.3. After verification, I appears that existing
Appender will run fine with 1.3. No need to recompile.

In principle though we have no obligation to keep our internal
interfaces backward compatible. One can argue all day about how good,
how nice and how important backward compatibility is, but when push
comes to shove, it is even more important to keep expectations
realistic and be able to deliver on them.

For instance, when a committer makes changes to code, I  expect them
to check that he did not break our test cases by running "ant runAll"
in the ./tests/ directory.

At 02:54 AM 1/5/2005, Mark Womack wrote:
> > No, log4j objects will not be referenced as Component. It is not a
> > marker interface either.
> >
> > The requirement to have both Component as an interface and
> > ComponentBase as a class, stems from the fact that we make the
> > distinction between Appender the interface and AppenderSkeleton the
> > class. Implementations of Appender derive from AppenderSkeleton but
> > all the other code in log4j refers to Appender and is oblivious to the
> > existence of AppenderSkeleton.
>And that makes sense because you want the outside world to deal with
>Appender, not AppenderSkeleton.  AppenderSkeleton has implementation methods
>that are specific to it.  I get it.  But if we will never reference
>Components and it is not a marker interface, why have an interface at all?
>Why not just implement ComponentBase with the functionality and have all the
>log4j implementation just inherit from that base class?  What purpose is the
>Component interface serving here?
>Let's approach it a different way.  If I am a developer, and I implement my
>own appender class that implements the Appender interface, will we (the
>framework) care if I implement setLoggerRepository?  Will parts of the
>framework expect to find this method or crash otherwise?  If yes, then an
>interface makes sense here.  If no, then I don't see what purpose the
>interface really serves; ComponentBase is providing useful but not required
>functionality for internal logging.
>I am guessing that we are making setLoggerRepository a required method for
>appenders given that you have Appender extending Component.  How have
>appenders survived this long without knowing about their owning repository?
>Besides internal logging (which one might argue, external developers should
>not have to be concerned about), what benefit does this have for appenders?
>That interface change is going to have much larger effect than the change to
>the Configurator interface.  Almost no one writes their own configurator,
>but at some point almost everyone writes their own appender.  Unless they
>subclass AppenderSkeleton, they will need to modify their appender code.

Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message