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 <[email protected]> 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. >
