openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <>
Subject RE: openjpa logging
Date Tue, 23 Jan 2007 00:05:39 GMT
> Okay, that's clearer.  So, when we receive a SQLException 
> from a database,
> we either re-throw the exact same exception, or we throw a 
> new Exception
> consistent with the API interface setting the cause as the caught
> Exception?  Is that our current exception processing model?

Pretty much. Typically, a new exception will get thrown, hopefully with
some additional information, and often with the initial exception as a
cause. This exception will then be translated into a spec-determined
exception type at the boundary. But see below...

> I agree.  I thought from Ritika's original note, she was 
> having problems
> obtaining the information anywhere.  I guess not.  I just 
> re-read her note
> and she has indicated that the information is available if 
> her testcase
> outputs the caught exception.
> What about trace or debug logging?  Do you have a concern 
> with logging of
> SQLException data when trace or debug is turned on?  For 
> applications that
> are not correctly processing the Exceptions thrown by our 
> runtime, the trace
> or debug information associated with caught SQLExceptions may be very
> helpful.  Probably not in all cases.  But, maybe in selected 
> paths as we
> continue to debug customer-related applications?

There actually is one place that we do have catch-all exception logging:
in BrokerImpl.afterCompletion(), if the log level is set to TRACE. We do
this because in our experience, application servers often make it very
difficult to get a printout of the underlying exception that causes a
managed commit.

Since the time that we implemented that, we added logic (the
RuntimeExceptionTranslator interface and its implementors) that takes
care of translating from internal exception types to spec-defined
exception types across the board. We certainly could move the logic for
logging at the trace level from BrokerImpl.afterCompletion() to that
boundary code. Since we (try to) guarantee that all exceptions that make
it to the user pass through the PersistenceExceptions class for
translation, that would be a nice uniform place to do the work.

Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

View raw message