Do you have to narrow the EJBHome object that you get back from the getEJBHome method in the EJBObject interface. As in this case: Advise advisor = home.create(); AdviseHome newHome = (AdviseHome) advisor.getEJBHome(); //need of narrowing? Thanks in advance /Magnus
Thank you Anselm. I have a follow up question, in the spirit of "there is no dumb questions". How about this case, assuming that movie is an entity bean with a String primary key and with remote interfaces: Movie movie = home.findByPrimaryKey("1"); String pk = (String) movie.getPrimaryKey(); //need of narrowing? As you always needs to narrow what you get back from an RMI-IIOP before you cast it, is it needed in this case as well. I think the thing I have a problem to understand is whether RMI-IIOP has the be involved to implement methods as getEJBHome() and getPrimaryKey(). Couldn't this methods be implemented in the EJBObject stub without remote calls or are we always to assume that RMI-IIOP are involved. Thank you /Magnus
Howdy -- good question The ONLY things that must be narrowed are remote stubs!! Nothing else retrieved from an RMI-IIOP call must be narrowed. And in fact, the *only* stubs that need to be narrowed are those for which the declared return type does not match the interface to which you are casting it. Thus: * The home stub needs to be narrowed, because it is coming from a method with a return type of Object. * The EJBObject stub that you get from create() (or find) does NOT need to be narrowed, because the return type of create already specifies the EXACT interface type to which you would be casting. So, think of narrowing as a form of exotic casting for stubs. It you don't need to cast the stub, then you don't need to narrow it. If you DO need to cast the stub, then you probably need to narrow it as well. But if it is NOT a stub, then you do not need to narrow it, regardless of whether it needs to be cast, and regardless of whether it is coming from a remote call. For your other question, yes, it *is* true that the stub could be implemented in such a way that it does internal processing and not all calls (like getPrimaryKey()) are remote. But yes YOU are to always assume that *every* call is remote, because according to the spec, the vendor is free to use plain old RMI-IIOP stubs as generated by rmic, and those stubs will not contain any other logic other than knowing how to send the call over the wire to whatever is waiting to receive it on the other side. Mostly, you'll find narrowing here: * ALL JNDI lookups of the remote home interface (your initial lookup of the bean's home) * ALL calls to getHandle() or getHomeHandle() (because they always return a remote stub) You will NOT find narrowing here: * Lookups of a *local* home interface * ALL calls to create() or find(), regardless of whether it is remote or local * ALL other remote calls *unless* the remote business method is returning a remote stub, and only if the return type of the method is NOT the same as the interface type to which you intend to cast it. Hope that helps... I'm still a little brain-dead Cheers, Kathy
Mostly, you'll find narrowing here: * ALL JNDI lookups of the remote home interface (your initial lookup of the bean's home) * ALL calls to getHandle() or getHomeHandle() (because they always return a remote stub)
The first point I'm clear on but the second isn't clicking with me. Doesn't the getHandle/getHomeHandle method return something that can get you the stub but not the stub itself. Page 139 of HF says the following:
A handle is a serializable that knows how to get back the original Remote EJB object. It's not the stub, but it can get the stub.
Since it does not return a stub, I does see a reason for narrowing it. Shouldn't the return value of getEjbObject() of the handle class be narrowed instead as shown in the following code from page 139 of HF: