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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
