Last night a matcher has got a java.lang.InternalError thrown deep in the stack by sun.awt.X11GraphicsEnvironment.initDisplay(Native Method) in a Solaris JVM.
The hierarchy is InternalError -> VirtualMachineError -> Error -> Throwable, so it is not an instance of Exception. For details see the thread named "Matchers & X Window" in the james-user list, in particular my posting at http://archives.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=742054, second part. To summarize, it was, from our point of view, something that we should have caught in JamesSpoolManager.process(Mail) and hence had the message sent to error, or even managed by the new "onException" mechanism (I would have coded - my personal choice - onException="noMatch"). But instead, being a Throwable, it was caught only in JamesSpoolManager.run() and the message was totally lost! This should not have happened, and things like this may have already happened several times to anyone. As we all agree that is imperative not to get messages totally lost, I'm going then to change JamesSpoolManager.process(Mail) to catch any Throwable instead of any Exception, in order to have the message sent in the worst case to Mail.ERROR. I hope that you all agree on this action. I'm also becoming convinced now that the new "onException" mechanism should catch any Throwable instead of just MessagingException-s (should it become named "onThrowable"?), but I will wait for your comments about this second modification. Vincenzo > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: marted� 17 giugno 2003 22.27 > To: James Developers List > Subject: RE: [PATCH]Endless loop in JamesSpoolManager > > > Noel, > > I know, and my opinion is/was (I'm not so sure though) to have > onException control only MessagingException-s, also because > Mailet.service(Mail) can throw only MessagingException-s, and so > only Error-s and RuntimeException-s (programming errors and > system malfunctions) can percolate up to LinearProcessor. > > So, the way things are coded now, a Mailet or Matcher programmer > is forced by the java compiler to catch all normal (event > related) Exception-s, and has to "throw new > MessagingException(String, Throwable)" if he wants to send it up > and leave the choice to the config administrator. And also this > way a programming error (RuntimeException) will not be hidden and > will go to the error processor, so that someone would be invoked > to fix it. > > I'm really not sure about it. If we control now only > MessagingException-s we can later on change our mind and control > also Exception-s (or even Throwable-s), but the reverse is not > true. But on other part "onException" does not mean > "onMessagingException". > > Let me know your opinion, as now I'm 50-50, so I leave it up to > you. Tomorrow morning after your answer I can quickly change the > things and send another patch. > > But we have to fix the endless loop problem asap. > > Vincenzo > > >Vincenzo, > > > > //We got an error... send it to the requested processor > >+ if (!(e instanceof MessagingException)) { > >+ //We got an error... send it to the error processor > >+ mail.setState(Mail.ERROR); > >+ } > > mail.setErrorMessage(e.getMessage()); > > > >Are you sure about this change? It is correct in terms of the > previous one, > >but it points out a lack in the prior patch: not all Exceptions will be > >MessagingExceptions. Do we only want onException to catch > >MessagingException instances, or do we want it to catch others? > > > > --- Noel > > > >-----Original Message----- > >From: Vincenzo Gianferrari Pini > >[mailto:[EMAIL PROTECTED] > >Sent: Tuesday, June 17, 2003 8:08 > >To: List James-Dev > >Subject: [PATCH]Endless loop in JamesSpoolManager > > > > > >The new "on{Match|Mailet}Exception" support introduced in 2.2.0a5 was > >causing an endless "config.xml" loop caused by JamesSpoolManager > not setting > >state to Mail.ERROR in case of an Exception not instance of > >MessagingException being thrown by a Mailet or Matcher. In such situation > >the message was resent to the current processor instead of going to > >Mail.ERROR. > > > >Vincenzo > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
