Given what you said it appears that either the config file or the code needs to give a filename for each thread. If you can do it in code then you may be able to do it in the config file. The config file would of course only work if the thread names were basically static.
Another option is to create the thread trunks as specified and attach the appenders in code (as would have to be done with the repository selector). Is there any advantage to using a repository selector over this idea? The only advantage that comes to mind is that the repository selector makes it easier to get the logger. For my example you would probably have to get the logger inside each method instead of making it a class member. On 2/22/06, Bender Heri <[EMAIL PROTECTED]> wrote: > No, this would not work since you dont know the thread id in configuration > file where you name the logger. > > [snip] > > Somewhere at the entry point of your sub app (thread) you must put the needed > distinguishing features into MDC, fetch a logger and supply the file > appender(s) with the desired filename. > > Heri > > > > -----Original Message----- > > From: James Stauffer [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, February 22, 2006 4:08 PM > > To: Log4J Users List > > Subject: Re: Use different log files inside one program > > > > > > Would the following work? It would make a separate logger trunk per > > thread name. > > > > Logger logger = Logger.getLogger(Thread.currentThread().getName() + > > "." + getClass().getName()); > > > > On 2/21/06, Kev. <[EMAIL PROTECTED]> wrote: > > > Winston Huang <weiqingh <at> mail.com> writes: > > > > > > > > > > > hi there, > > > > > > > > i have a java program that behaves like a cron job which kicks off > > > > jobs based on certain conditions. each job is implemented by a a > > > > Runnable. i would like to have each job use a different > > log file. the > > > > best i can do so far is to set NDC for the Runnable or > > print out the > > > > thread name in the output. but all the logs still go to the same > > > > file. it's more convenient if each job can write to a > > different log > > > > file, identified by the job name for example. is there > > any way to do > > > > it? > > > > > > > > note that each Runnable can invoke other common classes > > which in turn > > > > use log4j inside. e.g. Runnable1 may call Util.foo, and > > Runnable2 may > > > > call Util.foo as well. the logging output from Util.foo > > should go to > > > > different log files based on the Runnable. however > > Util.foo uses the > > > > static logger that's assoicated with the Util class itself. > > > > > > > > any help is greatly appreciated. > > > > Winston > > > > > > > > > > > > > I have this problem too... Any luck figuring this out? > > > > > > This is the same issue as one program spawning multiple > > threads and wanting to > > > direct the logging of each thread to a unique and dedicated > > log file. > > > > > > Seem's Log4j definitely supports logging control within a > > specific package > > > hierarchy... that is you can control packages at various > > levels. But what if > > > you want to control at the thread (lightweight or > > heavyweight) level - usually > > > spanning many, many disparate packages? > > > > > > Kev. > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > James Stauffer > > Are you good? Take the test at http://www.livingwaters.com/good/ > > > > --------------------------------------------------------------------- > > 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] > > -- James Stauffer Are you good? Take the test at http://www.livingwaters.com/good/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
