logging-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Womack <wom...@adobe.com>
Subject RE: Logging best practices?
Date Tue, 07 Dec 2004 17:03:22 GMT
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@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
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@mpi.com]
Sent: Tuesday, December 07, 2004 9:39 AM
To: Logging General
Subject: 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



This e-mail, including any attachments, is a confidential business
communication, and may contain information that is confidential, proprietary
and/or privileged.  This e-mail is intended only for the individual(s) to
whom it is addressed, and may not be saved, copied, printed, disclosed or
used by anyone else.  If you are not the(an) intended recipient, please
immediately delete this e-mail from your computer system and notify the
sender.  Thank you.


Mime
View raw message