No, this would not work since you dont know the thread id in configuration file
where you name the logger.
You must implement your own repository selector which maintains a repository
for each thread (or other distinguishing features as you like). The following
is a sample which has two distinguishing features put in the MDC (which is
maintained per thread basis):
public class PMSRepositorySelector implements RepositorySelector
{
/** ID of the default hierarchy */
private static final String DEFAULT_REPOSITORY_ID = "PMSDefaultRepository";
/** the location of the repository */
private static Hashtable myHt = new Hashtable();
/**
* @see org.apache.log4j.spi.RepositorySelector#getLoggerRepository()
*/
public LoggerRepository getLoggerRepository()
{
Integer eventID = ( Integer ) MDC.get( PMSLogger.PROP_NAME_EVENT_ID );
String appName = ( String ) MDC.get( PMSLogger.PROP_NAME_APP_NAME );
Hierarchy h = null;
if ( ( eventID == null )
|| ( appName == null ) )
{
// MDC values are not set. This means, this method was called from
somewhere not in PMS System
h = ( Hierarchy ) myHt.get( DEFAULT_REPOSITORY_ID );
if ( h == null )
{
h = createAndLoadHierarchy();
myHt.put( DEFAULT_REPOSITORY_ID, h );
}
}
else
{
// we maintain one Hierarchy per eventID and appName:
Hashtable ht = ( Hashtable ) myHt.get( eventID );
if ( ht == null )
{
ht = new Hashtable();
myHt.put( eventID, ht );
}
h = ( Hierarchy ) ht.get( appName );
if ( h == null )
{
h = createAndLoadHierarchy();
ht.put( appName, h );
}
}
return h;
}
/**
* Creates a new Hierarchy and configurs it from the file log4j.xml
*
* @return the newly created Hierarchy
*/
private synchronized Hierarchy createAndLoadHierarchy()
{
Hierarchy h;
h = new Hierarchy( new RootCategory( Level.DEBUG ) );
URL url = Loader.getResource( "log4j.xml" );
OptionConverter.selectAndConfigure( url,
"org.apache.log4j.xml.DOMConfigurator", h );
return h;
}
}
Within your main class you put the following static code:
private static Object guard = new Object();
static
{
LogManager.setRepositorySelector( new PMSRepositorySelector(), guard );
}
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]
