Hello there Sheldon,
Yes, this is a very confusing one that almost everybody wonders about. We should have put it in the book!
Your logic is correct, but the Container is able to do this because it is a *stateless* bean. Since any stateless bean is the same as any OTHER stateless bean, the Container is required to give *something* to the bean that acts as an EJBObject for that bean type. The EJBObject for stateless beans are not associated with any client-specific state, so it does not matter which EJBObject it gets. In other words, the Container is required to provide a stateless bean with a "placeholder" EJBObject that it can use if it needs to send a reference to itself to some other part of the system. But that reference would be for an EJBObject that could actually represent *any* of the stateless beans of that type.
So, even though there is no client yet associated with the stateless bean, the Container does not NEED to have client-specific information in order to create an EJBObject for the bean. This DOES mean that the two parts of the bean's lifecycle are not consistent -- for the reasons you state -- how can the EJBObject be created if it is not created until there is a client? But the answer is that the lifecycle diagrams in the EJB spec (and often in our book) do not represent *real* internals, but rather the way you are supposed to conceptually think about it. And this is one of those areas where you just have to trust that the Container has a way to make this work... for example, the Container could simply create *one* EJBObject shared by all stateless beans, until there is a client for that bean. At that point, the Container can swap the "placeholder" EJBObject for a real one, or have some other mechanism. It might not even use different EJBObjects for the different clients if it is a stateless bean.
This is part of what you are not allowed to know -- how the Container actually implements the spec. The only thing you MUST know, is that within your ejbCreate() for a stateless bean, you can ask for your EJBObject, and *something* will be returned that works. That's all you have to know, and it does not matter how the Container makes that work.
Cheers,
Kathy : )
Good luck with your studies.
If you want to post this to the javaranch forum, please do.
Originally posted by Johann Evans:
The EJB spec mentions:
The container invokes the ejbRemove method on an entity bean instance with container-managed persistence in response to a client-invoked remove operation on the entity bean�s remote home or remote interface.