DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16770 JAMES silently consumes java.lang.Error thrown by Maillet.service() Summary: JAMES silently consumes java.lang.Error thrown by Maillet.service() Product: James Version: 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Mailet API AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] A java.lang.Error indicates a catastrophic, unrecoverable failure for the JVM itself. It should never be caught, the JVM should be allowed to abort. For application servers that absolutely insist on attempting to continue to provide uninterrupted service for other components when one component experiences such a condition, the error should at the very least be reported to the administrator and the component marked as offline; silently consuming a java.lang.Error is Very Bad; continuing to attempt to stuff requests through a failed component is Extraordinarily Bad. Catching Throwable is Really Quite Bad. My particular problem arose from having an error in my build.xml which meant that a jar needed by the maillet was missing which meant that a java.lang.NoClassDefFoundError was thrown during class loading while servicing the first request. JAMES decided to pretend that the Error had not happened and (a) not log it anywhere then (b) continue to stuff requests through the failed component. It wasn't until I decided to investigate why multiple threads appeared to be occupying the same synchronized block that I realised that something other than an Exception was being thrown and that JAMES was concealing it. If you're going to try to catch anything more than Exception, then PLEASE handle them sensibly. Oh, how to reproduce: public void service(Mail mail) { throw new Error(); } Then notice the complete absence of logging, stdout or stderr clues about what has happened. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
