On Aug 23, 2006, at 3:13 PM, Kevin Williams wrote:
<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.
Please, please, please don't use clogging ;-) I used it in a previous
implementation of SCA and really came to regret it due to memory
leaks from not properly flushing its caches as well as collisions
with other libraries, particularly when deployed to JBoss. These
problems are not specific to SCA and I imagine they would be
exacerbated in DAS as it is not a "container" technology. Various
projects have encountered problems with clogging, including Jetty,
Spring, Hibernate, JBoss, and I believe Geronimo (Jeremy knows the
details of the latter). Basically, they revolve around failure to
call LogFactory.release().
The lead log4j developer has written a detailed analysis of common
problems here:
http://www.qos.ch/logging/classloader.jsp
The solution to some memory leak issues is suggested by clogging here:
http://wiki.apache.org/jakarta-commons/Logging/UndeployMemoryLeak?
action=print
http://jakarta.apache.org/commons/logging/guide.html#Classloader%20and
%20Memory%20Management
Requiring a container hook for release to be called seems very
intrusive for a library.
For a more colorful analysis, see:
http://www.jroller.com/page/fate/?anchor=the_evils_of_commons_logging
Jim
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
