[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.
A few more questions on this: What dependencies will aspectj add to our
distribution? aspectjweaver is more than 1Mb, do we need it?
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?
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.
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.
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]
