get a reference to EJBObject from ejbCreate() of SLSB

[Sheldon Fernandes]

Hi,

I am currently reading the Head First EJB book. I came across the following on page 228 'Bean things you can do from stateless bean methods'. The book says you can do the following:
- Use your SessionContext to get a reference to your home
- Use your SessionContext to get a reference to your EJB object
- Access your special JNDI environment

Now the second point confuses me. There is no client associated with a stateless session bean creation. Then how come you can get a reference to your EJBObject from the ejbCreate(). Page 224 says that the EJBObject is created when the client calls create() on the home. But then the bean creation isn't tied to this call, it happens at a completely different and unrelated time.

Now I've checked up the specs for this, and section 7.8.2 says the same things as the book (rather the other way round).

So what am I missing here? I feel I have not understood something fundamental. Some help would be much appreciated.

Thanks,
Sheldon
[ June 29, 2005: Message edited by: Sheldon Fernandes ]

[Sheldon Fernandes]

No replies yet!!!

public void ejbCreate() {
    EJBobject ejbObject = sessionContext.getEJBObject();
}

This is what I am trying to ask.
The above code is for a Stateless Session Bean. Why is the call to get a reference to the EJBObject valid from the ejbCreate() method? The question applies to ejbRemove() also.

[Sheldon Fernandes]

Hi All,

I posted my question on wickedlysmart.com and received a very prompt reply from Kathy herself. Thanks Kathy for taking time to answer my question. Below is her reply, just in case you were interested.

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.