I planned on implementing it myself but then I thought it would make more sense in Log4j since it wasn't there already. I don't think it would be such a tiny class because, from my orginal message, I would want the ThreadLocal to hold a stack of loggers, not just one logger. Then, as the thread of execution progresses, the logging context can be changed.
I agree that it would be fairly easy to implement but I think it offers the developer more flexibility in how they do logging (logging categories can be created based on function but possibly cover multiple classes/methods). I think it would be a good addition to Log4j. Tony >>> [EMAIL PROTECTED] 06/08/04 08:04PM >>> We've been using ThreadLocal loggers in our enterprise applications. We implemented a custom logging layer that sits on top of Log4j. There are other ways to do it.... you can declare ThreadLocal Logger variables -OR- you could build an intelligent Logger class -OR- perhaps you could build a custom LoggerRepository -OR- you could write a custom Appender that is thread-aware. -Sean > -----Original Message----- > From: Paul Smith [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 08, 2004 5:58 PM > To: Log4J Users List > Subject: Re: Log4j category for a thread > > > I was thinking about this, but it's just a tiny class that > would have a > Logger available, and then people might want different > ThreadLocal loggers > bound for different purposes. I'm not sure the class adds a > lot of value > to log4j, but I agree the concept/methodology might be worth > having on the > wiki somewhere.. > > cheers, > > Paul Smith > > On Tue, 8 Jun 2004, Tony Thompson wrote: > > > Would it make sense to put something like that in Log4j, since the > > functionality doesn't currently exist? > > > >>>> [EMAIL PROTECTED] 06/08/04 05:21PM >>> > > I would suggest then simply setting up a ThreadLocal Logger then, > > configured at the start of your request, that all the participants > > expect > > to be there. > > > > On Tue, 8 Jun 2004, Tony Thompson wrote: > > > >>> Pardon my asking but what is wrong with: > >>> > >>> void getUser() { > >>> Logger logger = LogManager.getLogger( > "org.widgets.getUser" ); > >>> } > >>> > >>> or just > >>> > >>> void getUser() { > >>> Logger logger = LogManager.getLogger( "org.widgets" ); > >>> } > >>> > >>> Why should the logging in getUser() care if it has been called by > >> login() > >>> or by logout()? > >>> > >>> Please bear with me, I am trying to understand the use case. > >> > >> No problem. > >> > >> I don't really want getUser() to have its own logging > category. What > > I > >> am concerned about is the end user experience. If I am > the end user > > and > >> I want to see DEBUG for the login process, I shouldn't have to set > > DEBUG > >> levels on more than one category. I should set DEBUG for > >> "org.widgets.login" and see all of the debug available for > the login > >> process. Plus, getUser() would display DEBUG messages every time > >> logout() is called which is not what I wanted either. > >> > >> Now, as the server developer, I could implement getUser() > like this: > >> > >> void getUser( Logger logger ) { > >> } > >> > >> and just pass the logger in every time I call it. That would > >> accomplish the same thing. But, I don't really want to > mess with all > > of > >> the code that calls getUser() and pass in a Logger. > >> > >> So, to me, the cleanest solution would be to set a Logger for the > >> current thread. Then getUser() can just grab the "current" logger > > and > >> use that. It doesn't care because it is only part of a larger > > process > >> anyway. This is an implementation detail but, you would > also need a > >> default category (maybe the root logger) to log messages to in case > > the > >> caller hasn't set a logger context. Either way, getUser() > relies on > >> someone else to tell it what its logger should be. > >> > >> Tony > >> > >> > > > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > ------------------------------------------------------------ > > Mail was checked for spam by the Freeware Edition of No Spam Today! > > The Freeware Edition is free for personal and non-commercial use. > > You can remove this notice by purchasing a full license! To order > > or to find out more please visit: http://www.no-spam-today.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ------------------------------------------------------------ Mail was checked for spam by the Freeware Edition of No Spam Today! The Freeware Edition is free for personal and non-commercial use. You can remove this notice by purchasing a full license! To order or to find out more please visit: http://www.no-spam-today.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
