Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Calling remove on local home interface

 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On p559 of HF EJB, there is this scenario:
Client calls the home remove method on the LOCAL home interface of a session bean.

The book says that the client will get a RemoveException because the only remove() method in a session bean's local home is the one that takes a primary key, and that can never work.
But won't the client get an EJBException as this method can only be used by local clients of an entity bean?
 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roger you may be right!
If you look at the API for Interface EJBLocalHome it mentions what you said.
public void remove(java.lang.Object primaryKey)
throws RemoveException,
EJBExceptionRemove 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.
Thanks,
Santosh
 
Joyce Lee
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But according to the EJB 2.0 at section 6.4.2 (pg 60) or 6.3.2 (pg 59), it says
Because session objects do not have primary keys that are accessible to clients, invoking the javax.ejb.EJBLocalHome.remove(Object primaryKey) method on a session results in the javax.ejb.RemoveException.

In this case, I will choose RemoveException.
Joyce
 
Santosh Ramachandrula
Ranch Hand
Posts: 252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joyce,
What you said is right by Specs.

I checked the API for J2EE 1.4 for EJBLocalHome and it says what you said
public void remove(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 a RemoveException.


I double checked the API for J2EE SDK 1.3 for EJBLocalHome (I think it has some typo or mistakes)
public void remove(java.lang.Object primaryKey)
throws RemoveException,
EJBExceptionRemove 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.

So what do you guys think is the better API version to check on?
[ April 10, 2004: Message edited by: Santosh Ram ]
 
cyril vidal
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
The type of exceptions thrown by session beans dealing with Primarey Key can be read in the spec �6.6:
EJBObject.getPrimaryKey() method results in java.rmi.RemoteException
EJBLocalObject.getPrimaryKey() method results in a javax.ejb.EJBException
while
EJBHome.remove(Object primaryKey) and EJBLocalHome.remove(Object primareyKey) both result in a javax.ejb.RemoveException application exception.
Last point, if the EJBMetaData.getPrimareyKeyClass() method is invoked on a EJBMetaData object for a sessioon bean, the method throws the java.lang.RuntimeException.
Hope this helps,
Regards,
Cyril.
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think that the J2EE 1.3 API is in error by saying that EJBException will be thrown if the remove() method of EJBLocalHome is called on a session bean. It makes more sense to me if the Container were to throw RemoveException.
Also, if there is a discrepancy between the spec and the API, the spec is normally deemed to be correct.
 
Vishwa Kumba
Ranch Hand
Posts: 1066
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I remember I had tried this with SUN's R.I 1.3.
I got RemoveException, which proved that the Spec is correct and the J2EE1.3API wrong.(a mistake I believe)
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic