In EJB2.0, the ejbObject().gethandle()is used to get the serializable stub of the remote stateful session bean. One can use the returned "handle" object at later point of time, even from some different jvm , to connect to the same Stateful session bean object.
Does EJB 3.0 support this feature by any means, as I guess there is no remote interface equivalent to EJBObject as such in it.
I asked this question in this forum twice. but no answers... My question is wrong? or it is so difficult to answer...
Further there should some tracking system to unanswered question so that the question doesn't loose its identity and value and gets the reply which it deserves. My proposal is to show all the unanswered question in a separate listing or should be shown at the top of the list.
There is obviously no such call on a business interface, so the vanilla EJB 3.0 session bean would not support this. However, you may add a component interface (which extends EJBObject) to an EJB 3.0 session bean if the handle feature is important to you.
In ejb 2.0 it is not the bean which implements the EJBObject. It is altogether a different interface whose implementation is provided only by the container and not the developer. There are lot of reasons for such a design principle and it becomes obvious that the developer should not be given a chance to mingle with it.
The approach which you have suggested seems to break that design principle, if I have understood it correctly. Am I right?
And if it is so, then my intention is only to know that 1)Whether the EJB3.0 specification has intentionally removed this feature? 2)What might be the reason for removing this feature from EJB3.0 specification (as going forward with EJB specification, it seems that this feature would be deprecated in future version)?[/EMAIL]
There is no change in the EJB 3.0 spec w.r.t. how coupled the developer-written client interface is to its implementation. The container still produces the implementation artifact that is used at runtime, it's just that the developer is not required to extend an interface that is usually of little concern to them.
In order to allow business interfaces that are unconstrained (or are not required to extend another interface) we could not have any built-in API on them. I have rarely seen anyone use the handle interface, anyway (you are the first person I have encountered who has even missed it!) so there was no major issues with this.
Mike, the question is not about no.s or whether the issue is major or minor. A issue is a issue and needs to be addressed.
I am new to this J2EE world, and my intention is only to know that whether my understanding is correct or not and how to handle the requirement in EJB3.0.
What you said, if I understood correctly, is to implement a EJBObject interface in our own session bean. But then, I can overwrite all the functionality of EJBObject without calling a super._ _ _. And then how container is going to provide the implementation for the same as the container is not supposed to change our code(though can add more codes). I am not clear that how EJBObject.getHandle()(Which now I have overwritten) will return me the handler object for future purpose.
May be I need to follow some restriction/convention while overwriting methods from EJBObject like what has been described in those links(posted earlier), but still needs clarity. I can always write wrong codes to destroy the functionality from EJBObject (through method overwriting). Or may be something I am missing conceptually.
Or may be I failed to understand totally the solution you proposed (excuse me for that).
I mean that you can provide an old component-style interface in the same way that you would do for EJB 2.1. You can even do this in addition to the business interface. You just define the home and local/remote interfaces and the container will provide the implementation class. The getHandle() method is provided by the container (just as it always was) and you will get that for free.
So what I am saying is that you define your interfaces in the same 2.1 way, but that you can define your bean class according to the rules of 3.0 (allowing you to add interceptors, etc.). Hope this is clear.