Howdy --
Well, I'm hoping someone will give a better answer, but you have hit on something that is not explained by the spec, far as I can tell.
It would *appear*, from the diagrams, that
you should *not* be able to access your
EJB object from within ejbCreate(), because according to the object interaction diagrams, there is no relationship between EJB object creation and stateless bean creation. In other words, it looks as though the Container could simply create a bunch of session beans for the pool, before *ever* creating an EJB object, since the EJB object creation is tied to the create() call from a client, according to the diagrams...
But remember, the object interaction diagrams in the spec are considered "possible implementations for illustration purposes" and NOT "this is how it is actually implemented". In other words, if you are a Container provider, you must make it appear to the Bean Provider that this is how it works, but this does NOT mean you have to actually use that particular set of objects to make it happen. So you cannot look at the object interaction diagrams and say, "This object is instantiated, and then this one, etc." You can say only, "This is how it *appears* to behave, but we have no idea what REALLY happens, or what objects are *really* being created and used..." Remember, there IS no requirement that the Container have all those individual EJB objects for each client, etc. Only the requirement that it *appears* to work that way.
So, you might want to have a stateless bean get -- and keep -- a reference to its EJB object in its ejbCreate() method, as part of the bean's initialization (as opposed to making that call in every business method, assuming it really does *need* that EJB object reference). So... it's just up to the Container how to deal with this.
Remember, that with a stateless bean one EJB object is identical to another, since the EJB object will not be storing any session object identification (other than, say, it's a bean from this particular home), so all stateless beans could be using the same EJB object reference, and then it's up to the Container how it maps that to EJB object references the clients have.
Anyway, my *wimpy* answer is:
*YES it seems confusing that a stateless bean could use ejbCreate() to get a reference to an EJB object, when there isn't yet a requirement to have an EJB object because there may not be a client...
BUT...
* Since the bean may need a reference to an EJB object as part of create and remove, the Container needs some way to deal with this, by allowing getEJBObject() and getEJBLocalObject() from within ejbCreate and ejbRemove. We have NO idea how that happens, and thankfully -- we do not have to. Whatever magic the Container does behind the scenes is fine.
So what are some examples of why you might want to use ejbCreate() to get a reference to an EJB object? Well, again, you might need to hand references to yourself to someone else, as part of the business logic in your business methods. It is simply more efficient to do the context.getEJBObject() once, assigning that reference to an instance variable, rather than doing it in each method.
Bottom line: The spec says you can do it (get your EJB object from ejbCreate()) because it might be important to the Bean Provider, so the Container is required to support it, somehow, we don't *care* how, and for the exam, all you need to know is that this is possible.
It helps me to think of the spec as more of a guideline for how the Container should **appear* to do things, rather than (as the spec puts is) as a "prescriptive" example. In other words, the spec does not require the Container provider to use any particular implementation, as long as the behavior it produces adheres to what is guaranteed to the Bean Provider.
Hope I didn't just make this even worse... but EXCELLENT question!
cheers,
Kathy
