That's the correct thing to do. Exceptions will always happen in a production environment, and without the stack trace there is little that can be done to quickly track them down.
John Baker -- Web SSO IT Infrastructure Deutsche Bank London URL: http://websso.cto.gt.intranet.db.com Daniel Kulp <[EMAIL PROTECTED]> 22/05/2008 22:43 Please respond to [email protected] To [email protected] cc Subject Re: Swalling exceptions In <2.0.4, we logged stack traces for all the exceptions and everyone complained about it as they didn't want stack traces for the exceptions they were throwing from their implementation as they are rightfully supposed to be mapped to faults. Logs were filling very fast, etc... Everyone hated it. In 2.0.5 we changed it so all the exceptions thrown from the implementation only got a single log line. However, I think we went too far here. Most likely, we should only do this for CHECKED exceptions. For the unchecked exceptions (like your NPE), we probably need the full stack trace. I'll change the code over to do that. That should hopefully come closer to making everyone happy, or at least a good compromise. (I hope) Dan On May 22, 2008, at 7:00 AM, John-M Baker wrote: > Hello, > > CXF is swallowing exceptions: > > 22-May-2008 11:59:29 org.apache.cxf.phase.PhaseInterceptorChain > doIntercept > INFO: Application has thrown exception, unwinding now: > java.lang.NullPointerException: null > > I think it should provide a full stack trace for all throwable > exceptiosn, > because when they happen in production (which they will!), log > levels will > be set to INFO and if it's reported as anything else then it is > missed. > > > John Baker > -- > Web SSO > IT Infrastructure > Deutsche Bank London > > URL: http://websso.cto.gt.intranet.db.com > > > --- > > This e-mail may contain confidential and/or privileged information. > If you are not the intended recipient (or have received this e-mail > in error) please notify the sender immediately and delete this e- > mail. Any unauthorized copying, disclosure or distribution of the > material in this e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. --- Daniel Kulp [EMAIL PROTECTED] http://www.dankulp.com/blog --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
