Enthuware

The explanation for the 3rd anwser option says "Although there is no client for a MDB, it can still call getCallerPrincipal as per Table 3 Section 5.5.1 of EJB 3.0 Specification. However, Message-driven bean instances cannot call isCallerInRole method."

However, according to Enterprise Java Bean 3.0, (Fifth Ed. 2006), O'Reilly, Section 12.2.2.1 MessageDriveContext, it reads " ... The security methods getCallerPrincipal( ) and isCallerInRole()also throw a RuntimeException if invoked on a MessageDrivenContext. When an MDB services a JMS message, there is no "caller," so there is no security context to be obtained from the caller. ..."

This contradicts with the above explanation.

Grateful for your advice.

Hi,
Since the EJB 3.0 specification clearly says that getCallerPrincipal is a valid call for a MDB in message listener method, business method, and interceptor method, the book needs to be updated.

HTH,
Paul.

the behaviour changed between 3.0 and 3.1 version of specification, which is very interesting in my opinion (it is not very common that the behaviour is not backward compatible). The book is about 3.0, and the test is for 3.1 so the question and book are ok (at least in those edition about 3.0).

Hi Paul

Thanks for your reply.

However, even in the newer version of the same book, Enterprise JavaBeans 3.1 - Sixth Edition, published in 2010, page 106, it also says the same thing, " ... The security methods—getCallerPrincipal() and isCallerInRole()—also throw a RuntimeException if invoked on a MessageDrivenContext." So, the book seems to have a fairly consistent view on the point being discussed.

Furthermore, I've done a testing myself. I've a MDB which can run properly to receive messages from the container's queue (I use Jboss). Then, I modify the MDB like this, adding the call on getCallerPrincipal():

@Resource MessageDrivenContext msgctx;
public void onMessage(Message message) {
try {
msgctx.getCallerPrincipal().getName());
...

It throws the exception at the red color line, saying "
javax.ejb.EJBTransactionRolledbackException: java.lang.IllegalStateException: No valid security context for the caller identity
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleInCallerTx(Ejb3TxPolicy.java:87)

The error above makes sense, since how can we tell the "caller identity" for a MDB which just receives the messages from the container's queue and it has been given no information about who deposits those messages at all.

What do you think? Thanks.

Regards,
John

jszczepankiewicz wrote:the behaviour changed between 3.0 and 3.1 version of specification, which is very interesting in my opinion (it is not very common that the behaviour is not backward compatible). The book is about 3.0, and the test is for 3.1 so the question and book are ok (at least in those edition about 3.0).

Hi jszczepankiewicz,

Thanks for the response. the question being discussed comes from Enthuware's product "EJB+ V5
for Oracle Certified Professional - Java EE 5 Business Component Developer Exam". (http://www.enthuware.com/index.php/mock ... 5-old-exam)

It's for the exam 1Z0-860, which, according to Oracle, follows EJB 3.0 (http://education.oracle.com/pls/web_pro ... id=1Z0_860)

Correct me if I'm wrong. Just to make sure that I'm heading to the right way. Thanks.

John

Hi John,
There was a discussion about the same issue sometime back. I understand that the books says otherwise but as I mentioned before, if EJB 3.0 specification says that it is allowed, we have to rely to it instead of the book.

EJB 3.0 also has the same information. You can verify for yourself. It is really a question of who do you trust more - the book or the specification. The book and the actual EJB containers must follow the specification.

thank you,
Paul.

Thanks for notifing about the version of test, this question comes from test for J5EE which has different behaviour than test for J6EE. Please compare the tables for allowed method invocations for both specifications. And please observe that isCallerInRole and getCallerPrincipal are treated separatelly.

admin wrote:Hi John,
There was a discussion about the same issue sometime back. I understand that the books says otherwise but as I mentioned before, if EJB 3.0 specification says that it is allowed, we have to rely to it instead of the book.

EJB 3.0 also has the same information. You can verify for yourself. It is really a question of who do you trust more - the book or the specification. The book and the actual EJB containers must follow the specification.

thank you,
Paul.

Thanks Paul,

It seems a bit weird or a bit sad that we've to memorize something without bothering to understand its real meaning. But it's also not worthwhile to spend more time on this issue. Surrendered. Afterall, it's kind of examination's true color.

Regards,
John

There is an unconfirmed errata posted here: http://oreilly.com/catalog/errataunconf ... 0596158033

It's always worthy of taking a glance at these pages - no book is perfect

Cheers!

PedroKowalski wrote:There is an unconfirmed errata posted here: http://oreilly.com/catalog/errataunconf ... 0596158033

It's always worthy of taking a glance at these pages - no book is perfect

Cheers!

Thanks PedroKowalski,

It's enlightening. Will monitor the development of the unconfirmed errata and see how the authors respond to it. Thanks

Regards,
John