This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes EJB Certification (SCBCD/OCPJBCD) and the fly likes EJBCore_Spec errata? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » EJB Certification (SCBCD/OCPJBCD)
Bookmark "EJBCore_Spec errata?" Watch "EJBCore_Spec errata?" New topic
Author

EJBCore_Spec errata?

Alexander V Fahrmann
Greenhorn

Joined: Jan 16, 2008
Posts: 22
[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:



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.


SCJD, SCBCD, SCWCD
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Hmmm, interesting! Have you contacted Sun about this?


Cheers, Martijn - Blog,
Twitter, PCGen, Ikasan, My The Well-Grounded Java Developer book!,
My start-up.
Alexander V Fahrmann
Greenhorn

Joined: Jan 16, 2008
Posts: 22
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.


I tried...


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
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

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

Joined: Mar 22, 2007
Posts: 329

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 ]

SCJP 1.4 (88%) - SCJP 5.0 Upgrade (93%) - SCWCD 1.4 (97%) - SCBCD 5.0 (98%)
Martijn Verburg
author
Bartender

Joined: Jun 24, 2003
Posts: 3274
    
    5

Thanks for the clarification Sergio.
 
wood burning stoves
 
subject: EJBCore_Spec errata?
 
Similar Threads
CMT supports & getRollbackOnly
HFEJB-497 Page- 4th qs
Topic: Big doubt! Spec Page 361 -- IllegalStateException for Supports attribute.
Handling of getRollbackOnly Method
Big doubt! Spec Page 361 -- IllegalStateException for Supports attribute.