On Wednesday, January 9, 2002, at 06:28 PM, Scott Sanders wrote: > I think that all calls should push through to the underlying system, and > that if possible the set/getLevel methods should operate on the > underlying implementation.
it's probably easier for me to start by saying why i made the change to dealing with log levels internally... what broke logging was that somebody changed the values of the Log level constants. this broke the existing implementations pretty badly. i wanted a way to create robust implementations and which would allow test code to be written. i switched to dealing with log level internally within commons-logging as a way to achieve these aims. i wasn't too sure what the original intention concerning log level had been until craig committed his Jdk14Logger. now we have one too many meanings for setLevel :) they are other ways that logging could be fixed while still delegating log levels to the logging system but i do have a couple of reasons why i think that dealing with the log level internally is better. how different logging systems are configured is much more variable than the logging interface they present. IMHO commons-logging should not perform any configuration of the underlying logging system. the user must be expected to perform that configuration but equally commons-logging should not change the configuration set up by the user. i also think that dealing with log levels internally will be easier to explain to users. i have two particular cases in mind: 1. i'd expect that setLevel(Log.OFF) should turn off logging for that instance. delegating to the logging system means that the actual behaviour in this case is variable. for example, the old log4j implementation of setLevel(Log.OFF) actually did the opposite since log4j doesn't support an OFF priority. 2. let's say we have two instances of a component with logging. let's say a user creates code that calls setLevel(Log.OFF) on one instance and setLevel(Log.DEBUG) on the other. i'd say that most users would expect the effect of this would be to switch logging on for one instance and off for the other. what you get with delegation to the logging system is that the effective priority will be determined by the order in which the calls are made. if they are internal to commons-logging then different instances can have different log levels. - robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
