ant elder wrote:
On 8/10/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Laws wrote:
On 8/8/07, ant elder <[EMAIL PROTECTED]> wrote:
On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
We talked about this before (
http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16784.html)
but
didn't come to any conclusions. So,
1/ What is the requirement?
2/ What is the technical solution?
3/ When should we try and get it done?
To get things going again here are some thoughts drawn from what was
said
in
the referenced thread.
1/ An API in line with accepted logging/management practices to
support
arbitrary debugging and runtime info, warning and error logging
A common approach to exception/error handling specifically around
the
detail recorded in the error messages
Internationalization/localization
Execution Tracing
2/ Keeping it simple was a popular sentiment
A number of java logging solutions have been proposed Log4J, SLF4J
etc.
I believe DAS is using Log4J.
We have dependencies that also use logging tools. We can take a
look
at how others approach this, e.g, quick glance at the last CxF release
shows
they include SLF4J jars
Aspects were investigated to show how they can be used for
tracing,
seems like an interesting optional facility but adds extra
complexity/dependencies
There was also a suggestion that we could implement some higher
level
tracing, e.g. runtime starts, stops, application loading, component
instance
creation etc.
We need to move error message out of the code and into resource
files
3/ I think we can reasonably expect to agree what approach we are
going
to
take fairly quickly and provide some examples, i.e. before the next
release?
People suggested before that we take time out to go through the
code
based and bring it into line. This will take a lot of time but can we
get
it
into 1.0?
Please add your thoughts to the list and we can then draw them
together,
try
some of it out and come to some conclusions.
Simon
+1 for going with SLF4J. If we can decide on this soon then we can all
just
start adding it in to the code we're working on and debugging, and then
maybe have a focused sweep before 1.0 to make sure its in everywhere
useful.
...ant
Cross posting to the user list also as I expect this is close to
everyone
heart. Can everyone reply to both lists.
Thanks
Simon
We had a similar discussion in April [1].
Here's what I suggest for logging:
- Separate the trace calls from the runtime code. Insert them
automatically at build time or run time using Aspectj. Raymond on SCA
and Kelvin on SDO already showed how to do it.
- Use SLF4J in these generated trace calls.
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
Thoughts?
There were several posts on that referenced thread less keen on using
aspects - [1], [2], [3]. Aspects are cool, but I think I'd still favour the
simplicity of the more traditional approach of explicit logging calls in
Tuscany.
...ant
[1]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
[2]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
[3]
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200704.mbox/[EMAIL
PROTECTED]
OK then, I don't care much about whether or not we use aspects, but I
think that calls to trace method entry/exit+parameters should be
externalized and inserted automatically when we build Tuscany, as IMO
writing all these repetitive calls by hand will be problematic:
- it's a lot of work and will be difficult to maintain and keep
consistent (when methods are renamed, parameters added etc.)
- it puts a big requirement on people contributing Tuscany extensions to
write all these calls in their extensions as well
- it will make Tuscany difficult to integrate in an environment using a
different logging framework
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
