ejbActivate on session beans??

[Badri Iyengar]

The only difference between a stateful and a stateless session bean, in terms of the implementation, is in the deployment descriptor!. I am not exactlty sure what the name of the tag is, it is probably something like <bean type> where you specify whether the enterprise bean is stateful or stateless. Given that, how does one identify if the bean is, a stateful or a stateles bean, given the following snippet of code
public void ejbActivate () {
// Is empty??
}
I dont think I am missing anything here, but this was a beta question. Does this mean that this could be a stateful session bean, with all it's instance state serializable, and/or meets the requirements of passivation. In other words, there are no database connections, or any other resources which need to be released prior to passivation and reacquired on activation. I could have potentially misread the question too.
The next point is, since the lifecycle of a stateless session bean does not include activation/passivation, why not make it implement a third interface or abstract class called StatelessSessionBean with dummy implementations for ejbActivate and ejbPassivate instead of having to implement them, and later realize they are never called. If the moderator, or someone from Sun is watching, would appreciate their reply

[Kathy Sierra]

Given that, how does one identify if the bean is, a stateful or a stateles bean, given the following snippet of code
public void ejbActivate () {
// Is empty??
}
Does this mean that this could be a stateful session bean, with all it's instance state serializable, and/or meets the requirements of passivation.

You're absolutely right. This could be either a stateful or stateless bean.

why not make it implement a third interface or abstract class called StatelessSessionBean with dummy implementations for ejbActivate and ejbPassivate instead of having to implement them, and later realize they are never called.

You can always make your own superclass that has the methods provided so that you don't have to implement all of the methods from the SessionBean interface. I'm kind of surprised they don't have that in J2EE, as a convenience class (the way they have AWT event handler 'adapters'). One of the J2EE engineers told me the reason why they didn't make a separate interface for each 'state' type, but now I don't remember! So I'm going to guess on two reasons:
* that it was because they want as many decisions as possible to be made at deploy time (via the DD) rather than at compile time. Of course, in reality at the time you're writing your bean code, you are almost always making that decision.
But if you look at the way they used to explain stateful vs. stateless session beans... the assumption that you would make a stateful session bean, and then at the last minute you could flip a switch in the deployment descriptor if you notice that there's no reason not to make it stateful.
* Having two interfaces for stateful and stateless would have implications in many places, and for consistency might lead to having four bean types instead of three, (and that stateless and stateful beans would then have their own separate DD tags, and be treated differently).
There are other fun questions like that too... like, how come there's just EJBHome and EJBLocalHome, but not EJBEntityHome, EJBSessionHome, etc. Having a single home interface for both session and entity beans means that entity-only methods are exposed to session clients? I don't think they actually have a good reason for that one... it happened more as an artifact of the way the EJB 1.0 spec looked. Remember, Entity beans weren't even required in EJB 1.0!
I will try to get a more official answer again to that session bean question.
Or while we're on strange things about the API... how come they originally called it EJBHome and EJBObject? Why oh why didn't they call it EJBRemote? Everyone... absolutely every person doing EJB referred to the interfaces as "the home and the remote" (until now, when it became the 'home' and the 'component' interface, which will take me forever to break the habit of saying 'remote').
Of course now, that would have led to the oxymoronic EJBLocalRemote So I guess it's best that they didn't name it remote. But they weren't even *considering* local interfaces at that time.
But I digress into history and trivia that I'm not even sure about, but which are fun to speculate on.
cheers,
Kathy