You cannot set your own LoggerRepository, but your own RepositorySelector,
somewhere at the beginning of your main application:
private static Object guard = new Object();
static
{
LogManager.setRepositorySelector( new MyRepositorySelector(), guard );
}
When asking for a Logger the LogManager asks first this selector for the
correct repository. You write your own derivation of the Hierarchy class where
you overwrite the getLogger(String, LoggerFactory) Method in order to append
your JobID to the desired logger name.
This approach assumes your jobs are running in different thread contexts. At
the entry point of the thread you put the JobID into the MDC which keeps its
values threadlocal. Your Hierarchy derivation can retrieve the value valid in
the current thread. At the end of the thread the value should be removed again.
Doing like this you dont loose the main benefit of log4j, i.e. finetuning your
logger output by class and package names.
Heri
> -----Original Message-----
> From: Steve Folly [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 04, 2006 11:34 PM
> To: log4j-user@logging.apache.org
> Subject: [SPAM (Bayesain Analysis)] - Implement my own logger
> repository? - Bayesian Filter detected spam
>
>
> Hi,
>
> I have found previous threads in this mailing list about the
> limitation of not being able to remove loggers from the hierarchy.
>
> But I have a web application that executes 'jobs' for
> different users
> (executed in background threads). I'd like to implement a log for
> each job. Each job (and thus it's logger) is transient and
> only lasts
> for a short period of time (sometimes just seconds, others for
> several minutes).
>
> Could it make sense to implement my own logger class outside of the
> logger hierarchy and make it AppenderAttachable? I'd like to use the
> functionality of the appenders to give me file and socket support.
>
> Or would I just need to implement my own LoggerRepository? I get the
> impression the design might allow the use of different repository
> implementations? I'd like to implement one that stores just a flat
> list of loggers (one per 'job'), and will allow the removal of a
> logger from the list. In fact, it probably doesn't even need to keep
> a reference to the logger since the 'job' object will do that.
>
> Does this make any sense? Thanks for any help.
>
> --
> Steve.
>
>
> ---------------------------------------------------------------------
> 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]
