logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Curt Arnold <carn...@apache.org>
Subject Re: [POLL] Component and ComponentBase
Date Tue, 04 Jan 2005 15:57:16 GMT

On Jan 4, 2005, at 6:08 AM, Ceki Gülcü wrote:

> At 08:53 PM 1/3/2005, Curt Arnold wrote:
>> In addition, it is probably not good to have "components" reference 
>> the concrete LoggerRepository class.  We should probably introduce an 
>> interface (maybe "LoggerContext") that exposes the methods on 
>> LoggerRepository that "components" are expected to use.
> This touches a larger problem of log4j's security model. However,
> since log4j users can freely access the logger repository it would
> seem unreasonable to prevent log4j components from having the same
> access.

I was thinking more about testing concerns than security concerns.  If 
"components" depend on and may have interactions with a concrete class 
like LoggerRepository, then it increases the difficulty of testing.  If 
they depend on an interface, then the unit tests can provide a mock 
implementation if need be.

> You are 100% right to note that LoggerRepository can be left
> unset. However, leaving the LoggerRepository unset is synonymous with
> a programming error.

Minimizing the opportunities for programming errors is a good thing in 
my book.

> In the absence of bugs in log4j configurators,
> the LoggerRepository will be correctly set for all components
> generated during the configuration phase.  If custom extensions (built
> outside the Apache Logging Services) forget to set the
> LoggerRepository, then the CustomerBase implementation defaults to
> using a o.a.ugli.impl.SimpleLoggerFA instance instead of the "correct"
> LoggerRepository.
> Most importantly, it is not possible to impose a constructor on an
> interface and log4j source code assumes interfaces, not classes. For
> example, the code is developed in terms of the Appender interface not
> AppenderSkeleton.

The configuration constructs concrete classes and could pass the 
LoggerRepository/LoggerContext/Logger as a constructor parameter.

Looks like the move to extend things from ComponentBase is in progress. 
  Please give us a heads up when that is finished.  I would very 
strongly prefer that the "component" receive an implementation of some 
appropriate interface instead of a concrete class and would prefer that 
that occur in its constructor.  When you've rebased everything on 
ComponentBase, then we can experiment.

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

View raw message