Simon Laws wrote:
On Mon, Apr 14, 2008 at 2:49 PM, Mark Combellack <[EMAIL PROTECTED]>
wrote:
Hi,
Whilst fixing a bug[1] I wanted to log an error message. I've realised
that
I'm not clear on Tuscany's policy on how this should be done.
I've had a look through the developer guides [2] and [3] (we have more
than
1?) but neither mention anything about logging.
To narrow the scope of this question a little bit, I am not talking about
tracing execution (method entry/exit). I am talking about logging runtime
errors.
Having a scan through the Developer Mailing List, I could not find
anything
conclusive on the subject. There was a discussion in August 2007 [4] that
seems to suggest the use of AOP and JDK Logging although no formal
decision
seems to have been made.
Looking through the code, there appears to be a few strategies for
logging:
*) Don't do any logging
*) Log to the Console - e.g. e.printStackTrace()
*) Use JDK logging.
The scenario I ran into in the bug [1] was that a @OneWay invocation has
thrown a RuntimeException (e.g. NullPointerException). The original
invoking
client is no longer around as a new Thread has been used to invoke the
@OneWay operation. The exception could just ripple up through and "kill"
the
thread but this is not very nice. What I want to do is log the Exception
so
the fact it happened can be recorded in a log.
From a personal perspective, I think we could consider using something
like
SL4J [5]. Tuscany is very likely to be integrated into other
applications/containers (e.g. Tomcat, WebSphere, etc) so SL4J would allow
the same Tuscany logging code to use different logging back ends (e.g.
log4j, JDK Logging, console, etc) depending on the environment in which it
is running.
So .... (takes a step back as he fears he might be opening a can of
worms).... what is the general opinion on how logging should be done in
Tuscany?
Thanks,
Mark
[1] https://issues.apache.org/jira/browse/TUSCANY-2225
[2] http://cwiki.apache.org/TUSCANY/sca-java-development.html
[3] http://cwiki.apache.org/TUSCANY/java-sca-developer-guide.html
[4] http://www.mail-archive.com/[email protected]/msg21735.html
[5] http://www.slf4j.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Mark
Funny you should mention this. Way back when (your [1]) we decided to go
with the JDK logger as there were so many opinions this seemed to be the
lowest common denominator.
After having used it for a while now, my preference is still for the JDK
logger for debug trace and logging.
As a slight aside I'm just now looking at the monitoring that goes on in
assembly where validation problem reports are collected and reported at a
later date rather than just logged out (well actually they are just logged
out at the moment by the monitor but I want to make it pluggable). There is
a discussion here [1]. I'm just about to check in a pass at separating out
the monitor to appreciate any comments. I'll post separately on this.
Simon, for monitoring (which I consider differently from
tracing/logging) the monitor discussed in [1] looks good to me.
I would only suggest to rename MonitorImpl to DefaultLoggingMonitor to
make clear that (1) it's a default impl that can be replaced and (2) it
logs.
Regards
Simon
[1] http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg30294.html
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
