On 24 Apr 00, at 11:36, Herbers, Joe wrote: > We've had a problem related to this. Knowing what you had stated below > about beans throwing RemoteException (or any kind of RuntimeException), we > created our own application exception. We threw it from our Entity Bean > expecting our caller (a Session Bean) to be able to gracefully catch it. > However, our container (WebLogic 4.5) intercepted it and printed the > exception and stacktrace to the log. This was odd enough, but if this > occurred within the scope of the transaction, WL rolled the transaction > back! Hi Joe, The correct container behavior, assuming that your entity bean's business method is running in the context of the session's transaction, and assuming that your application exception was a checked exception that also did not have RemoteException as a base class, is to allow the transaction to continue. (Of course, the entity bean could have called setRollbackOnly, in which case the transaction would fail at commit time.) If you met all these conditions and WebLogic rolled the transaction back, I believe this is a software defect in WebLogic. Maybe someone else who uses WebLogic can test and verify this. As for logging the exception, this is not mandatory in the case of an application exception. But, neither is it forbidden. -Dan It appeared to rethrow the exception because our caller did then > catch it. However, because of the way WL handled this, we ended up using a > boolean return code instead of an exception in this situation. > > Does the EJB spec address what should happen when beans throw application > exceptions? From what one of the EJB books says, I would have thought the > container would have left our application exception alone and we would have > been fine. Is it only WebLogic that does this? > > Thanks, Joe > > > Date: Sun, 23 Apr 2000 12:48:32 -0400 > > From: Dan OConnor <[EMAIL PROTECTED]> > > Subject: Re: Throwing and catching exceptions that are > > derivatives of RemoteEx > > ception from EJB methods. > > > > On 23 Apr 00, at 16:31, Ohad Parush wrote: > > > > Hi Ohad, > > > > Technically, you should not throw RemoteException from your > > bean code, even indirectly. This is deprecated in the 1.1 specs > > (although support for it by the container is mandatory.) > > > > If your code does throw a RemoteException or a subclass thereof, > > it will be treated as a runtime exception by the container (even > > though RemoteException is a checked exception). This means > > that a new RemoteException will be sent to the client, wrapping > > your "non-application" exception. > > > > This behavior is mandated in various places of chapter twelve of the > > specification. There is no way to throw an exception that derives > > from RemoteException in your bean code, and have it reach the > > client. > > > > -Dan > > =========================================================================== > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff EJB-INTEREST". For general help, send email to > [EMAIL PROTECTED] and include in the body of the message "help". > =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
