Wonder if someone could give me their opinion on something that puzzles me about stateful and stateless session EJBs
Why did sun make the classification of a stateful/stateless session EJB a deployment issue rather than a class interface classification???
Surely once a session EJB is coded to rely on its stateful nature, i.e reaccessing instance variables during a conversation, this precludes it from ever being deployed again as a stateless session EJB.
I'm asking the question because I have had to check whether an EJB which is currently being deployed as a stateful EJB could be deployed as stateless. Luckily in my case it can but if any methods had relied on the stateful nature I would have been scuppered!
I suppose you could access the sessionContext or something and condition certain logic on the beans deployment.
I had this same question. I agree that it seems very odd since the decision to go stateful vs. stateless clearly invloves programming issues. It sounds like you are lucky that you could easily go from stateful to stateless.
EJB seems to have several cases like this where I ask "why didn't they add another interface. It seems that would make things cleaner." Instead, there are a lot of "generic" interfaces that leave the developer having to remember a long list of rules like "ok I have a XXX bean so even though this ZZZ method is available to me through the interface my bean implements, I can't use it. Of course the compiler will let me, but to quote HF EJB, 'it's just against bean law'"
I suspect that it may be because they needed to maintain backwards compatibility with older versions of the EJB spec?
Blake Minghelli<br />SCWCD<br /> <br />"I'd put a quote here but I'm a non-conformist"