[QUOTE 188.8.131.52 Handling of setRollbackOnly Method] The container must throw the java.lang.IllegalStateException if the EJBContext. setRollbackOnly method is invoked from a business method executing with the SUPPORTS, NOT_SUPPORTED, or NEVER transaction attribute.
[QUOTE 184.108.40.206 Handling of getRollbackOnly Method] The container must throw the java.lang.IllegalStateException if the EJBContext. getRollbackOnly method is invoked from a business method executing with the SUPPORTS, NOT_SUPPORTED, or NEVER transaction attribute.
That is, according to the spec, the container MUST throw IllegalStateException if the getRollbackOnly/setRollbackOnly methods are invoked within a method with the SUPPORTS transaction attribute NO MATTER if the transaction really exists or not.
But other chapters of the spec state that those methods must cause the IllegalStateException ONLY when them are invoked outside of a transaction (or within a method of a Bean with Bean-Managed Transaction demarcation)!
Results (No Transaction context is inherited from the client): 1. getEJBExceptionProxy returns "NO EXCEPTION!"; 2. getEJBException returns "IllegalStateException"; 3. getIllegalStateExceptionProxy returns "NO EXCEPTION!"; 4. getIllegalStateException returns "IllegalStateException";
AppServer - GlassFish.
So, it seems that there are arrata in the specs?! Be careful, ranchers.
Originally posted by Martijn Verburg: Hmmm, interesting! Have you contacted Sun about this?
Actually, there is nothing to sneer at, Martijn.
Another "Easter egg":
[QUOTE 4.6.2 Session Bean Class] The session bean class may have superclasses and/or superinterfaces. If the session bean has superclasses, the business methods, lifecycle callback interceptor methods, the timeout callback method, the methods of the optional SessionSynchronization interface, the Init or ejbCreate<METHOD> methods, the Remove methods, and the methods of the SessionBean interface, may be defined in the session bean class, or in any of its superclasses. A session bean class must not have a superclass that is itself a session bean class.
[QUOTE "EJB in Action" (Panda) - 5.2.2 The @Resource annotation in action - page 155] @Resource and annotation inheritance In chapter 3, you learned that an EJB bean class may inherit from another EJB class or a POJO. If the superclass defines any dependencies on resources using the @Resource annotation, they are inherited by the subclass. For example, Bid- ManagerBean extends another stateless EJB, PlaceBidBean, where PlaceBidBean defines a resource, as in this example:
The environment entry defined in the PlaceBidBean will be inherited by the BidManagerBean and dependency injection will occur when an instance of Bid- ManagerBean is created. As useful as DI is, it cannot solve every problem. There are some cases where you must programmatically look up resources from a JNDI registry yourself. We�ll talk about some of these cases next, as well as show you how to perform programmatic lookups.
SessionInterfaceBean described in my previous post... Application works!
But I am with the spec here: the Bean provider should not extend another Session bean, even if the app works.
The problem lies on the meaning of "an uspecified transaction context".
Quoting sections 4.4.1 (operation allowed in methods of a stateful session bean) and 4.5.2 (operation allowed in methods of a stateless session bean) of the ejb core specs:
Invoking the getRollbackOnly and setRollbackOnly methods is disallowed in the session bean methods for which the container does not have a meaningful transaction context, and to all session beans with bean-managed transaction demarcation.
It states that we should not call those two methods on methods for which the container does not have a "meningful transaction context".
Now to the interesting part...
This is from section 13.6.5 of the ejb core specification (handling of methods that run with "an unspecified transaction context":
The term “an unspeciﬁed transaction context” is used in the EJB speciﬁcation to refer to the cases in which the EJB architecture does not fully deﬁne the transaction semantics of an enterprise bean method execution.
This includes the following cases: - The execution of a method of an enterprise bean with container-managed transaction demarcation for which the value of the transaction attribute is NOT_SUPPORTED, NEVER, or SUPPORTS. - The execution of a PostConstruct, PreDestroy, PostActivate, or PrePassivate callback method of a session bean with container-managed transaction demarcation. - The execution of a PostConstruct or PreDestroy callback method of a message-driven bean with container-managed transaction demarcation.
The misunderstanding lies in that we often confuse "unspecified transaction context" with "no transaction". [ September 11, 2008: Message edited by: Sergio Tridente ]