EJBCore_Spec errata?

[Alexander V Fahrmann]

[QUOTE 13.6.2.8 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 13.6.2.9 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)!

So, I developed a simple Bean, to test the issue:

@Stateless
@TransactionManagement(value = TransactionManagementType.CONTAINER)
public class SessionInterfaceBean implements SessionInterface {
    
    @Resource EJBContext ctx;
    
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public String getEJBException() {
        String result = "NO EXCEPTION!";
 
        try {
            ctx.setRollbackOnly();
        } catch (IllegalStateException ise) {
            result = "IllegalStateException";
        } catch (Exception e) {
            result = "Exception";
        }
 
        return result;
    }
 
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public String getEJBExceptionProxy() {
        return getEJBException();
    }
 
    @TransactionAttribute(TransactionAttributeType.SUPPORTS)
    public String getIllegalStateException() {
        String result = "NO EXCEPTION!";
 
        try {
            ctx.getRollbackOnly();
        } catch (IllegalStateException ise) {
            result = "IllegalStateException";
        } catch (Exception e) {
            result = "Exception";
        }
 
        return result;
    }
 
    @TransactionAttribute(TransactionAttributeType.REQUIRED)
    public String getIllegalStateExceptionProxy() {
        return getIllegalStateException();
    }
}

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.

[Martijn Verburg]

Hmmm, interesting! Have you contacted Sun about this?

[Alexander V Fahrmann]

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:

@Stateless
public class PlaceBidBean implements PlaceBid{
@Resource(name="censorship")
private boolean censorship;
..
}
@Stateless
public class BidManagerBean extends PlaceBidBean implements BidManager{
..
}
 

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.


I tried...

@Stateless
public class SessionInterfaceExpBean extends SessionInterfaceBean 
        implements SessionInterfaceExp {
 
    public String getStringRepresentation(Double d) {
        return d == null ? "null" : d.toString();
    }
}

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.

[Martijn Verburg]

Wow, good finds! You should definitely contact Sun about this, they can amend the JSR as part of the maintenance review process.

[Sergio Tridente]

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 unspecified transaction context” is used in the EJB specification to refer to the cases in which the EJB architecture does not fully define 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 ]

[Martijn Verburg]

Thanks for the clarification Sergio.