Hi

The problem of different log files within the same app does not arise on the 
"main" classes of each job (this can be configured very easy through different 
appenders), but in all underlying framework and helper classes. If the log 
outputs of these underlying classes should be separated too, then the 
RepositorySelector is a good choice, and the selector criteria can be defined 
via MDC. I did this in a similar project (a scheduler starts different jobs at 
given time intervals, each job has its own log file, but all self written 
without any big framework). 

To achieve this you have to ensure the following:
- each job must be executed in an own fresh Thread (to enable the selection 
criteria through MDC)
- classes which are common to different jobs must not have static Logger 
instances but instance member loggers (assuming the class is newly instantiated 
on a new job)
- utility classes with static helper methods must neither have static nor class 
member Logger instances but have to fetch the correct Logger within each call 
of each method
- on start of each job (Thread) you have to put a distinct value into MDC (i.e. 
"JobName=JobA"), before any logger is fetched from the repository
- The RepositorySelector maintains a Repository for each JobName. When it is 
asked for the correct repository the Selector will fetch the actual job name 
from MDC.
- Somewhere the file appender(s) for the different files must be supplied with 
the desired file name. This can be done at the same code location where the job 
starts and the MDC is updated. Iterate over the found appenders and change the 
file name.

I posted this solution some times ago (~2-3 years) to this news group. There 
was even a second selector criteria beside the actual job: each job was done on 
different mandators, so we had to log into different files for each 
job/mandator pair. Both criterias were in the MDC, the RepositorySelector 
maintained a Respository for each such pair.

If you dont find my posting write me and I will send you the solution.

Heri

> -----Original Message-----
> From: Jacob Kjome [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 07, 2008 7:42 PM
> To: Log4J Users List
> Subject: [SPAM (Bayesain Analysis)] - Re: Different Loggers for
> Different Instances of Same Class - Bayesian Filter detected spam
> 
> 
> So, because you use Spring setter injection, you think you 
> can't name your 
> loggers in a custom way?  Why not use a combination of 
> constructor and setter 
> injection?  I'm not sure why you'd need a repository selector 
> in this case 
> anyway?  What would be the selection criteria?  Are you 
> thinking thread? 
>  While that is possible, it seems both heavyweight and unnecesary.
> 
> It doesn't take multiple logger repositories to get 
> differently named logger 
> output into separate files.  In Spring, just use...
> 
>          <constructor-arg type="java.lang.String" 
> value="InstanceNameQualifierValue"/>
> OR
>          <constructor-arg index="0" 
> value="InstanceNameQualifierValue"/>
> OR (if it's the only constructor argument)
>          <constructor-arg value="InstanceNameQualifierValue"/>
> 
> Now, you mentioned MDC, and that's a separate, and seemingly 
> unrelated, issue. 
>  What problems are you having with MDC?
> 
> If I'm missing something, please let me know.
> 
> Jake
> 
> On Mon, 07 Apr 2008 08:24:25 -0400
>   "Robert Pepersack" <[EMAIL PROTECTED]> wrote:
> > Hi Jake,
> > 
> > Thanks for your response.
> > 
> > I did some reading from my copy of "The complete log4j 
> manual".  Chapter 8 
> >has a solution to this problem:  create a 
> RepositorySelector.  But, for me 
> >this is only a partial solution.  This is because I'm using 
> the Spring 
> >Framework's IOC container to manage my application (which is 
> a Java job 
> >scheduler that uses Quartz).  This means that, when I first start my 
> >application, the IOC container creates most of the instances 
> of my classes 
> >(including my Quartz jobs), and uses setter injection to 
> create the state for 
> >my classes.  I don't know how to get my loggers, and 
> associate them with the 
> >current thread using the MDC, when they have already been 
> created by the 
> >Spring IOC container.  Do you know how?
> > 
> > Thanks,
> > 
> > Robert Pepersack
> > Senior Lead Developer
> > Maryland Insurance Administration
> > 410-468-2054
> > 
> >>>> Jacob Kjome <[EMAIL PROTECTED]> 04/06/2008 4:42 PM >>>
> > 
> > You can use per-instance loggers and name you loggers as...
> > 
> > private Logger logger;
> > 
> > JdbcFacade(String instanceNameQualifier) {
> >   this.logger = this.getClass().getName() + istanceNameQualifier;
> > }
> > 
> > instanceNameQualifier might be "A" or "B" or whether else 
> you want it to be.
> > 
> > 
> > Jake
> > 
> > Robert Pepersack wrote:
> >> Hello.
> >> 
> >> Thanks in advance for your help.
> >> 
> >> I'm running scheduled jobs, and they create their own 
> instances of my JDBC 
> >>class.  For example, JobA creates a new JdbcFacadeA, and 
> JobB creates its own 
> >>JdbcFacadeB.  I would like to log each job in its own log 
> (easy).  But, I 
> >>want the output from JdbcFacadeA to go to the log for JobA, 
> and I want the 
> >>output from JdbcFacadeB to go to JobB's log.  I'm using the 
> log4j convention 
> >>for naming loggers, which uses the fully qualified class name.
> >> 
> >> How can I do this?
> >> 
> >> Thanks,
> >> 
> >> Robert Pepersack
> >> Senior Lead Developer
> >> Maryland Insurance Administration
> >> 410-468-2054
> >> 
> >> 
> >> 
> ---------------------------------------------------------------------
> >> 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]
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> 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]

Reply via email to