remove on a bean that's already removed. Pg 559

[Arun]

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??

[B.Sathish]

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

[Roger Chung-Wee]

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.

[Greg Charles]

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.

[Roger Chung-Wee]

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".

[Greg Charles]

What spec are you reading?

P. 79 for SFSB

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.

[Roger Chung-Wee]

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!