commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomas Znamenacek <>
Subject [logging] API - methods for logging entry and exit events
Date Wed, 19 Jan 2005 02:26:31 GMT

This discussion thread is regarding proposed methods for logging method
entry and exit events.
For each issue I have found in previous discussions I'm offering my comment
or recommendation, if I have any.

1. Refactoring a method containing calls to log.enter() and log.exit(),
with hardcoded method name, will render these calls inaccurate.

Such refactoring is a feature of development tools and I see no point in
constraining an API because of tooling deficiency, even that it is a
concern from ease of use point of view. I'm sure the tools will adapt to
what developers need and until they do, the developers would need to use
Search/Replace functionality when refactoring methods/classes.
Also, in this case, AOP can help with a "around pointcut" that would
prevent execution of the original logging calls and execute proper ones,
where class name and method name are obtained at runtime(which means they
are always correct). This approach however is just a workaround because it
has a dependency on AspectJ.

2. Adding enter() and exit() methods is not necessary because the same can
be achieved with AspectJ using the methods on current Log interface.

The Aspect oriented programming certainly offers a great flexibility for
adding enter/exit logging calls without having to write them manually,
however, similar to previous point, the tooling ability should not prevent
us from defining a complete API that does not require the developer to use
a specific development tool/language in order to implement proper logging.

3. There is no clear difference between trace and debug level and adding
yet another trace level would not help in this situation.

Adding methods for logging enter and exit events will make the set of
tracing methods more complete and will bring more sense to using them. From
my experience I can see that interface with debug, trace and enter/exit
logging methods allows developers to produce more granular logging output
which is easier to work with during problem determination.

4. The event of method entry or exit is a trace kind of event and should
not be logged at different severity(should not have a method on the logging
interface) but it should be encapsulated in the message that is being
logged. Also, some enter/exit events might have more importance than
others, therefore the fact that an event represents enter or exit point
should be a state of the message not its severity.

The proposed interface will allow us to make a logging call for method
enter/exit event without having to create another object(message object)
and set the enter/exit flag on it.
If there is a logging implementation that allows the enter/exit be a flag
on message object, the wrapper for this implementation can certainly have
the enter/exit methods implemented that way.
When enter/exit events need to be logged on different levels, we start
talking about two dimensional space of logging events. Adding support for
this into a thin wrapper that is designed to bridge many(all?) different
APIs, will get too complicated and would loose the simplicity and ease of

5. The Log4J does not have methods for logging method entry/exit events. We
should not add those only because Java Logging has added them.

The JCL is a thin wrapper for many different logging implementations, not
only Log4J. Java Logging has added methods for logging entry/exit events
because they were identified as being useful for problem determination. Is
there something wrong with following their lead on this ?
I believe that by adding these methods to the interface will make the
interface easier to use, because the users-developers will not need to
write their own code constructing entry/exit messages, if they require
those to look consistent within their application/component.

6. Adding more than one enter() method will make the interface too big.

The current Log interface contains two methods for each level and based on
situation (normal code path or exception code path) the developer can
choose the proper one to use. The proposed interface also provides multiple
methods for logging entry and exit events, each one for different
situation. It seems to be following the same pattern.
If we decide on keeping the interface small, then the enter() methods could
be consolidated to one, with following signature:
            enter(Class clazz, String methodName,
                  Object[] methodArgs,
                  Object message);

7. Instead of obtaining class name from the Class object that is passed in,
the class name could be obtained from current execution stack.

This approach is expensive and inaccurate. In order to obtain the current
stack trace, a Throwable object has to be created. Once the current stack
trace has been obtained, the calling class has to be located in the stack
and there is no way to identify which class is the real caller, because the
developers might have implemented their own logging helper classes, which
will show up in the stack trace as well. Java Logging implementation has
this problem.

8. Adding a parameter of type Class will result in more Class objects being
created and more Class.getName() calls being made.

When the call is made, the Class object is already instantiated and the
getName() call will most likely be eliminated by a JIT compiler. Also,
passing the Class object in to the logging methods, will effectively avoid
the inaccurate logging entries, which could be created during class


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message