aspose file tools*
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes Ejb Implementation Question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "Ejb Implementation Question" Watch "Ejb Implementation Question" New topic
Author

Ejb Implementation Question

Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

Hi ranchers i am studying Ejb through specs , and currently i am studying Local Vs Remote Client View , as i was studying , i am also trying to imagine how internally (inside container) everything is working and i am unable to think on following subject.
Lets assume the following example ,

Now can some one explain me that what a @Remote does ?? the only thing i know is that it makes the interface a Remote interface / remote view .
I have also made the following assumption , so please do tell me that my assumption if wrong or right ??
My assumption on @Remote is that the container must be extending MyBeanRemote to Remote interface , and it must be creating a stub that now implements MyBeanRemote ,
but then if the stub is implementing MyBeanRemote then since my doStuff() in MyBeanRemote interface is not throwing ay n/w related or checked exception then even the stub will not be able to throw any n/w related exception , whereas it is expected to throw one because of rmi...... ??

Your help will be really valuable to me because i am really confused on this , please do let me know about the @Remote and my assumption.
Regards,
Shroff


OCJP-90%,OCPWCD-95%
Frits Walraven
Creator of Enthuware JWS+ V6
Bartender

Joined: Apr 07, 2010
Posts: 1717
    
  25

then if the stub is implementing MyBeanRemote then since my doStuff() in MyBeanRemote interface is not throwing ay n/w related or checked exception then even the stub will not be able to throw any n/w related exception , whereas it is expected to throw one because of rmi...... ??

They are not suppose to throw a java.rmi.RemoteException, see the explanation in the EJB specs here:
14.3.12 Support for Deprecated Use of java.rmi.RemoteException
The EJB 1.0 specification allowed the business methods, ejbCreate, ejbPostCreate, ejbFind<METHOD>, ejbRemove, and the container-invoked callbacks (i.e., the methods defined in the EntityBean, SessionBean, and SessionSynchronization interfaces) implemented in the enterprise bean class to use the java.rmi.RemoteException to report non-application exceptions to the container.
This use of the java.rmi.RemoteException was deprecated in EJB 1.1 - enterprise beans written for the EJB 1.1 specification should use the javax.ejb.EJBException instead, and enterprise beans written for the EJB 2.0 or later specification must use the javax.ejb.EJBException instead.
The EJB 1.1 and EJB 2.0 or later specifications require that a container support the deprecated use of the java.rmi.RemoteException. The container should treat the java.rmi.RemoteException thrown by an enterprise bean method in the same way as it is specified for the javax.ejb.EJBException.

Also note that the EJBException is a RuntimeException (i.e. unchecked exception)

Regards,
Frits
Sagar Shroff
Ranch Hand

Joined: Jun 07, 2011
Posts: 208

Thanks frits.It makes sense the reason they have switched to an unchecked exception is because checked exceptions breaks encapsulation i.e the caller should not know the details of the callee which happens in checked exception.

P.S switched in the sense that they have handled the checked exceptions themselves and thrown an unchecked exception.

Regards,
Shroff.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Ejb Implementation Question