Re: what to log - API questions :)
Maybe you need to look at AspectJ and Aspect Oriented Programming in general to address this cross-cutting concern? regards, Wim 2008/6/13 Christophe Elek [EMAIL PROTECTED]: They are great discussion :) I really enjoy reading them :) I have one on my own. My goal in IBM Rational is to ensure all products have a consistent set of logging so we can correlate the logs of all the products. Some are legacy products, some are new products. Developers and Architect always ask me... 'Chris, really, do I have to create the 4 Logger in each of my class and then figure out which logger to call ? This is crazy... Can't I just have an API like this MyComponent.log(String,Exception) ?' My answer to them is that the component owner must create the API and I see the following API 1) MyComponent.createLogRecord(String messageKey,Object[] parametersMessage,int severity,Throwable exception) 2) MyComponent.error(MyLogRecord) or MyComponent.audit(MyLogRecord) or MyComponent.traceHttp(MyLogRecord) What do you think the minimal set of API should be ? Or should we force our developers to become expert of Log4J ? I know I can explain to them the value of logging, the value of software engineering, quality of code...and so on... but seriously, If we come up with a very simple set of API...wouldn't that make this discussion between the developer and me easier ? Christophe Elek - Senior Software Analyst IBM Rational Serviceability Architect IBM Toronto Lab 8200 Warden Avenue, Markham, Ontario, L6G 1C7 Phone Number: (905) 413-3467 Email: [EMAIL PROTECTED] Don't just fix the mistakes - fix whatever permitted the mistake in the first place. Charles Fishman
RE: log4j best practises
RE: I think logs should be normalized and the UI viewers can be
adjusted by the human wherever he/she is located to display the
local times.
This sounded like a good idea, so I added it to Chainsaw as a per-tab
preference. Will show up in the next Chainsaw release (whenever that is).
Scott Deboy
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Telephone: 503.224.7496
Cell: 503.997.1367
Fax:503.222.0185
[EMAIL PROTECTED]
www.comotivsystems.com
-Original Message-
From: Wascally Wabbit [mailto:[EMAIL PROTECTED]
Sent: Sun 6/15/2008 7:28 AM
To: Log4J Users List
Subject: Re: log4j best practises
Hi Julius,
My 2cents from mostly a let's help the support staff view:
-The Wabbit
Greppable Logs
[+ Separate files of different areas of interest]
To me this eliminates a whole world of log diagnostic tools.
Limiting support tools to 'grep' makes sense of very controlled
applications on dedicated hardware/systems. If however, your
company invests $$$ into additional logging tools, application
developers should ensure their logs can feed into these systems
as well. (If your application is one of many that interact in
a long-lived or distributed transaction for instance, support
needs to walk the transaction through other applications not
just yours even if they're all housed on the system back-end.)
Having said that...I agree with the premise that log statements
meant for support should have a planned consistent pattern to
them if possible.
Always log to a local disk.
[+ Separate files of different areas of interest]
I think you're assuming a single use for log4j. Example:
I've used log4j as the foundation of a usage tracking system that
has worked perfectly in a cross-machine/cross-location/clustered
web services deployment. Using a disk-based sink would have been
a pretty bad idea (speed/sync aside, the cost of the (SAN)disk
and other HA/DR requirements far exceeded the code of additional
db storage). I find local-disk a good sink for turn everything
on modes but by no means a best-choice for all kinds of logging.
Timestamps
I actually disagree with the timezone customization option. I
think logs should be normalized and the UI viewers can be
adjusted by the human wherever he/she is located to display the
local times. I suppose like the 'greppable' logs, it's a matter
of complexity of the application(s) and tools available to
the support staff.
Use Log4j 1.2.x (or a competitor)
You're missing slf4j+friends heresome interesting bits wrt
eliminating the horrid: if (isDebugEnabled(...)) { ... } crud.
Also the ability to dynamically create filters. Now *that's*
interesting.
Programming with log4j
Every class must contain this line:
private static Logger log = Logger.getLogger( MyClass.class )
Oh lord, please no! Why would I have a Logger in my exception
classes? Put loggers where they're explicitly used and no place
else. You can't magically start using loggers that are declared
but never used (the compilers are probably just stripping these
unused things out anyway...)
DO NOT: create a single class com.foo.app.Log and run
all logging calls through that! You are severely impairing
log4j's flexibility if you do that.
This to me is a weird statement. Log4J is a tool that helps you
implement your strategy for logging. If that strategy works with
a single log class so be it. Log4J works with name hierarchies
-- the fact that the original examples used class names to
indicate hierarchy has become this myth of implementation using
log4j. Configuration is linked to the logger/category not the
class; the developer creates that coupling not log4j. Log4J's
own MDC is an example of a logging pattern that is not
hierarchy bound. I also use task-based logging (a logger
that transcends a single class but is linked to a set of classes
-- or instances-- performing a single task) to good effect daily.
Logging Exceptions...[sending stacktraces to a separate log]
This might be accomplished more cleanly using a custom
filter and appender that tees the exception to an additional
appender...just a thought...no idea how it would work.
Cosmetic considerations
You might just try padding the more human-readable level
labels to take up the same (mono)spaces:
'DEBUG', 'INFOM', 'WARNG' 'ERROR' 'FATAL' 'TRACE'
Also just create a custom Level object and use that in your
log4j configuration instead of altering log4j levels directly.
A Log Rotation Best Practice That Is Currently Not Possible
I don't see why you cannot do most of this today yourself?
If you can change log4j's level labels, why can't you just on
application startup log some information? Am I missing something
here? If it's a WAR put in a lifecycle listener; if an EAR
put in a bootstrap servlet no? Perhaps you could
extend the current rotating log file appender to do the custom
stamp also?
HTH
-
To
RE: Recommended way of getting a logger
There might be a problem if you use your own RepositorySelector wich maintains different Repositories depending on some context (MDC etc.). Utility classes whose methods can run in different contexts should fetch the logger each time where it is used. Heri -Original Message- From: Jiri Pejchal [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 5:57 PM To: log4j-user@logging.apache.org Subject: [SPAM (DNS Blacklist)] - Recommended way of getting a logger - Sending mail server found on relays.ordb.org Hi, is there any real difference between getting logger each time a message is being logged by calling Logger.getLogger() : Logger.getLogger(getClass()).info(message); and putting logger as a class member: final Logger logger = Logger.getLogger(getClass()); and than in methods use: logger.info(message); I have an older web application that uses the first form and I'm just wondering if I could use the second form without consequences. Thanks. Jiri Pejchal - 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: what to log
I do not agree to yours Logs are not for debugging. In heavy loaded multithreaded applications it could be the only way to debug. The DEBUG level IS definitively for debugging purpose. In production, I agree, the level should be INFO or higher. Heri -Original Message- From: Julius Davies [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 8:18 PM To: Log4J Users List Subject: [SPAM (DNS Blacklist)] - what to log - Sending mail server found on relays.ordb.org Richard J. Barbalace wrote the following in the best practises thread: --- [...] Do NOT log valuable information. By valuable, I mean information that has value to the organization or the users, as opposed to the developers. For instance, in medical applications, you should not log personal health information (PHI). This is hopefully obvious, but I would never want to see this in a log: 2004-09-28/18:37:35.138/PDT - Submitted POSITIVE result for HERPES test for patient SMITH. That could violate the HIPAA law, create a severe privacy breach if someone unauthorized reviewed your log, and might include information that the developer is not even legally permitted to see. As another example, in a banking system, you should not log personal account details, social security numbers, etc. to a file whose only purpose is for debugging. Thankfully, in most cases, the exact personal details are not necessary for debugging an application. --- Logs are not for debugging. That's the least important side of logging. (Unfortunately in the java world, debugging is where most of the logs are focused!) I think of logs as an intense write-always, read-rarely database. So I log 5TB of data over a year because my client might need to look at 1KB when something serious happens. As for what to log, look at the real life situation: - The doctor can see the patient's chart (same for doctor's staff). - The lab technician can see the lab's correspondence with the doctor (same for lab's staff). - Additional people probably have access to the information through the lab's software systems, and the doctor's software systems. I don't see why the log shouldn't be able to store similar information. Of course access to the log should be controlled. When I worked at a credit union, the production logs were tightly controlled. Only a few select people had access to specific logs, and developers, almost always, never had access. Probably logs should have the same security, privacy, and access controls around them that one would apply to the database (and its hard-drive). In the end it's just information on a hard-drive. If we go down the path you're suggesting, one should also not store this information in a database! On the other hand, I strongly believe in not logging valuable information when there is no need to log it. Logging a customer's bank balance is never useful. But logging the fact they made a bill payment for $5,000 can be useful if they call up later after something goes wrong. In other words, log important state changes, but don't log the state. If a patient's state changed from healthy to herpes, I would log that. (What if the computer made a mistake? The log will help!) You also can't log information if you promise your customers you will never retain it (or even see it), like a password. Logs are not for developers. Like the rest of the application, they are written by developers, and used by everyone else. In the case of logs the users are usually: sysadmins, customer support, security auditors, lawyers, and occasionally the police! -- yours, Julius Davies 250-592-2284 (Home) 250-893-4579 (Mobile) http://juliusdavies.ca/ - 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: Unable to display caller name in log info
The FQCN is used for determinating the class which issued the log call.
The log framework produces a callstack and searches backwards until it
has found the supplied FQCN. The next entry is then taken for expanding
the %C pattern in the layout.
Normally, if you use the myLogger.debug() (et al.) methods, the Logger
class inserts its own FQCN on calling the generic method. That's why the
calling class will show up in the rendered log message. Make use of the
generic method log() only if you use a centralized log wrapper class.
Then you would supply the FQCN of that wrapper class in order to render
the name of the class which has called the wrapper.
Your example supplies a file name as FQCN. This string cannot be found
within the stack trace, so the routine climbs up until the main method
of the main class. Nothing found - ?.
If you want to see LogTest as %C replacement, you have to supply
LogText.getClass().getName() as FQCN.
Heri
-Original Message-
From: Debarshi Sanyal [mailto:[EMAIL PROTECTED]
Sent: Monday, June 16, 2008 8:42 AM
To: log4j-user@logging.apache.org
Subject: [SPAM (DNS Blacklist)] - Unable to display caller
name in log info - Sending mail server found on list.dsbl.org
Hi,
I wrote a small Java program to configure an
org.apache.log4j.Logger and log messages using it.
Excerpts from the Java file are:
package MyPackage;
//...
public class LogTest
{
private static Hashtable cLoggerHash = new Hashtable();
private void setLogInfo()
{
String sLogFile = TestLogFile.log;
Logger cLogger = Logger.getLogger( sLogFile );
cLogger.setLevel( Level.toLevel(DEBUG) );
PatternLayout cLayout = new PatternLayout();
cLayout.setConversionPattern( [%d{/MM/dd
HH:mm:ss.SSS}]%C -
%m%n );
RollingFileAppender cFileAppender = new RollingFileAppender();
//...
cFileAppender.activateOptions( );
cFileAppender.setLayout( cLayout );
cLogger.addAppender( cFileAppender );
cLoggerHash.put( sLogFile, cLogger );
}
public static void main (String[] args)
{
LogTest logTest = new LogTest();
logTest.setLogInfo();
Logger cLogger = Logger.getLogger( TestLogFile.log );
cLogger.log(TestLogFile.log, Level.INFO, \t
++ This is a test log + , null);
}
The output is:
[2008/06/13 20:24:53.415]? - ++ This is a test log
+
The fully qualified classname is NOT displayed.
Instead a ? is displayed.
Please help.
Regards,
Debarshi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unable to display caller name in log info
First, it's unusual to name your logger after the name of the log file you
expect it to go to. But I guess that's up to you. Your real problem is
probably that you haven't compile your classes with debug info (the java -g
option).
Jake
On Mon, 16 Jun 2008 12:11:37 +0530
Debarshi Sanyal [EMAIL PROTECTED] wrote:
Hi,
I wrote a small Java program to configure an org.apache.log4j.Logger and log
messages using it.
Excerpts from the Java file are:
package MyPackage;
//...
public class LogTest
{
private static Hashtable cLoggerHash = new Hashtable();
private void setLogInfo()
{
String sLogFile = TestLogFile.log;
Logger cLogger = Logger.getLogger( sLogFile );
cLogger.setLevel( Level.toLevel(DEBUG) );
PatternLayout cLayout = new PatternLayout();
cLayout.setConversionPattern( [%d{/MM/dd HH:mm:ss.SSS}]%C -
%m%n );
RollingFileAppender cFileAppender = new RollingFileAppender();
//...
cFileAppender.activateOptions( );
cFileAppender.setLayout( cLayout );
cLogger.addAppender( cFileAppender );
cLoggerHash.put( sLogFile, cLogger );
}
public static void main (String[] args)
{
LogTest logTest = new LogTest();
logTest.setLogInfo();
Logger cLogger = Logger.getLogger( TestLogFile.log );
cLogger.log(TestLogFile.log, Level.INFO, \t ++ This
is a test log + , null);
}
The output is:
[2008/06/13 20:24:53.415]? - ++ This is a test log
+
The fully qualified classname is NOT displayed.
Instead a ? is displayed.
Please help.
Regards,
Debarshi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
