You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Tomas Znamenacek <to...@ca.ibm.com> on 2005/01/19 03:26:31 UTC
[logging] API - methods for logging entry and exit events
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
use.
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
refactoring.
Tomas
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] API - methods for logging entry and exit events
Posted by Emmanuel Bourg <eb...@apache.org>.
Tomas Znamenacek wrote:
> 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
> use.
Indeed, it's still possible with:
if (log.isDebugEnabled()) {
log.enter(this, "foo");
}
There is no need for a "level" parameter on the enter/exit methods.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] API - methods for logging entry and exit events
Posted by Richard Sitze <rs...@us.ibm.com>.
Emmanuel Bourg <eb...@apache.org> wrote on 01/19/2005 06:16:35 AM:
> 9. Logging entry/exit event is not so common and I'd better write
directly:
>
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
>
> rather than
>
> log.enter(this, "foo", new Object[] { param1, param2 }, "Entering");
>
> enter()/exit() doesn't make the code much shorter, it provides just a
> more detailed semantic.
1. But more than just an alternate to debug. For loggers that "support"
it, it would be mapped to a different logging level [i.e. JSR-47 "FINER"].
If we were to follow the guidelines described in the current JCL users
guide for "debug" level logging, and map those over to include the
entry/exit method "level", then best practices for JCL would be:
a) log.debug() to be used as we cross component
boundries, allowing a high-level
view of the flow between multiple
components. Also reasonable to
log "interesting" events/information
that are meaningfull at a
component level.
b) log.entry/exit() would be used as we cross
class and method boundries,
allowing a view of the flow
between and within classes
within a component.
c) log.trace() would be used to provide additional
detail reflecting flow and information
within a method.
And by having these on separate levels [for those impls
that support the levels], you could enable
(a), (a)+(b), or (a)+(b)+(c).
2. Just FYI, the [conceptual] equivalent to
log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
would be
log.enter(this, "foo", new Object[] { param1, param2 }, null);
Specifically,
Log.enter(Class clazz,
String method,
Object[] params,
String additionalText)
is intended to be mapped to the logger, and it is expected that the logger
impl would express that as something similar to:
"Entering " + clazz.getName() + "." + methodName + "(" + params + ") "
+ additionalText
[please consider that psuedo-code... there are details missing I know :-)]
> Emmanuel Bourg
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Re: [logging] API - methods for logging entry and exit events
Posted by Richard Sitze <rs...@us.ibm.com>.
Emmanuel Bourg <eb...@apache.org> wrote on 01/19/2005 06:16:35 AM:
> 9. Logging entry/exit event is not so common and I'd better write
directly:
>
> log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
>
> rather than
>
> log.enter(this, "foo", new Object[] { param1, param2 }, "Entering");
>
> enter()/exit() doesn't make the code much shorter, it provides just a
> more detailed semantic.
1. But more than just an alternate to debug. For loggers that "support"
it, it would be mapped to a different logging level [i.e. JSR-47 "FINER"].
If we were to follow the guidelines described in the current JCL users
guide for "debug" level logging, and map those over to include the
entry/exit method "level", then best practices for JCL would be:
a) log.debug() to be used as we cross component
boundries, allowing a high-level
view of the flow between multiple
components. Also reasonable to
log "interesting" events/information
that are meaningfull at a
component level.
b) log.entry/exit() would be used as we cross
class and method boundries,
allowing a view of the flow
between and within classes
within a component.
c) log.trace() would be used to provide additional
detail reflecting flow and information
within a method.
And by having these on separate levels [for those impls
that support the levels], you could enable
(a), (a)+(b), or (a)+(b)+(c).
2. Just FYI, the [conceptual] equivalent to
log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
would be
log.enter(this, "foo", new Object[] { param1, param2 }, null);
Specifically,
Log.enter(Class clazz,
String method,
Object[] params,
String additionalText)
is intended to be mapped to the logger, and it is expected that the logger
impl would express that as something similar to:
"Entering " + clazz.getName() + "." + methodName + "(" + params + ") "
+ additionalText
[please consider that psuedo-code... there are details missing I know :-)]
> Emmanuel Bourg
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Re: [logging] API - methods for logging entry and exit events
Posted by Emmanuel Bourg <eb...@apache.org>.
9. Logging entry/exit event is not so common and I'd better write directly:
log.debug("Entering MyClass.foo(" + param1 + ", " + param2 + ")");
rather than
log.enter(this, "foo", new Object[] { param1, param2 }, "Entering");
enter()/exit() doesn't make the code much shorter, it provides just a
more detailed semantic.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] API - methods for logging entry and exit events
Posted by Richard Sitze <rs...@us.ibm.com>.
Eclipse makes search/replace of strings during refactoring "optional".
It's certainly easy enough to manage there.
Emmanuel Bourg <eb...@apache.org> wrote on 01/19/2005 06:22:29 AM:
> Tomas Znamenacek wrote:
>
> > 1. Refactoring a method containing calls to log.enter() and
log.exit(),
> > with hardcoded method name, will render these calls inaccurate.
>
> I don't know how the Eclipse refactoring works, but at least for
> IntelliJ there is no problem here. With:
>
> public void foo() {
> log.enter(this, "foo");
> }
>
> Renaming the method will automatically change the string.
>
> Emmanuel Bourg
>
*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development
Re: [logging] API - methods for logging entry and exit events
Posted by Emmanuel Bourg <eb...@apache.org>.
Tomas Znamenacek wrote:
> 1. Refactoring a method containing calls to log.enter() and log.exit(),
> with hardcoded method name, will render these calls inaccurate.
I don't know how the Eclipse refactoring works, but at least for
IntelliJ there is no problem here. With:
public void foo() {
log.enter(this, "foo");
}
Renaming the method will automatically change the string.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org