Howdy -- this is ALWAYS a confusing one, for exactly the logical reason you mention. The spec demands that even a stateless bean be capable of initializing itself in ejbCreate() with a reference to its EJBOBject, *even if no clients have yet tried to ASK for an EJBObject*. We don't have to care HOW the server does it, only that the server has to give the bean SOMETHING that it can use as its EJBObject / component interface reference, if it needs to pass that reference to some other object as part of the bean's ejbCreate()/initialization.
So imagine that the server creates a single EJBObject and gives it to the bean's context, so that in ejbCreate(), the bean can GET that reference from its context. Yes, it's not entirely consistent with some of the OID diagrams, but remember -- the diagrams are only a way for you to THINK about it, and they do not represent the *real* way it works inside the server. In other words, these diagrams in the spec are not intended to show you the *real* true number of objects created. But yes, this is always a confusing one... how the stateless bean can get a reference to its EJBObject, when it doesn't yet look like any have been made. So again, the way I think about it is just to pretend that when the server makes a stateless bean for the pool, the server guarantees that it has at least one reference to that bean's component interface. And remember, this is not a problem because all stateless beans of a certain type can use ANY EJBObject for that bean type, since every stateless bean of a specific type is the same as any other, and so it is the same with the EJBObject references for beans of that type.
This is a good question, though, and shows that you're really thinking about the implications of what it says in the spec (and in the book
)
cheers,
kathy
