openjpa logging

[Ritika Maheshwari <ri...@gmail.com>]

I am running a Query "select d.breed from Dog d " .This query gives an
argument exception because Dog does not have a field called breed.Now there
is no way I can make openjpa log this exception.The only way I can see this
exception is by having  a try and catch block in my code and catching and
printing out the exception myself.

No matter what DefaultLevel of openjpa.Log was:WARN,FATAL,TRACE,INFO. The
Argument exception was not logged.

I also tried the various logging channels I made RUNTIME=TRACE,
RUNTIME=FATAL,QUERY=TRACE etc.But even using different logging channels did
not help in logging the exception.

I am not sure if the support for these different Logging Channels is
actually there in openjpa, because if you look at the
org.apache.openjpa.lib.jdbc.DataSourceLogs.java you see only 2 types of logs
jdbc and sql.

In another application I was running I had a sql Exception
(DuplicateKeys).Now there was no way in which I could make openjpa log this
sql exception either.

So my question is that is there currently any way to log these Argument
Exceptions and sql Exceptions in openjpa.

Re: openjpa logging

[Abe White <aw...@bea.com>]

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

Exception translation isn't 100%, though.  For example, when someone  
grabs the Connection from us and uses it, we don't do any exception  
translation.

I don't mind logging exceptions in trace mode, but I do think it's  
very difficult to maintain complete coverage without any duplicate  
exceptions being logged.  And I still feel that given our strategy of  
always nesting the original exception as the cause of the exception  
we throw to the user, it's mostly unnecessary. 
  
_______________________________________________________________________
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.

RE: openjpa logging

[Patrick Linskey <pl...@bea.com>]

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

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

Re: openjpa logging

[Kevin Sutter <kw...@gmail.com>]

Abe,

On 1/22/07, Abe White <aw...@bea.com> wrote:
>
> > So the assumption is that the caller will log the appropriate
> > exception-related message if such an exception is caught?
>
> We're throwing an exception.  The user has to do something with it.
> It is a trivial matter for him to log it if that's what he chooses to
> do, but I would expect much more sophisticated handling of exceptions
> by most users -- handling based on the operation in question and what
> behavior might be expected.


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?

> The processing that I am used to is to log any unexpected
> > exceptions when
> > calling out to an external plugin or feature.
>
> All exceptions we encounter are unexpected.  We can't tell the
> difference between a database error caused by the user's illegal
> actions and one caused by an internal database error.
>
> In my experience, you either throw an exception or log it.  When you
> do both, you just end up with repeats of the same exception logged
> repeatedly as it propagates.


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?

Kevin

Re: openjpa logging

[Abe White <aw...@bea.com>]

> So the assumption is that the caller will log the appropriate
> exception-related message if such an exception is caught?

We're throwing an exception.  The user has to do something with it.   
It is a trivial matter for him to log it if that's what he chooses to  
do, but I would expect much more sophisticated handling of exceptions  
by most users -- handling based on the operation in question and what  
behavior might be expected.

> The processing that I am used to is to log any unexpected  
> exceptions when
> calling out to an external plugin or feature.

All exceptions we encounter are unexpected.  We can't tell the  
difference between a database error caused by the user's illegal  
actions and one caused by an internal database error.

In my experience, you either throw an exception or log it.  When you  
do both, you just end up with repeats of the same exception logged  
repeatedly as it propagates. 
  
_______________________________________________________________________
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.

Re: openjpa logging

[Kevin Sutter <kw...@gmail.com>]

Abe,

On 1/22/07, Abe White <aw...@bea.com> wrote:
>
> OpenJPA does not log exceptions that are thrown to your code.


So the assumption is that the caller will log the appropriate
exception-related message if such an exception is caught?

The processing that I am used to is to log any unexpected exceptions when
calling out to an external plugin or feature.  For example, when performing
the query in Ritika's example, we're calling out to an external database --
DB2, Oracle, Derby, etc.  Each of these may process the request
differently.  If we get an exception from the database, it seems like we
should be logging that exception.  At least at the Trace or Debug level.  As
Ritika has pointed out, if we leave this up to our caller, then we may
experience customer sat issues.

Thoughts?

Kevin

Re: openjpa logging

[Abe White <aw...@bea.com>]

OpenJPA does not log exceptions that are thrown to your code.
_______________________________________________________________________
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.