In the chapter on Exceptions (page 559) of HFE it given that client will get remove exception when home remove method is called on local home interface of session bean. But in API & also in the same page under the heading "Client calls getPrimarykey on the local component interface of a session bean " its given that just like the home remove method called on local home inteface of session bean it throws EJB Exception ! Why is this discrepancy ? i guess it has to be EJB Exception for both the cases. Please make me clear.
howdy, Vish. you CAN'T remove session bean using HOME LOCAL interface. PERIOD. NEVER. 1. PK is not accessible for SessionBeans. 2. Handle is not accessible for local view. the only way to remove LOCAL session bean - using local [component] interface. cheers !
Howdy, Yep, in the spec (6.3.2) it states that calling remove(Object pk) on EITHER the remote or local home of a session bean will result in a RemoveException, but that's because there IS such a thing as a RemoveException (an application exception). With the getPrimaryKey() method, there is no special application exception for that, so instead the normal EJB exception rules apply: remote clients get a RemoteException, and local clients get the EJBException. So think of it as something like this: -The RemoveException exists to tell you that something went wrong with the remove. Since remove is an important part of the behavior of your application, and there's no return value for the method, you need a way to know that the remove didn't happen. Calling remove with a primary key, for a session bean, definitely means that the remove didn't happen, so you get the RemoveException. They could have chosen to instead throw the client an EJBException or RemoteException, and that would have made sense as well... since calling remove(Object pk) on a session bean is an obvious problem!! But since there IS a RemoveException, the EJB spec designers decided to use the more specific application exception that says, "Something bad happened in remove, and the object was not necessarily removed!" (in this case, definitely NOT removed). - But there is NOT a specific application exception related to getting a primary key, so you simply get the normal EJB exception process if you call getPrimaryKey() on a session bean's component interface... local clients get EJBException and remote clients get RemoteException. So, to me it could have made sense either way, but since there IS a specific application exception, RemoveException, thrown by the remove method, that's what the client gets. Think of the RemoveException as being thrown for two different reasons: 1) Something genuinely DID go wrong with the remove (including an entity bean that is refusing to allow client-directed removal). 2) The client is stupid, and called remove(pk) on a session bean In this case, RemoveException doesn't mean, "something went wrong" but rather "the client is an idiot". But since they don't have a ClientIdiotException (which I personally would probably get on a regular basis), you get the RemoveException instead cheers, Kathy
Very nice to see your reply Kathy. Okay i understand that since there * IS A * RemoveExcpetion which is more specific than the EJBException, the client will get a RemoveException. So does that mean that the statement given in J2EE API that "calling home remove method on the local home interface of session bean will throw an EJBException" is wrong ? Thanks again Kathy for your detailed replies.
The J2EE1.3.1 API : public void remove(java.lang.Object primaryKey) throws RemoveException, EJBException Remove an EJB object identified by its primary key. This method can only be used by local clients of an entity bean. An attempt to call this method on a session bean will result in an EJBException From the discussions above, I think the EJB2.0 Spec is correct and the J2EE API docs wrong. remove(primarykey) method on a session bean's local/remove home interface always gives RemoveException or in some rare cases ClientIdiotException , if the client calls remove method with any Object as the primary key