I'm a little bit confused about the way that the container handles exceptions thrown by the bean. Does the following sound right? Suppose there is a remote client with a remote component interface for a stateful session bean that has just been removed. The client tries to call a business method on the removed bean. Since the bean doesn't exist anymore, the client is going to get an exception, probably a java.rmi.RemoteException. I am wondering why the client doesn't get a java.rmi.NoSuchObjectException. Or does it? I guess one point that confuses me has to do when a bean throws a system exception. It often means that the container is going to throw java.rmi.RemoteException to the client, but not always that exception? For example, if a CMT bean calls getUserTransaction on its context, the bean will throw an java.lang.IllegalStateException to the container, but now does a remote client get that same exception or just always a RemoteException when things go wrong? C Arthur
May be i'm wrong. but i think if a CMT bean calls getUserTransaction will throw IllegalStateException it's mean that bean instance *can not* be run it's mean that bean miss config or something. but if you got NoSuchObjectException it's mean caller is wrong.
EJB spec is not very forthcoming about the exception thrown by the container. For example if there is DuplicateKeyException, the container might throw the same exception to the client or it might throw CreateException. I hate it when the spec doesn't define a rigid rule and gives so much room to the container which leads to all sorts of confusion. - walk rustin
In th efirst case , it will throw java.rmi.NoSuchObjectException only , not the RemoteException . And in the second case , it throws IllegalStateException . I never tried this as i am new to EJB . this is my bookish knowledge .
In fact, it will throw a Remote Exception, because the bean itself has been removed. see HFE p.559. You get a NotSuchObjectException just in the case where the component interface has been removed or is no more available. Regards, Cyril.
SCJP 1.4, SCWCD, SCBCD, IBM XML, IBM Websphere 285, IBM Websphere 287
In fact, it will throw a Remote Exception, because the bean itself has been removed. see HFE p.559. You get a NotSuchObjectException just in the case where the component interface has been removed or is no more available
But on p.552 of HFEJB under NOSuchObjectLocalException, it says that Container throws this exception to client when the client invokes a method on a local home or components and the bean has already been removed (either through a previous client call to remove(), or because the Container killed the bean due to an exception, stateful bean timeout, or to reduce the size of the pool". Somehow it contradicts the one on p559. Also from the EJB 2.0 spec 18.3.5: If a client makes a call to a session object that has been removed, the Container should throw the java.rmi.NoSuchObjectException (which is a subclass of java.rmi.RemoteException)to a remote client, or the javax.ejb.NoSuchObjectLocalException to a local client. I believe the answer will be NoSuchObjectException if I were asked to choose between NoSuchObjectException or RemoteException. Joyce
if a CMT bean calls getUserTransaction() method on its context , EJB Specification says that it throws IllegalStateException , which is a RunTimeException . So , if the client is remote , will that throw a RemoteException or not!! looks strange..
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com