[EMAIL PROTECTED] wrote: > On 22 Jul 2002, Bob Herrmann wrote: > > >>This could be fixed by adding these methods to Log of commons-logger >> >> void trace(Object msg, Throwable thr, String className, String method); >> void debug(Object msg, Throwable thr, String className, String method); >> void info(Object msg, Throwable thr, String className, String method); >> void warn(Object msg, Throwable thr, String className, String method); >> void error(Object msg, Throwable thr, String className, String method); >> void fatal(Object msg, Throwable thr, String className, String method); > > > I think there is a simpler solution for this class of problems, and > that would also work with log4j and doesn't require _any_ API change. > ( only changes to the adapter implementations ) > > Any 'wrapper' will use: > factory=LogFactory.getFactory(); > > factory.setAttribute( "commons-logging.wrapperClass", > "[CLASSNAME-OF-WRAPPER]"); > factory.getLog(), etc. > > The classname of wrapper will be passed to the impl.. > > - for log4j - this just gets passed further, since log4j already supports > this feature. > - for jdk1.4 or other loggers who don't support wrapping - there is > already code in Jdk14Logger that walks the stack trace. Curently it > uses a hard-coded '2 levels up', but it can use the wrapperClass > and walk up to find it.
Looks good :) +1. Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
