In pg 559 of HFEJB it says that when a client calls remove() on a bean that has already been removed, the client will get a EJBException or RemoteException.I was wondering why it is not NoSuchObjectException/NoSuchObjectLocalException. Isn't that the exception thrown when you try to invoke a business method on a bean that has already been removed??
you are right, but RemoteException and EJBException are more general forms of the specific exceptions and the container might throw them without violating the spec. In the exam, if you are not given the more specific option, you should choose the general one and if they ask you to select 2 answers, you can select both the superclass and the subclass
NoSuchObjectException Is-A RemoteException, NoSuchObjectLocalException IS-A EJBException. These subclasses should (recommended but not mandated by the EJB spec) be thrown by the Container to give the client a better indication of the cause of the error.
I agree that RemoteException and EJBException are the more general forms of NoSuchObjectException and NoSuchObjectLocalException, so it's technically correct that the client gets a RemoteException when thrown a NoSuchObjectExeption, for example. I'm not sure if HFEJB meant this as a trick question, or if it was just careless.
I don't agree that the spec allows a container to throw the more general form of the exceptions though. The spec is fairly clear that the container throws the more specific form. Compare that to DuplicateKeyException, where the spec says, "The container may, but is not required to, throw the DuplicateKeyException" . With NoSuchObject(Local)Exception the language is always "should", "does", or "must", with no indication that the superclasses are an acceptable substitute.
I'm referring to the EJB 2.0 Final Release Specification.
posted 14 years ago
If the spec says "should" (which it does for these exceptions), then surely it is optional. It's a recommendation, but it doesn't have to be followed.
The only time that something is mandatory is when the spec uses words like "must" or "required".
When the client calls remove on the home or component interface to remove the session object, the container issues ejbRemove() on the bean instance. This ends the life of the session bean instance and the associated session object. Any subsequent attempt by its client to invoke the session object causes the java.rmi.NoSuchObjectException to be thrown if the client is a remote client, or the javax.ejb.NoSuchObjectLocalException if the client is a local client.
P. 114 for Entity Beans
After an entity object has been removed, subsequent attempts to access the entity object by a remote client result in the java.rmi.NoSuchObjectException.
P. 132 also for Entity Beans
The Container must detect any subsequent attempt to invoke an accessor method on the removed entity object and throw the java.rmi.NoSuchObjectException if the client is a remote client or the javax.ejb.NoSuchObjectLocalException if the client is a local client.
In one or two other places, you're right though. It says "should" in place of "will" or "must". It's not the most clearly written specification. However, on this point, I can't see the container taking that shortcut. It almost certainly violates the spec, and really doesn't save any effort for the container implementer.
posted 14 years ago
Ah, I was looking in the wrong place, which is this.
18.3.5 Non-existing session object
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.
Anyway, maybe it's a useful mistake to have made as I've dug up something which not many people know about!