getPrimaryKey on session beans

[Peter Wiederkehr]

Hi javaranch readers,

Invoking javax.ejb.EJBLocalObject.getPrimaryKey() on a session bean results in javax.ejb.EJBException been thrown.
Why they have choosen to throw a EJBException and not a IllegalStateException? (if I know the reason I can better remember that stuff).

Regards

Peter

[Valentin Crettaz]

As per the Java API, IllegalStateException should be thrown when a method has been invoked at an illegal or inappropriate time, but since session bean do not make their identity public, there will never be a proper time where getPrimaryKey() could be invoked, and thus, the container, JVM or whatever will never be in an appropriate state for returning the session bean identity to the client.

[Jason Hunt]

HFEJB P560: A session bean calls getPrimaryKey() on its context get an IllegalStateException.

So I think, if callMethodMakeNoSense() happened in the bean class code then the bean class itself will get IllegalStateException, but if it is happened in the client code, for example: EJBLocalObject.getPrimaryKey() then the container already wrap the IllegalStateException into EJBException (or RemoteException for remote client).
[ July 15, 2004: Message edited by: Jason Hunt ]

[Peter Wiederkehr]

@Valentin
>IllegalStateException should be thrown when a method has been invoked at
>an illegal or inappropriate time

If the definition is that the IllegalStateException should be thrown at an illegal time, why does that not match the getPrimaryKey on session beans? The session bean has this method and it's illegal to call it (because session bean do not make their identity public).
Of course there will never be a proper time where getPrimaryKey() could be invoked, but that would only match the definition at the "inappropriate time" part!
If yopu change the definition to:
"IllegalStateException should be thrown when a method has been invoked at
an inappropriate time" I would be fully agree.

@Jason
>So I think, if callMethodMakeNoSense() happened in the bean class code >then the bean class itself will get IllegalStateException
Why should the bean class itself get an IllegalStateException, makes it more sense for the bean itself to call such a method?? I dont't think so.

[Valentin Crettaz]

If the definition is that the IllegalStateException should be thrown at an illegal time, why does that not match the getPrimaryKey on session beans?
Well, I guess we will never find out why the EJB team decided to do so. All I understand is that the session bean will never be in a state that allows one to get its primary key, and thus, the session bean is not in an illegal state but more that no one is allowed to call the getPrimaryKey() method at anytime. This is one example of the *cool* issues and special cases we get when trying to leverage the reuse of existing artifacts. A session object and an entity object have close to nothing in common except that they are both proxies to their respective beans, yet they still have to extend the same interface. Does it make sense?

[Peter Wiederkehr]

>Well, I guess we will never find out why the EJB team decided to do so.
Agree! (after much thinking about that Exception I would prefer an OperationNotSupportedException )

I also do not understand why they have defined ejbActivate and ejbPassivate in SessionBean and EntityBean, although they have a completely different meaning!
But somebody has thought that this is a good idea (perhaps I will never understand why and if someone knows the answer pls tell me )

[Valentin Crettaz]

It sure isn't a good idea to have two methods that have two very different purposes for two different artifacts to be named the same way. This sort of things can only confuse people. Unless you get on the EJB expert team or at least provide them with some well-argumented feedback, you are going to have to cope with such design choices, however bad or good they might be

[Peter Wiederkehr]

I would give them a feedback if it would be possible to change, but because they must support backward compatibility they will not change that stuff (I will allways return null for a cmp entitty bean )

[Valentin Crettaz]

Actually, the containers for EJB 3.0 beans will have to be backward compatible, i.e. they will have to support pre-3.0 beans. EJB 3.0 compliant beans will not have to declare those callbacks methods anymore because the implementation of the new callbacks (ejbCreate, ejbLoad, ejbStore, ejbRemove, ejbMerge, ejbDetach) will become optional.

[Jason Hunt]

Originally posted by Peter Wiederkehr:
Hi javaranch readers,

Invoking javax.ejb.EJBLocalObject.getPrimaryKey() on a session bean results in javax.ejb.EJBException been thrown.
Why they have choosen to throw a EJBException and not a IllegalStateException? (if I know the reason I can better remember that stuff).

Regards

Peter

javax.ejb.EJBLocalObject.getPrimaryKey()
this method is belong to client view method, so it will never throw IllegalStateException, just imagine there is a container hide behind the client view method and always wrap the system exception into RemoteException or EJBException. so it is impossible for client view method(methods in home or remote interface) throw IllegalStateException, instead it should throw RemoteException or EJBException). Only Bean class can encounter IllegalStateException, client will never do.

for example(IllegalStateException):
1. CMT bean get a context and then call getUserTransaction()
2. BMT bean get a context and then call getRollBackOnly()
3. MDB bean get a context and getCallerPrincipal()

RemoteException or EJBException:

1. client try to get the primaryKey for session bean
2. client calls remove() on the session bean that has been removed.

[Narasimha Rao B.]

Hi peter,

See the errata for this page at oreilly site,
Errata page for HFEJB

[Alec Lee]

Actually, HFEJB does explain it on P552.

1. IllegalStateException

The Container throws this to a bean if....

2. EJBException

bean throws this to tell the container......
container can also throw this....

You see, the important concept is who throw what to whom.