Errata

In page 82 it is stated that Remote Object(and according to the picture of this page
Remote Object=EJBObject) implemnts Component Interface, but this is opposite to the
page 83 when it says:
Remote Component interface must extends the EJBObject interface.

I know the concept here(some contradiction with core java!), and I think the picture
should be corrected(Remote Object != EJBObject)
EJBObject is an interface while Remote Object is an object.

"There's only one interface here that could be a stateless session
bean's home-number 3."
should read:
"There are two interface here that could be a stateless session
bean's home-number 1 and 3. And number 1 could be both stateless and stateful."

I think that the line
Object o = h.getEJBObject(); should read
EJBObject o = h.getEJBObject();
since getEJBObject returns and EJBObject not just a regular object.

Question 5, choice C states: "The remove() method in the component
interface can be used only by remote clients." Handwriting next to
it says: "- no, only for local".

I agree that the statement is not correct, but the comment is wrong.
Choice C. is incorrect because the remove() method in the component
interface can be used by both remote AND local clients, and not by
local only. This can be verified on page 154. Also, on page 137, it
is stated in bullet 4 that remote clients can call remove() on the
component interface as good manners to tell the container your're
done.

ejbCreate() missed

in the list of things you can do from stateless bean methods there is an omission.
From a stateless session bean with BMT it is possible to get a transaction reference
using getUserTransaction, spec 90. So it should say that its about CMT stateless
session bean.

Answer provided was:

Which session bean interface can contain this method?

Provided answer is A. However, SessionBean interface does not contain such a method
at all. Even the SessionBean interface's implementation class doesn't - it contains
ejbCreate method(s) instead.

So the answer should be D.

Class should be declared abstract:

public abstract class CustomerBean implements EntityBean {

Step 2 should come before step 1 according to OID on page 215 of EJB spec 2.0

The answer mentions B as correct (b2.getFoo() == null). But as the CMR relationship
is said *unidirectional*, b2.getFoo() does not even exist. A (f1.getBar() == null)
should be the only correct answer.

The question states "unidirectional relationship". So, I think, Bar simply does not
have getFoo() method. Answers B and C are invalid

Answer D is incorrect.
The question is "Which will return all orders that have line items ?".

D = SELECT OBJECT(o) FROM Order o

Or there is a missing "WHERE NOT o.lineItems IS EMPTY" or D should be unchecked.

Under "Option2", in the example, in the first container-transaction element there are
three methods with three different ejb-name values. It means that these methods
belong to different beans.

On the other hand EJB spec on the page 353 says: "It is required that all the methods
specified in a single container-transaction element be methods of the same enterprise
bean". It means that the example doesn't comply to the spec.

The answer is valid for stateless session beans, isn't?

The sequence ut.begin(); c.cmtRequiresNew(); c.cmtMandatory(); c.cmtRequiresNew();
ut.commit() will result in exception at attempt to call the second cmtRequiresNew().
It would mean that the same instance of the bean keeps pending changes from
cmtMandatory() and is asked to start new transaction. As I understand, it will not
work

TransactionRolledBackException and TransactionRequiredException are in
javax.transaction, NOT javax.ejb, only their Local counter parts come from javax.ejb

In the book:

The client gets a RemoveException. Why? Because the only remove() method in a session
bean's local home is the one that takes a primary key, and that can never work.
Remote client would also get a RemoveException.

Should read:

The client gets an EJBException. ... Remote client would get a RemoteException.

"(if the client were local, he'd get a RemoteException)"
It should be
"(if the client were remote, he'd get a RemoteException)"

"A session bean calls getPrimaryKey() on its context ...
bean gets an Illegal state exception.

This is incorrect, as sessionContext has no getPrimaryKey() method - only
entityContext has getPrimaryKey() which can throw an illegalStateException.

If the author meant "call getPrimaryKey() via the EJBObject" then the exception would
be a remoteException, not an IllegalStateException.

Option B checked as a correct answer. It says: "They can be listed in the unchecked element."

In EJB spec (p.485) element unchecked defined as EMPTY, which means that nothing can
be listed in it.

If an ejb-jar file only contains message-driven beans, then it does not contain any home or component interface.

Option A says: "Primary key fields must be cmp-fields." The handwritten comment says:
"... you can use a compound key", implying that the option is not correct.

Because the option says about fields of a primary key, it must mean the primary "key
that maps to multiple fields in the entity bean class." (spec p.203), which means
that the primary key is a compound key. That makes the comment out of place and the
option as a correct answer.

answer choice c:
C. Entity beans with BMT demarcation must use the getStatus method instead of the getRollBackOnly method.
- is wrong because entity beans are not allowed to use BMT.