SessionContext.getEJBObject()

[rick collette]

The following is from Mikalai Zaikin's Study guide:

The container MUST implement the SessionContext.getEJBObject() method such that the bean instance can use the Java language cast to convert the returned value to the session bean�s remote interface type. Specifically, the bean instance does not have to use the PortableRemoteObject.narrow(...) method for the type conversion.

My question: why MUST container implement the SessionContext.getEJBObject() method to use the Java language cast to convert the returned value to the session bean�s remote interface type?

This sounds remote to me.

thanks,

[Mike Melton]

SessionContext.getEJBObject() is called by the bean instance, not the client. The bean and the EJBObject live in the same JVM, so the call is not remote even though the returned value is of the remote interface type.

HTH
Mike

[Hai Lin]

Mike,
I don't agree with what you said
"SessionContext.getEJBObject() is called by the bean instance, not the client",
Of course, clinet have a way to use SessionContext. For example,
in componet interface we add one more method like following:
public interface Advice extends EJBObject {
public String getAdvice() throws RemoteException;

public EJBContext getSessionContext() throws RemoteException;
}

while in corresponding bean class which implements getSessionContext() to return the SessionContext, then when client calls method getSessionContext() by EJBObject's stub, the client can get the object SessionContext.

Thanks.

Hai

[Sandesh Tathare]

Hai,

The arguments or return value types for a bean's method must be legal types for RMI/IIOP if the method corresponds to a business method on the bean�s remote interface.
So arguments or return value types for a remote method must be one of following:
1] Primitive
2] Serializable objects
3] An array or collection of primitives or Serializable objects
4] A Remote Object

So first of all we won't be able to return EJBContext.
Secondly, remember that "The EJBContext interface provides an instance with access to the container-provided runtime context of an enterprise Bean instance." And it's not a very good idea to expose EJBContext to a client of a bean from encapsulation point of view.

And what Mike said makes sense.

Regards,
Sandesh