On 8/20/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> 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]
I agree that entry and exit tracing can be overwhelming in a lot of
situations. I think this is an advantage of taking the AspectJ approach. If
people want to add this kind of tracing then we can make that possible with
no direct impact on the tuscany code base.
A concrete proposal for other messages...
I've been poking around to see what others do and, on closer inspection, CXF
have a rather nice, IMHO, approach which is a combination of a home grown
logging util class and the JDK logger that.
uses parameters to reduce the formatting load for inactive log statements
uses message property files for message lookup
encompasses basic internationalization support using ICU and the message
files behind the scenes
handles exceptions and strings (although it doesn't localize exception
strings)
SLF4J does very similar things to this but we didn't seem to get much
traction with that before on this thread. It seems that we all have
different requirements for reducing dependencies vs providing logging
function. If we can reach a satisfactory level of function while relying on
the built in JDK logging features then that seems to be a good compromise.
Also with some home grown utilities we can at least make life a little
easier for ourselves in terms of recording user oriented messages related to
model elements.
Looking at the CXF code this is what you build.
MyModule
src
main
java
somepath
SomeTuscanyClassA
Messages.properties
resources
logging.properties
Nothing too surprising there. They have a LogUtil class (see
cxf-common-utilities) which provides an interface for getting JDK loggers
and for logging with them. I'm assuming they created it but we should check.
Here is an example of how to use it.
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.cxf.common.logging.LogUtils;
public class SomeTuscanyClassA {
private static final Logger Log1 = LogUtils.getL7dLogger (
SomeTuscanyClassA.class);
public SomeTuscanyClassA() {
Integer params[] = {8, 9, 4};
LogUtils.log(Log1,
Level.INFO,
"TEST_MESSAGE",
null,
(Object[])params);
Exception ex = new IllegalStateException("some exception string");
LogUtils.log(Log1,
Level.INFO ,
"TEST_MESSAGE",
ex,
(Object[])params);
}
We could then extend this to allow for common Tuscany situations. For
example, by allowing a model element to be passed in,
LogUtils.log(Log1,
Level.INFO,
composite, // or some other specialization of Base
where the component name, uri can be read from
"TEST_MESSAGE",
null,
(Object[])params);
We could then chose to use
SEVERE
WARNING
INFO
CONFIG
To record our end user readable information. This proposal assumes people
are comfortable with committing to JDK logging. If people are comfortable
with this then I don't see why we can't use.
FINE
FINER
FINEST
for mid method tracing.
So is this going in the right direction? Or do people have completely
different approaches in mind?
Regards
Simon
