This sounds like a good opportunity for a custom LogFactory implementation that manages its own hierarchy of loggers, so that you can create document-specific instances as necessary.
The way that the default LogFactory implemenation interprets the string or class argument to the getLog() method is just that -- a default. You can replace it with anything you need, so you can accomplish what you're after in this particular use case. Craig On Wed, 24 Nov 2004 16:10:51 +0100, J�rg Schaible <[EMAIL PROTECTED]> wrote: > Shapira, Yoav wrote on Wednesday, November 24, 2004 2:40 PM: > > > Hi, > > I don't know the reason, but I'm curious as to your use-case: > > why do you need it? > > Basically I have a special "named" logger hierarchy, i.e. I don't use class > names there, since I have the requirement that by examinating the logs you > should be able to follow the transitions of a document processed in my > application. Each document belongs to a client and I should be able to set > individual log levels for the different clients. In this case I would like to > receive in my components an existing Log object, request its name and create > a sublogger for document related entries (in fact I have also one for jobs > and more may come) and use that logger. > > > > - J�rg > > --------------------------------------------------------------------- > 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]
