date:20080407

Re: Log Utility

2008-04-07 Thread Maarten Bosteels

Or you can use log4j via SLF4J:

void *debug*(String
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html
format,
   Object
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html arg1,
   Object
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html arg2)

Log a message at the DEBUG level according to the specified format and
arguments.

This form avoids superfluous object creation when the logger is disabled for
the DEBUG level.

*Parameters:*format - the format stringarg1 - the first argumentarg2 - the
second argument
http://www.slf4j.org/api/org/slf4j/Logger.html#debug(java.lang.String,%20java.lang.Object,%20java.lang.Object)

Maarten

On Sun, Apr 6, 2008 at 10:46 PM, Jacob Kjome [EMAIL PROTECTED] wrote:


 How about LogMF or LogSF in Log4j's own Extras companion?

 http://logging.apache.org/log4j/companions/extras/index.html


 http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/LogMF.html

 http://logging.apache.org/log4j/companions/extras/apidocs/org/apache/log4j/LogSF.html


 Jake


 Wim Deblauwe wrote:

  You probably mean that you want to avoid expensive string concatenation
  and
  toString() operations if you logging is not logged anyway. There are a
  number of solutions to avoid that using
  log5jhttp://code.google.com/p/log5j/or
  logback http://logback.qos.ch/.
 
  regards,
 
  Wim
 
  2008/4/4, Tim Nguyen [EMAIL PROTECTED]:
 
   Thank you! It is similar to what I wanted to do. This is more like the
   solution for one class. Is there anyway to check for all classes? I
   have
   hundreds of classes and I want to have an util that I can just replace
   the
   current logging  (e.g: logger.debug(String)) with LogUtil (e.g:
   LogUtil.debug(String) and it does the trick. That way I can just
   replace
   All the logger with LogUtil :)
  
   Thanks again for your help!
  
  
   - Original Message 
   From: Robert Pepersack [EMAIL PROTECTED]
   To: Log4J Users List log4j-user@logging.apache.org
   Sent: Friday, April 4, 2008 12:14:30 PM
   Subject: Re: Log Utility
  
   Hi Tim,
  
   The Logger class has a way of checking the level first.
  
   First put this in your instance variables:
  
  private static final Logger logger =
   Logger.getLogger(my.package.MyClass);
  
  private final boolean debug = logger.isDebugEnabled();
  
   Then put this in your method:
  
  if (this.debug)
  {
  logger.debug(new String(test));
  }
  
   Hope this helps.
  
   Robert Pepersack
   Senior Lead Developer
   Maryland Insurance Administration
   410-468-2054
  
Tim Nguyen [EMAIL PROTECTED] 04/04/2008 3:02 PM 
 
 Hi,
  
   I am writing a Log Utility to check the log level first before
   creating a
   string object. For example, if my log level is INFO, and I call:
  
   log.debug(new String(test));
  
   It will still instantiate the String object even thought it doesn't
   log
   anything.
  
   So I would like to write an Utility to check the level first, if the
   log
   level is lower, then I don't have to instantiate the object and just
   skip
   it.
   Anybody knows what is the easy way to do that?
  
   Thanks,
  
  
  
  
  
  

   
   You rock. That's why Blockbuster's offering you one month of
   Blockbuster
   Total Access, No Cost.
   http://tc.deals.yahoo.com/tc/blockbuster/text5.com
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  
  
  
  
  
  

   
   You rock. That's why Blockbuster's offering you one month of
   Blockbuster
   Total Access, No Cost.
   http://tc.deals.yahoo.com/tc/blockbuster/text5.com
  
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Different Loggers for Different Instances of Same Class

2008-04-07 Thread Robert Pepersack

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]

Re: Different Loggers for Different Instances of Same Class

2008-04-07 Thread Jacob Kjome

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]

Re: Different Loggers for Different Instances of Same Class

2008-04-07 Thread Robert Pepersack

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]

Re: Different Loggers for Different Instances of Same Class

2008-04-07 Thread Bender Heri

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

Re: Different Loggers for Different Instances of Same Class

2008-04-07 Thread Robert Pepersack

Yes, I saw your posting of PMSRepositorySelector.  That's where I got the idea 
to use the MDC.  The twist is that I'm using the Spring IOC container to create 
instances of my classes, including my Quartz jobs (Spring has classes that 
support Quartz).  When the IOC container starts, it automatically creates 
instances of the jobs in its startup thread, and maintains the job instances 
as singletons (using the Spring singleton scope).  When the job instance is 
created, the logger for that job is created as an instance variable of the job. 
 Then, when a job is run (its trigger fires), a *new* thread runs the job.  So, 
how do I tell the RepositorySelector which hierarchy to choose for my other 
classes that a job uses?

Thanks.

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

 Bender Heri [EMAIL PROTECTED] 04/07/2008 2:39 PM 
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

logging to catalica out only

2008-04-07 Thread Kevin Gutch

Hi, I am new to log4J. I have several Contexts running under Tomcat and 
each has its own log4j.xml file in the classes folder. If I set the 
priority value to anything besides 'debug'I seem to get all of my 
logging and WARNings in the catalina.out file. The Context specific 
files are created but not written to.


Any idea why this might be?

Thanks in advance,

Kevin

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Log Utility

Re: Different Loggers for Different Instances of Same Class

Re: Different Loggers for Different Instances of Same Class

Re: Different Loggers for Different Instances of Same Class

Re: Different Loggers for Different Instances of Same Class

Re: Different Loggers for Different Instances of Same Class

logging to catalica out only

7 matches

Site Navigation

Mail list logo

Footer information