LS> perhaps you can explain a little more just why this constructur sucks so
LS> bad....I can imagine valid use cases. Furthermore, I can imagine it
LS> actually being used in places.
AT> 8) LogKitLoggerManager(
AT> String prefix,
AT> Logger defaultLogger)
AT>
AT> in line with changes discussed in section 7) I would
AT> like to change the contract
LS> again, changing contracts on released code is something I'm weary of.
Okay, after thinking this over
probably I shall leave all these constructors do what they do,
two new constructors will be added
LogKitLoggerManager( String prefix, String switchTo )
LogKitLoggerManager( String prefix, Hierarchy hierarchy, String
switchTo)
they will play in cooperation with enableLogging() to provide the
"internal", aka "fallback" logger.
Probably I'll elaborate in the inline docs to the "old" constructors
(those that accept loggers) that the newer ones are probably preferred
to them.
Maybe also
getLoggerForCategory( String category )
{
if ( "".equals( category ) )
{
return m_defaultLogger;
}
...
}
Is that better?
Not deprecation but an advice to consider the other constructors.
Still I do not like very much what the
LogKitLoggerManager( String prefix, Logger logger )
constructor does, maybe deprecate it in the future? :-)
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
