You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@wink.apache.org by djna <ar...@uk.ibm.com> on 2009/12/10 19:19:38 UTC
Mapped Exceptions from service operations - Wink logs errors
I'd like to ask two questions:
Q1). Can anyone think of reasons to prefer one or the other of two error
handling techniques.
Q2). Wink does what I consider to be excessive logging in one of the cases.
Do folks agree? Could be reduce the volume in this case?
Details:
If I want to produce a detailed error response from a service method there
seems to be two good possibilities:
a). return Response.status(Status.NOT_FOUND).entity(myInfoEntity).build();
b). Define a SomeInfoException of my own, and add a provider
public class SomeInfoExceptionMapper implements
ExceptionMapper<SomeInfoException >
and then throw new SomeInfoException (/* etc */)
I quite like the latter. I think it makes for more readable service code.
The only problem is that Wink logs a bulky Error message and stack trace
when I throw such a Mapped Exception.
[10/12/09 14:17:26:968 GMT] 0000085d RequestProces E
org.apache.wink.server.internal.RequestProcessor logException
DuplicateInsertionException (500 - Internal Server Error) occured
during the handlers chain invocation
org.djna.library.service.exception.DuplicateInsertionException
at
org.djna.library.service.BookEditionResources.addNewEdition(BookEditionResources.java:76)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
--
View this message in context: http://n2.nabble.com/Mapped-Exceptions-from-service-operations-Wink-logs-errors-tp4146928p4146928.html
Sent from the Apache Wink Users mailing list archive at Nabble.com.
Re: Mapped Exceptions from service operations - Wink logs errors
Posted by djna <ar...@uk.ibm.com>.
Yes, it's flagged as Info, but unfortunately we still seem to get a stack
trace.
[10/12/09 22:51:23:968 GMT] 0000085d RequestProces I
org.apache.wink.server.internal.RequestProcessor logException
WebApplicationException (404 - Not Found) occured during the handlers chain
invocation
javax.ws.rs.WebApplicationException
at
org.djna.library.service.BookEditionResources.getEditionByIsbn(BookEditionResources.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at
org.apache.wink.server.internal.handlers.InvokeMethodHandler.handleRequest(InvokeMethodHandler.java:51)
I'm not really convinced that throwing a mapped exception from a service
method, merits any logging at all. I would go so far as to say that throwing
Business Significant exceptions is part of the interface contract of a
Business Method and hence should at most be a Debug Trace event.
Another option:
throw new
WebApplicationException(Response.status(Status.NOT_FOUND).entity(myInfoEntity).build())
I didn't check it lately, but I think that in this case the log level will
be 'info' and it won't include the stacktrace.
On Thu, Dec 10, 2009 at 8:19 PM, djna <ar...@uk.ibm.com> wrote:
>
>
> I'd like to ask two questions:
> If I want to produce a detailed error response from a service method there
> seems to be two good possibilities:
>
> a). return Response.status(Status.NOT_FOUND).entity(myInfoEntity).build();
>
> b). Define a SomeInfoException of my own, and add a provider
> public class SomeInfoExceptionMapper implements
> ExceptionMapper<SomeInfoException >
> and then throw new SomeInfoException (/* etc */)
>
> I quite like the latter. I think it makes for more readable service code.
> The only problem is that Wink logs a bulky Error message and stack trace
> when I throw such a Mapped Exception.
>
> [10/12/09 14:17:26:968 GMT] 0000085d RequestProces E
> org.apache.wink.server.internal.RequestProcessor logException
> DuplicateInsertionException (500 - Internal Server Error) occured
> during the handlers chain invocation
>
> org.djna.library.service.exception.DuplicateInsertionException
> at
>
> org.djna.library.service.BookEditionResources.addNewEdition(BookEditionResources.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
--
View this message in context: http://n2.nabble.com/Mapped-Exceptions-from-service-operations-Wink-logs-errors-tp4146928p4148460.html
Sent from the Apache Wink Users mailing list archive at Nabble.com.
Re: Mapped Exceptions from service operations - Wink logs errors
Posted by Michael Elman <el...@apache.org>.
Another option:
throw new
WebApplicationException(Response.status(Status.NOT_FOUND).entity(myInfoEntity).build())
I didn't check it lately, but I think that in this case the log level will
be 'info' and it won't include the stacktrace.
On Thu, Dec 10, 2009 at 8:19 PM, djna <ar...@uk.ibm.com> wrote:
>
>
> I'd like to ask two questions:
>
> Q1). Can anyone think of reasons to prefer one or the other of two error
> handling techniques.
> Q2). Wink does what I consider to be excessive logging in one of the cases.
> Do folks agree? Could be reduce the volume in this case?
>
> Details:
>
> If I want to produce a detailed error response from a service method there
> seems to be two good possibilities:
>
> a). return Response.status(Status.NOT_FOUND).entity(myInfoEntity).build();
>
> b). Define a SomeInfoException of my own, and add a provider
> public class SomeInfoExceptionMapper implements
> ExceptionMapper<SomeInfoException >
> and then throw new SomeInfoException (/* etc */)
>
> I quite like the latter. I think it makes for more readable service code.
> The only problem is that Wink logs a bulky Error message and stack trace
> when I throw such a Mapped Exception.
>
> [10/12/09 14:17:26:968 GMT] 0000085d RequestProces E
> org.apache.wink.server.internal.RequestProcessor logException
> DuplicateInsertionException (500 - Internal Server Error) occured
> during the handlers chain invocation
>
> org.djna.library.service.exception.DuplicateInsertionException
> at
>
> org.djna.library.service.BookEditionResources.addNewEdition(BookEditionResources.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>
> --
> View this message in context:
> http://n2.nabble.com/Mapped-Exceptions-from-service-operations-Wink-logs-errors-tp4146928p4146928.html
> Sent from the Apache Wink Users mailing list archive at Nabble.com.
>
Re: Mapped Exceptions from service operations - Wink logs errors
Posted by Bryant Luk <br...@gmail.com>.
Out of the options you listed, I personally prefer the latter if your
application uses the same exceptions to make things consistent. I
would also add some exception mappers for NullPointerException and the
like and any checked exception thrown from your service methods to
give better responses to end users of your applications.
It may also be the case that your JAX-RS resource class can be easily
instantiated without JAX-RS injections (so the resource method also
functions as a normal Java method). For instance, if you use the
class's methods to normally do CRUD operations, you can get Java
exceptions back from the resource method that you may want to process
instead of Response objects or WebApplicationExceptions.
It really depends if you're able to change the method signature too.
If you can't change the method signature (i.e. can't add a Response
return type), then the unchecked runtime WebApplicationException may
be the easiest way to propagate custom error status codes to the
JAX-RS runtime.
As far as the Wink logging, I'm open to reducing the logging.
On Thu, Dec 10, 2009 at 12:19 PM, djna <ar...@uk.ibm.com> wrote:
>
>
> I'd like to ask two questions:
>
> Q1). Can anyone think of reasons to prefer one or the other of two error
> handling techniques.
> Q2). Wink does what I consider to be excessive logging in one of the cases.
> Do folks agree? Could be reduce the volume in this case?
>
> Details:
>
> If I want to produce a detailed error response from a service method there
> seems to be two good possibilities:
>
> a). return Response.status(Status.NOT_FOUND).entity(myInfoEntity).build();
>
> b). Define a SomeInfoException of my own, and add a provider
> public class SomeInfoExceptionMapper implements
> ExceptionMapper<SomeInfoException >
> and then throw new SomeInfoException (/* etc */)
>
> I quite like the latter. I think it makes for more readable service code.
> The only problem is that Wink logs a bulky Error message and stack trace
> when I throw such a Mapped Exception.
>
> [10/12/09 14:17:26:968 GMT] 0000085d RequestProces E
> org.apache.wink.server.internal.RequestProcessor logException
> DuplicateInsertionException (500 - Internal Server Error) occured
> during the handlers chain invocation
>
> org.djna.library.service.exception.DuplicateInsertionException
> at
> org.djna.library.service.BookEditionResources.addNewEdition(BookEditionResources.java:76)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
>
> --
> View this message in context: http://n2.nabble.com/Mapped-Exceptions-from-service-operations-Wink-logs-errors-tp4146928p4146928.html
> Sent from the Apache Wink Users mailing list archive at Nabble.com.
>