I got thinking about creating a custom RepositorySelector, because that's what 
the book suggests.  Also, I want to keep using the log4j convention of using 
the fully qualified class name to name my loggers.  That way I can manage the 
loggers in each hierarchy as everyone else does.  Also, I'm using a library of 
classes that I don't want to have to change. 

I mentioned MDC, because I saw an example RepositorySelector that uses the MDC 
to determine which hierarchy a logger belongs in.  Here's the URL for the 
example:

http://mail-archives.apache.org/mod_mbox/logging-log4j-user/200602.mbox/[EMAIL 
PROTECTED]

Is there another way?

Robert Pepersack
Senior Lead Developer
Maryland Insurance Administration
410-468-2054

>>> "Jacob Kjome" <[EMAIL PROTECTED]> 04/07/2008 1:42 PM >>>
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