Zsolt Koppany | 2 Dec 2004 11:39

How to send messages of a class into one and only to one appender with log4j?

Hi,

How can I store the log messages of "cv.parser_db_log" only to appender
"parser_db_file"? Right now messages sent to "parser_db_file" will be also
stored into "A2" and "A1".

I use log4j-1.2.8.

My configuration:

log4j.rootCategory=DEBUG, A2, A1
...

log4j.category.cv.parser_db_log=INFO,parser_db_file

Zsolt

Moynihan, Edward | 7 Dec 2004 15:28

Logging best practices?

Hi, 
Can someone provide advice or best practice for this problem? We use the Spring framework (v1.0) and have
the following setup in our web.xml to initiate logging 

<context-param> 
<param-name>log4jConfigLocation</param-name> 
<param-value>/WEB-INF/conf/log4j.properties</param-value> 
</context-param> 

This is fine and has been working for us. However, now we are moving into managed regions, which equate to a
test, qa and prod regions. The problem now becomes a question of managing the logging level depending on
what region we are in. 

We do not have the ability to change the application property files once it moves into Test and all files from
Test get moved up to QA. All files from QA eventually move up to Prod. So, as you can see, if we turn on logging
in Test, then that logging will be on in Prod, which we do not want. 

We know what region we are in because we start the application server up with a System property that we can
access. This tells us what region we are in. So we are thinking we will have 4 versions of the
log4j.properties file, with the following directory structure 

/WEB-INF/conf/dev/log4j.properties 
/WEB-INF/conf/test/log4j.properties 
/WEB-INF/conf/qa/log4j.properties 
/WEB-INF/conf/prod/log4j.properties 

Is this the correct approach? I presume I will have to customize
org.springframework.web.util.Log4jConfigServlet. I'm interested in your thoughts. 

Thanks. 
(Continue reading)

Shapira, Yoav | 7 Dec 2004 15:38

RE: Logging best practices?


Hi,
You're asking for best practices, right?

>This is fine and has been working for us. However, now we are moving
into
>managed regions, which equate to a test, qa and prod regions. The
problem
>now becomes a question of managing the logging level depending on what
>region we are in.
>
>We do not have the ability to change the application property files
once it
>moves into Test and all files from Test get moved up to QA. All files
from
>QA eventually move up to Prod. So, as you can see, if we turn on
logging in
>Test, then that logging will be on in Prod, which we do not want.

This is far from a best practice.  It is expected that code and tests
remain the same across environments, but configuration is subject to
change.

You could consider programmatic configuration that takes into account
the environment, but the best solution is to have a different log4j
configuration file for each environment to fit your needs for that
environment.  You can have your build script fill in relevant things
automatically by using Ant filter tokens, for example.

Yoav Shapira http://www.yoavshapira.com
(Continue reading)

Moynihan, Edward | 7 Dec 2004 17:06

RE: Logging best practices?

   While I understand and appreciate your comments, I unfortunately have to work within the framework that I
outlined.  

   To summarize, when I create a WAR file, it must contain the difference logging levels for all managed
regions.  In this case, those regions are Test, QA and Prod.  I am working within the application server
administrators policy and there policy states that one build will be performed to Test.  That build will be
moved in its entirity to QA.  The files in QA will be moved in their entirity to Prod.  I do not have the
opportunity to build a release specific to QA or to Prod.

   To know what region we are working with, the application server is started up with a system property that we
can interrogate.  So with that information, is there are a way that I can easily implement logging specific
to regions?

   Someone on the Spring Framework board suggested the following;

     "I think that log4j also allows system property substitution in its properties files so you could have
something like:

      Code:
      log4j.rootCategory=${region.logLevel}, A1

      And then set region.logLevel as a system property."

-Ed.

-----Original Message-----
From: Shapira, Yoav [mailto:Yoav.Shapira <at> mpi.com]
Sent: Tuesday, December 07, 2004 9:39 AM
To: Logging General
Subject: RE: Logging best practices?
(Continue reading)

Shapira, Yoav | 7 Dec 2004 17:09

RE: Logging best practices?


Hi,
Yeah, you could do this system property - driven approach.

Another alternative is to configure log4j programmatically, going off
your own configuration file, not the log4j-formatted one.  Your file
might look like:
logging.development.file = ...
logging.development.rootLevel = ...

And then your code would read this file and configure log4j
programmatically according to a single system property or other
indicator which tells you what the environment is.

Yoav Shapira http://www.yoavshapira.com

>-----Original Message-----
>From: Moynihan, Edward [mailto:EMoynihan <at> russellmellon.com]
>Sent: Tuesday, December 07, 2004 11:06 AM
>To: Logging General
>Subject: RE: Logging best practices?
>
>   While I understand and appreciate your comments, I unfortunately
have to
>work within the framework that I outlined.
>
>   To summarize, when I create a WAR file, it must contain the
difference
>logging levels for all managed regions.  In this case, those regions
are
(Continue reading)

