EJB programming & troubleshooting: Can an SessionBean Method return another SessionBean?
- Posted by: Kostas Karadamoglou
- Posted on: July 31 2005 18:02 EDT
I am new to EJB programming.
I want to ask you if it is possible to return a SessionBean from a method of another SessionBean.
Specificallly, There is an article about creating a JDBC driver with rmi in www.javaword.com (http://www.javaworld.com/javaworld/jw-05-2002/jw-0517-jdbcdriver.html)
The client jdbc driver communicate with the database through a middle tier jdbc driver.
I want to implement the same thing but with EJBs.
Thank you in advance, Kostas
- Can an SessionBean Method return another SessionBean? by Viktor Sadovnikov on August 01 2005 03:32 EDT
- Can an SessionBean Method return another SessionBean? by Emil Kirschner on August 01 2005 05:56 EDT
- Can an SessionBean Method return another SessionBean? by Emil Kirschner on August 01 2005 06:00 EDT
First of all, clients never have references to SessionBeans. They deal with EJB Home stubs and SessionBeans stubs.
As I remember, only EJBHome stubs can be freely passed within applications. SessionBeans can always be created
why would you do that? is your session bean method that returns another session bean some kind of a factory? in this case I'd rather advise you to return the home's JNDI name and let the caller use a service locator pattern implementation to obtain the stub.
An important aspect to keep in mind is what Viktor just told you. When you deal with EJBs, you never invoke your code directly. It goes like this: you call methods on a stub class which connects to the application server via some network protocolle and asks it to invoke method X() on bean Y, with parameters p1, p2, ...pn. The app server invokes the bean, obtains the returned value or catches a thrown checked exception and propagates that back to the stub. The method you called on the stub would then either return the value it got back from the app server or throw the checked exception. If youejbjb code throws anruntimeme exception or error, that will bcoughtht by the container and sent to the stub which will wrap it in RemoteExceptionon which will be thrown back at the caller. This would also cause the current container managed transaction to be rolled back if one exists.
Emil Kirschner (http://testare.dev.java.net/)
there are some spelling errors in my previous post, I guess the spell checker in google's firefox toolbar still needs some improvements :-)