Napu Sun

Hi Bart,
Congratulation for your new book.

We will start a project next week. We are asked to transform Oracle forms to Java components. We decided embedding Oracle forms in JSF as the first phase of the project to keep users experience and complete the project in the time schedule. I am curious about this part of JSF.

Thanks Bart.

Invoking the getCallerPrincipal and isCallerInRole methods is disallowed in
the message-driven bean methods because the Container does not have a client security context.
The Container must throw and log the java.lang.IllegalStateException if
either of these methods is invoked.

Please refer to Specification 15.5.1

If bean instance hasn't been used in a period of time, container call its ejbPassivate(). If Ejb object's life time is expired, container call its ejbRemove().
Please refer to EJB 2.0 spec Page 78, 79

At this point, we cannot use CMT. CMT starts when we call methods which have a transaction context. But BMT can be used.

congratulate.
Thanks for your message, I will go for exam soon.

Thanks, Neetika

If use "RequireNew", then the method always on the new transaction, it cannot prove the method's caller is in an existing transaction. So container will not already throw TransactionRolledbackException. When caller is in the transaction, the method with "RequireNew" will throw TransactionRolledbackException. But when caller is not in the transaction, container will not throw.

Here, I got a question:
when caller is not in the transaction, then the method with "RequireNew" throws a system exception, what exception the container will finally throw?
I think container will throw RemoteException for remote client, EJBException for local client.

Spec 238 11.3.5

EJB QL, like SQL, treats the FROM clause as a cartesian product. The FROM clause is similar to that of
SQL in that the declared identification variables affect the results of the query even if they are not used
in the WHERE clause. The Bean Provider should use caution in defining identification variables
because the domain of the query can depend on whether there are any values of the declared type.
For example, the FROM clause below defines a query over all orders that have line items and existing
products. If there are no Product instances in the persistent store, the domain of the query is empty and
no order is selected.
SELECT OBJECT(o)
FROM Order AS o, IN(o.lineItems) l, Product p

In HFEJB, page 543 and 546 have your answer

for EJB 2, I think we cannot use primitives for primary key

I only can help for the second question,
in ejb specification Page 436(21.2.5) and 451(21.6.5)
It is mentioned that container's responsibility is providing security context in business methods.

for the first question, I am also looking for it.

Congratulation

before running ejbActivate(), the container will give the EJBObject identity to the entity context.

Hi KRK,
1. By two ways, an entity bean move from "method ready" state to "pooled" state --- ejbPassivate() and ejbRemove() (same as Celinio said).

For ejbPassivate(), the EJBObject will be stay there for the next business method call (at least we can make this assumption based on the "conceptual architecture" -- head first EJB);

For ejbRemove(), the EJBObject will be removed or be not valid, if I call the stub to this EJBObject, I will get a NoSuchObjectException exception.

2. The invocation of finder methods goes through EJBHomeObject not EJBObject (same as Awishek said)

3. The entity bean in the pool is still active, because it can do "finder" methods, and Home Business Methods.

Congratulation
Thanks for your posting