Hi Jeroen, I think you can solve your problem the way I did it: I put a wrapper around the Log4j logger and created a class called LoggingContext. This context keeps all additional information needed in my project (user name, component name, an additional log class, e.t.c.) The protocol of my wrapper is sightly extended it takes the context object as an additional parameter (i e.g. info(Object msg, Throwable t, LoggingContext ctx)). Before calling the native log4j-logger with message and throwable I do two things: I put the whole context objetc into the MDC. This enables my own appenders to fetch the context and use its information and/or functionality. Secondly, I put each single attribute of the context into the MDC. This enables all log4j appenders which can handle conversion patterns to use the context information. (This works fine even in a J2EE environment because there is no chance for the container to change the thread between filling the MDC and executing the log. So, a ThreadLocal is a safe place for the context.)
So you don't modify log4j functionality and - by using a context object - you keep your own client code stable even if the requirements change later. Hope this helps Klaus > -----Urspr�ngliche Nachricht----- > Von: "Frissaer, Jeroen" <[EMAIL PROTECTED]>@GEHE > Gesendet: Mittwoch, 5. Juni 2002 11:22 > An: 'Log4J Users List' > Betreff: RE: Log4J Wrapping > > <<...OLE_Obj...>> > Indeed Ceki, > > what I want to do is this: I would like to modify the Log4J functionality > in > order for the logging methods (info, debug, warn, error and fatal) to take > more parameters (not only message and throwable). To do this I must > change > multiple intern Log4J methods and the LoggingEvent class. This however is > not really the problem, but if I change the Log4J source to solve my > problem > I will have to do this every time a new version of Log4J will be released. > So I want to create some classes that implement my specific needs and can > be > used in together with Log4J. Whenever a new version of Log4J is released > I > will only have to install it the same way the previous version was > installed > and everything should work again. (Log4J like a plugin) > > Jeroen > > -----Original Message----- > From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 05, 2002 12:41 AM > To: Log4J Users List > Subject: Re: Log4J Wrapping > > > > I don't think Jeroen uses the term wrapping in the sense of > commons-logging. He apparently would like to extend the LoggingEvent > class. > > At 15:27 04.06.2002 -0700, Michael Klem wrote: > >Take a look at Apache's Commons-Logging code. This provides a wrapper > >around multiple logging techniques including Log4j. > > > ><http://jakarta.apache.org/commons/logging.html> > > > >You can grab the source from CVS and see what they do. > > > >>Jeroen, > > From a very quick look at what you are trying to do, I suggest you > create > >>an object type say MyObject that includes duration, userS, userR, > >>etc. and use that object when logging. You should also implement the > >>toString() method to return appropriate information. > >> > >>Probably a better approach is to use the MDC. > >> > >>At 11:20 04.06.2002 -0500, Frissaer, Jeroen wrote: > >>>Hi, > >>> > >>>My company is planning the use of Log4J within its applications (J2EE). > To > >>>serve our needs we will have to modify the Log4J API. We must use a > wrapper > >>>class in order to avoid recoding of the Log4J core each time we will > change > >>>Log4J versions. > >>> > >>>Modifying the Log4J API will look something like this: > >>>instead of using Logger.debug(Object message) we want to use > >>>Logger.debug(long duration, String UserSession, String userRequest, > String > >>>Resource, String ...) > >>> > >>>I tried making such a wrapper class with limited success. It looks > like > >>>this: > >>> > >>>package org.apache.log4j; > >>> > >>>import org.apache.log4j.LogManager; > >>>import org.apache.log4j.spi.*; > >>> > >>> > >>>public class MyWrapper { > >>> > >>> public static Logger myLogger; > >>> protected static LoggerRepository repository; > >>> > >>> public static void getMyLogger(String name) { > >>> myLogger = LogManager.getLogger(name); > >>> > >>> } > >>> > >>> public static void debug(long duration, String userS, String > userR, > >>>String result, String locInf, String res1, String addAtt1, String > addAtt2, > >>>String addAtt3) { > >>> //if(repository.isDisabled(Level.DEBUG_INT)) > >>> //return; > >>> if(Level.DEBUG.isGreaterOrEqual(myLogger.getEffectiveLevel())) > { > >>> myForcedLog(myLogger.getName(), Level.DEBUG, duration, > userS, > >>>userR, result, locInf, res1, addAtt1, addAtt2, addAtt3); > >>> } > >>> } > >>> > >>>Has anyone done similar things before? And would be kind enough to > share > >>>some ideas with me? > >>>What do you, Log4J - Java experts, think of this wrapping? Are there > better > >>>ways to solve the problem? > >>> > >>>Thanks in advance > >>>Jeroen > >> > >>-- > >>Ceki > >> > >>SUICIDE BOMBING - A CRIME AGAINST HUMANITY > >>Sign the petition: http://www.petitiononline.com/1234567b > >>I am signatory number 22106. What is your number? > >> > >> > >>-- > >>To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > >-- > >To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > Ceki > > SUICIDE BOMBING - A CRIME AGAINST HUMANITY > Sign the petition: http://www.petitiononline.com/1234567b > I am signatory number 22106. What is your number? > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
