Just to throw some more thoughts out here. For the default path, I think that exceptions (besides WebApplicationException) are re-thrown to the container per the JAX-RS spec and I think it should be the responsibility of the container to log an exception being thrown. If Wink logs it, then it has the possibility to be logged twice. I think users who don't want the logging have no way of turning the logging of exceptions off when they use exceptions as part of their normal resource method code (without potentially turning off all of the logging from Wink).
I think if a developer chooses to intercept a non-WebApplicationException with an ExceptionMapper and/or handler, the developer should log it. I think this would reduce logging for the case mentioned on wink-user since the re-thrown exception would only be logged by the container (if the container does that). For WebApplicationExceptions, I think the intent is that the developer already knows they want a specific response to be sent back specifically for the JAX-RS code path. Just my experience, but in most cases it's being used for control flow when developers cannot modify their method signatures to return a Response or throw an exception that they can easily map back via ExceptionMapper. In any case, I think that WINK-240 satisfies the compromise and meets the use case described on wink-user so that a message is still sent to the logs at info level that an exception was thrown and the stacktrace at debug level. If a user wants more logging (i.e. if they want the stacktrace at warning level), they can implement an ExceptionMapper to do it so hopefully this meets everyone's need. On Sun, Dec 13, 2009 at 12:41 AM, Michael Elman <[email protected]> wrote: > I think it's not so obvious. Generally you say that user exceptions should > not be printed to log. But how can you distinguish between user thrown > WebApplicationException and Wink thrown such an exception? > > In addition I think that there are users, who would like to know if their > code throws an exception, since it indicates a problem, an the only place > that can catch and log it is Wink (yes, there are at least two other > options: implement a handlers or implement an ExceptionMapper, but I think > that user expects logging out of the box). > > The compromise can be sending the stacktrace to log only at debug level. > > On Fri, Dec 11, 2009 at 11:42 PM, Nicholas L Gallardo > <[email protected]>wrote: > >> +1 >> >> User exceptions shouldn't be logged given that they may be a normal part of >> the exchange. >> >> >> >> Nicholas Gallardo >> WebSphere - REST & WebServices Development >> [email protected] >> Phone: 512-286-6258 >> Building: 903 / 5G-016 >> >> [image: Inactive hide details for Bryant Luk ---12/11/2009 03:37:26 PM---As >> mentioned by djna on wink-user regarding the exception logg]Bryant Luk >> ---12/11/2009 03:37:26 PM---As mentioned by djna on wink-user regarding the >> exception logging, >> >> >> *Bryant Luk <[email protected]>* >> >> 12/11/2009 03:36 PM >> Please respond to >> [email protected] >> >> >> To >> >> [email protected] >> cc >> >> >> Subject >> >> Change to logging exceptions >> >> As mentioned by djna on wink-user regarding the exception logging, >> there is a lot of logging going on if an exception is thrown from a >> resource method (which can happen multiple times and is expected for >> whatever reason). I think the request to reduce the logging is >> reasonable and I'll change the logging behavior in the trunk later >> unless someone has an objection. >> >> >
