<snip>
Luciano Resende wrote:
Not sure if I'm just repeating what Robbie just said, but what about also
having a common log/trace infrastructure/abstraction between SCA, SDO and
DAS, and we could provide a default implementation using a standard log
framework (e.g log4J or java native log support) and allow user to
customize
it by implementing a specific interface and registering/loading it
somehow ?
<snip>
The current DAS logging implementation was put in place to facilitate
early development and debug. Now we need to take a step back and think
about logging from within a client's application perspective. I think
there are two issues we must resolve before we can go forward and change
the current DAS logging code:
1. What logging framework should the DAS use?
2. What is our logging policy?
It seems that the discussion, so far, has been about #1. My first
thought was that the DAS should use one of the popular logging
frameworks directly. I think the approach SCA has taken is too heavy
for our lightweight RDB DAS and I doubt our time would be well spent
inventing a new framework. But, Jim and Jeremy make an important point
about the need to work well with the logging implementation chosen by
our client applications. Given this, Commons Logging seems the best
choice for the DAS. But, Jim mentioned problems he has experienced with
Clogging and Jeremy even threatened a trout-slapping over the issue. I
would like to know if these issues were specific to the SCA runtime and
perhaps not an issue with a potential DAS usage. There are several
successful OS projects using Commons Logging.
The second issue has to do with what we should log and what logging
patterns to use. There was some initial discussion on this list quite
awhile back and TUSCANY-292 was created and remains open. Here are
Ricks initial comments to the JIRA:
...
I've looked for "logging guidelines" in various projects but couldn't find
anything really relevant.
My only specific advise is to log exceptions, major interfaces between
components, and user settings/ configurations.
Any thoughts?
Thanks,
--Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