Mark Womack | 7 Dec 2004 18:03
Picon
Favicon

RE: Logging best practices?

Ed,

I think your idea of using a system property to somehow choose the log4j
configuration to use for the region deployment is the right way to go.  Then
you can reuse your war across all of your regions, but you will need to
package all of the region configurations in the war.  At least it will be
the same build across all of the regions, and the only difference should be
the configuration, which hopefully will not affect your runtime behaviors
being tested (just the output of the log messages).

I am not familiar with the level of support in Spring, but besides an init
servlet, you may also want to consider including a configuration servlet so
that log4j settings can be changed during runtime.  There is an example of a
simple, evolving version in the log4j-sandbox repository.

-Mark

-----Original Message-----
From: Moynihan, Edward [mailto:EMoynihan <at> russellmellon.com] 
Sent: Tuesday, December 07, 2004 8:06 AM
To: Logging General
Subject: RE: Logging best practices?

   While I understand and appreciate your comments, I unfortunately have to
work within the framework that I outlined.  

   To summarize, when I create a WAR file, it must contain the difference
logging levels for all managed regions.  In this case, those regions are
Test, QA and Prod.  I am working within the application server
administrators policy and there policy states that one build will be
(Continue reading)

ceki | 8 Dec 2004 18:47
Picon
Favicon

cvs commit: logging-site/src/xdocs/site who-we-are.xml

ceki        2004/12/08 09:47:54

  Modified:    docs/site who-we-are.html
               src/xdocs/site who-we-are.xml
  Log:

  Added Nicko and Curt to who-we-are. Changed my bio.

  PR:
  Obtained from:
  Submitted by:	
  Reviewed by:	

  Revision  Changes    Path
  1.19      +15 -2     logging-site/docs/site/who-we-are.html

  Index: who-we-are.html
  ===================================================================
  RCS file: /home/cvs/logging-site/docs/site/who-we-are.html,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- who-we-are.html	22 Nov 2004 18:18:12 -0000	1.18
  +++ who-we-are.html	8 Dec 2004 17:47:54 -0000	1.19
   <at>  <at>  -55,6 +55,19  <at>  <at> 
                                                         <h1>PMC members</h1>
                                                         <ul>

  +
  +  <li><b>Curt Arnold</b> 
(Continue reading)

Ceki Gülcü | 8 Dec 2004 18:56
Picon
Gravatar

Single "Who we are" page for all Logging Services developers


Hello,

I would like to invite all Logging Services developers to add their
biography to our "who we are" page.

   http://logging.apache.org/site/who-we-are.html

For updating the Logging Services site, see:

   http://logging.apache.org/site/logging-site.html

--

-- 
Ceki Gülcü

  The complete log4j manual:  http://qos.ch/log4j/  

yoavs | 8 Dec 2004 19:04
Picon
Favicon
Gravatar

cvs commit: logging-site/src/xdocs/site who-we-are.xml

yoavs       2004/12/08 10:04:38

  Modified:    docs/site who-we-are.html
               src/xdocs/site who-we-are.xml
  Log:
  Updated my bio.

  Revision  Changes    Path
  1.20      +4 -5      logging-site/docs/site/who-we-are.html

  Index: who-we-are.html
  ===================================================================
  RCS file: /home/cvs/logging-site/docs/site/who-we-are.html,v
  retrieving revision 1.19
  retrieving revision 1.20
  diff -u -r1.19 -r1.20
  --- who-we-are.html	8 Dec 2004 17:47:54 -0000	1.19
  +++ who-we-are.html	8 Dec 2004 18:04:38 -0000	1.20
   <at>  <at>  -110,11 +110,10  <at>  <at> 
       <table>
         <tr><td>

  -      <p>Yoav Shapira works for Millennium Pharmaceuticals and is as
  -      interested in the business aspects of Open-Source Software as he
  -      is in the technical aspects. Yoav contributes to the Tomcat
  -      container, the Log4j logging system, and a number of
  -      jakarta-commons and other open-source projects.</p>
  +      <p>Yoav Shapira contributes numerous Apache and other open-source
  +      projects: you can read more about him at 
  +      <a href="http://www.yoavshapira.com">YoavShapira.com</a>.
(Continue reading)

Pradeep Jonnalagadda | 9 Dec 2004 16:36
Picon

Question on logging

Guys,
      We want to use log4j and chainsaw.From the website it seems
like log4j1.3 is the version i need to use to use chainsaw v2.When is
log4j v1.3 expected to be released( i know currently alpha is
released).Is it advisable to use alpha version and later use the final
version when it is released.
Or is it a good idea to use log4j current version and a previous
version of chain saw.If so where can i get the previous version of
chain saw and is it compatibale with the current version of log4j
pradeep


Gmane