See inline.
Simon
Raymond Feng wrote:
Comments inline.
Thanks,
Raymond
----- Original Message ----- From: "Jean-Sebastien Delfino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, August 17, 2007 9:27 AM
Subject: Re: Monitoring, logging and exceptions (again)
[snip]
ant elder wrote:
And also my 2p inline...
...ant
On 8/16/07, Simon Laws <[EMAIL PROTECTED]> wrote:
A number of different requirements have been discussed and solutions
proposed. My 2p (I'm using Raymond's definitions b.t.w)
Tracing: Dump out input/output/exception for method calls for the
purpose
of
debugging/troubleshooting. (Target for developers/technical support)
I feel that tracing of execution paths through the Tuscany codebase
would
be
useful but agree that " it's a lot of work and will be difficult to
maintain
and keep consistent" if we did it manually. I'm happy that this is the
responsibility of whoever wants to trace through the code and not a
core
part of the codebase. For the Tuscany developer community AspectJ have
been
proposed a couple of times and support has been prototyped. We could
choose
SLF4J as the interface through which messages are output.
I'm not sure we need to use SLF4J if we go the AspectJ route. SLF4J is a
facade for logging APIs, so you can code to the SLF4J API and then
plug in
whatever logging impl you like, but if the only logging calls we have
are
confined to a single tracing aspect we might as well just code that
aspect
to a specific logging API like JDK logging. That avoids the extra
dependency
on SLF4J and anyone can add additional aspects if they really want to
use a
different logger. The main other benefit of SLF4J is its parameterized
message logging (avoids all the "if(logger.isDebugEnabled())" ) but
again if
all the logging calls are in a single aspect thats not so useful.
Makes sense to me. If we go the aspectj route for tracing method
entry/exit, I agree that using the JDK logger directly is simpler.
Since the aspect is on the side, we're flexible. JDK logger can be
default and it can be replaced easily if the embedders or users choose
to do so.
A few more questions on this: What dependencies will aspectj add to
our distribution? aspectjweaver is more than 1Mb, do we need it?
I'll try to spend some time to explore both the compile-time and
load-time weaving.
What about mid-method logging of specific interesting events, for
example
the contents of requests as the enter and leave bindings and
implementation
types and things like that? That sort of logging is often all a lot
of users
want to see not the detail tracing of every method entry/exit. Could
we add
things like this in specific places?
+1 for the ability to produce this level of information. This is my
preferred approach for debugging or understanding how some part of the
code works. Having every method entry and exit produce a trace line
often creates a huge amount of output that obscures the essential details
of what is happening.
Can this mid-method logging be split in two categories?
a) Debug tracing
A simple solution is to split the method in two, and then leverage the
entry/exit method tracing as discussed above.
In many cases this would lead to a convoluted code structure with local
variables needing to be passed as parameters between the two methods, or
methods that contain a single line of code (if a trace line needs to be
produced from within a loop).
We can use JDK logger to add statements in the middle of a method. Then
we can use an aspect to capture such calls to dump out the information.
For example, if we have the following statement in a method:
logger.debug(...);
The apsect can trap it by a point cut like "call *
java.util.logger.Logger.debug(..).
If the logger call is already there, why is an aspect needed to trap it?
Why not just let it execute?
b) End-user readable information (info that a binding is
sending/receiving a message for example)
This falls into the second category discussed in this thread,
reporting significant events to a management console.
The above suggestion should help too. The key here is to have some calls
to indicate such requirements and they can be then trapped to provide
the concrete logic.
I think we're starting to see concrete solutions for (a) with aspectj.
I have not seen any real concrete proposal for (b) yet.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
