This week's giveaway is in the Spring forum. We're giving away four copies of liveProject: Protecting User Data with Spring Security and OAuth2 and have Laurentiu Spilca on-line! See this thread for details.
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.
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)
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.