Good Morning, maybe this is a different approach to allow custom (propietary) logger development for special cases and interfaces and use at the same time log4j quality, infrastructure and concepts:
1) creating a class abstract org.apache.log4j.AbstractLogger: -containing (protected) methods for checking the loglevel, really writing (so like forcedLog) -removing all depracted methods 1b) -extending existing class org.apache.log4j.Logger extends AbstractLogger implements ULogger 2) creating a class abstract org.apache.log4j.AbstractLogStore -containg (protected) methods store(AbstractLogger logger) remove(AbstractLogger logger) 2b) creating a class LogManager extends AbstractLogStore -method public static org.apache.log4j.Logger getLogger(String name) ... Pro's: -(backward) compatibilty with existing mechanisms -still allowing wrappers as build in ugli -allowing different interfaces (hm, not liked here, I write it anyway: org.apache.ugli.JSR47Logger, org.apache.commons.logging.Log :-) -typesafe -compile-time bind Con's: -Many Developers have an 'not invented here' syndrom, so potentially there are hundreds of project specific (senseless duplicated) AbstractLogger implementations -not forced but one possible result: many factories causing confusion -refactoring of Logger needs new intensive testing, may cause new bugs Tonight hopefully I have some time to write a first PoC Code. Regards Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
