Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of plinskey@bea.com designates
 66.248.192.21 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: openjpa logging
Date: Mon, 22 Jan 2007 16:05:39 -0800
Message-ID: <7D856CDFE035FF45A0420ACBD71BDD6302E71329@repbex02.amer.bea.com>
In-Reply-To: <89c0c52c0701221532p69c78d51nd44eccf96d7ec458@mail.gmail.com>
Thread-Topic: openjpa logging
Thread-Index: Acc+fapAZ/3+rN6CQjG2cqIkpQIycgAAomOQ
References: <7a5e6f6a0701221101n1ba36d3cm1d2a7b57ad2c0784@mail.gmail.com>
 <B85A2A93-AEE4-40EE-999F-03C2C819A744@bea.com>
 <89c0c52c0701221336l4fa46946p1e60229a01b01c67@mail.gmail.com>
 <E91132D3-5148-4496-9180-1883C05305DE@bea.com>
 <89c0c52c0701221532p69c78d51nd44eccf96d7ec458@mail.gmail.com>
From: "Patrick Linskey" <plinskey@bea.com>
To: <open-jpa-dev@incubator.apache.org>

> Okay, that's clearer.  So, when we receive a SQLException=20
> from a database,
> we either re-throw the exact same exception, or we throw a=20
> 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=20
> having problems
> obtaining the information anywhere.  I guess not.  I just=20
> re-read her note
> and she has indicated that the information is available if=20
> her testcase
> outputs the caught exception.
>=20
> What about trace or debug logging?  Do you have a concern=20
> with logging of
> SQLException data when trace or debug is turned on?  For=20
> applications that
> are not correctly processing the Exceptions thrown by our=20
> runtime, the trace
> or debug information associated with caught SQLExceptions may be very
> helpful.  Probably not in all cases.  But, maybe in selected=20
> 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.

-Patrick
_______________________________________________________________________
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.