Standard uses of log4j in designing business software

Question

I'm currently doing a research on the standard usage of the 5 levels of Log4j. My question is that is there a standard convention of which level to use when we program? Like should we use DEBUG more often than INFO? I understand that there are certain circumstances which require us to use a specific level. However, how about when we don't have the special cases; which level do we use usually (esp. when we write programs at the production level)? Is there a general concensus/convention/standard?
Also, what is a good approach/standard for logging entry and exit of the method?
I know that this might be a quite specific question. I'm also trying to find out what other programmers/companies are doing...(do they have a standard way of using it?) But It seems really hard to find exact information I'm looking for. If anyone could offer some outlets for finding the solutions to my question, that'd be great. Thank you.

Answer 1

This is a bit off-topic, since this forum is dedicated to Java Business Integration (JSR 208) specifically, rather than general business software topics. Also, JBI provides direct support for the standard Java logger. Other loggers can be used by JBI plug-in components, but these should be either adapted to the standard logger, or else the ability to correlate activity by multiple plug-in components will be lost, or at least made very difficult.
I'm not aware of a general consensus about use of logging levels, and separate loggers. In general, it is good to remember there are two separate audiences for logs:
- users, wishing to understand the behaviour of the application (particularly misbehaviour!)
- developers, wishing to understand the technical behaviour of the application.
There are two separate domains. The user needs to understand what is happening in terms of application domain concepts. The developer needs to understand what is happening in terms of implementation domain concepts. (In O-O these can intersect.)
For each type of logger audience, the various logging levels are used to develop a more and more detailed picture of application activities, as the level is increased to finer granularity. Each level should develop a coherent, consistent explanation of applicaition activity. It helps to have project guidelines about what should be logged at each level, so that levels are used consistently throughout an application.
The actual guidelines are a product of the application domain itself, pragmatism, and developer "taste." We've all seen logging systems that permit flexible, useful diagnosis of troubles experiences by production systems, and we've all seen counterexamples: logging systems that produce meaningless data, or that cripple the production system when turned on at the lowest logging volume. We tend of imitate those successful examples, and avoid repeating the failures.
There are academic studies of using program traces of a specific kind to help validate the program (i.e., the trace can be demonstrated to be coming from a correct or incorrect implementation). These studies don't look at logging levels, as far as I have seen: they assume a trace that is related to a formal model of the application, which is much different in purpose than most application logging.