About Question com.enthuware.ets.scbcd.v5.2.304 : test 3 question 5

[Alex]

Hi,
I think there is a mistake in your question and the associated explanation.
The proposition : MessageDrivenContext.isCallerInRole is not valid.

The spec says that this method inherited from EJBContext must not be called on a MessageDrivenContext. If called, IllegalStateException is thrown if i don't mistake.
However MessageDrivenContext.getCallerPrincipal() can be invoked.

furthermore, I think that the principal returned by getCallerPrincipal() invoked whithin a MDB
has nothing to do whith the principal specified wiith run-as. because run-as (@RunAs) specifies an identity under wich the method onMessage(Message m) will execute. It doesn't specify / reference the caller invoking the method (here the container). Is it true ?


Regards,
Alex

[admin]

Hi Alex,
This has already been fixed in current version (1.30) of the question bank.
HTH,
Paul.

[Alex]

Hi Paul,
this is strange because I'm using the actual 1/30 version. So my comment about this question come from this updated version. the fourth option is : MessageDrivenContext.isCallerInRole() wich is considered as a good answer by the databank.
furthermore, although I forgot to validate this assertion(I have only validate the first assertion) my answer is considered as a good answer. But the message says Wrong answer.
regards,
Alex

[admin]

Hi Alex,
As per section 5.4.4 of EJB 3.0 Core spec, "The getCallerPrincipal method returns the java.security.Principal that is associated with the invocation."
Further, the run-as behavior is as per Section 17.3.4.1.

HTH,
Paul.

[Alex]

Hi Paul,

Sorry my question was maybe not clearly exposed.

1) the question in the version 1/30 suggests MessageDriven.isCallerInRole() . Not MessageDrivenContext.getCallerPrincipal(). So I think that this is not a correct answer

2) the explanation says "These methods will return the values a per the "run-as" configuration of the bean"
If I had well understood the spec., run-as specifies an identity under wich the onMessage will execute.
Establishing a run-as identity for an enterprise bean does not affect the identities of its callers, which are the identities tested for permission to access the methods of the enterprise bean. The run-as identity establishes the identity the enterprise bean will use when it makes calls.
So in the case of MessageDrivenContext.getCallerPrincipal(), the returned principal is "the provider", not the identity associated with the logical role specified via run-as. If onMessage() invoke a method on a session bean, inside this invoked method, SessionContext.getCallerPrincipal() would return the identity specified by run-as on the caller MDB. HopeI was enough clear.

Regards,
Alex

[admin]

Hi Alex,
Can you please specify where in the specification it says that isCallerInRole cannot be called? Originally, this option was marked as incorrect, then it was discussed here viewtopic.php?f=4&t=466&p=731 and it was changed.

I need to investigate further.

thank you,
Paul.

[Alex]

Hi Paul,
From the EJB 3.0 core spec.

section 5.4.4 page 108 :
The getCallerPrincipal method returns the java.security.Principal that is
associated with the invocation.
• The isCallerInRole method is inherited from the EJBContext interface. Message-
driven bean instances must not call this method.

Furthermore from table 3 page 108 : operations allowed in the methods of a MDB, isCallerInRole() is not presents :

MessageDrivenContext methods:
getRollbackOnly, setRollbackOnly,
getCallerPrincipal, getTimerService,
lookup
...

Here is the implementation of MessageDrivenContext.isCallerInRole() in glassfish (from kickjava)

public boolean isCallerInRole(String roleRef)
{ throw new java.lang.IllegalStateException ("isCallerInRole() is not defined for message-driven ejbs"); }

Regards,
Alex

[admin]

OK, I think I now know the cause of confusion.

The option was originally marked as incorrect, which was good. This was also carried over to the new certification question bank EJB+ V6. A customer of EJB+ V6 reported that this was a mistake and the option should be correct. I investigated and sure as per EJB 3.1 Specification Section 5.4.4 and Table 4, method isCallerInRole() is allowed. So I changed it and propagated it to EJB+ V5 as well.

However, in EJB 3.0 Specification Section 5.5.1 Table 3 this method call is not allowed.

Regarding RunAs, even in the bean code (not just in the method that the bean calls) isCallerInRole() will return true/false depending on the role specified in RunAs. getCallerPrincipal() will still return the caller's principle, however.

In case of MDB, the principal will be container's default principal and the role will be as per RunAs.

HTH,
Paul.

[Alex]

Hi Paul,
Thank you a lot.

But i'm not sure having well understand your explanation about RunAs.
Because I think that the principal returned by EJBContext.getCallerPrincipal in a bean on wich a RunAs role is specified, has nothing to do with the RunAs role(identity).
I have made tests and the spec. for EJB 3.0 says :
Establishing a run-as identity for an enterprise bean does not affect the identities of its callers, which are the identities tested for permission to access the methods of the enterprise bean. The run-as identity establishes the identity the enterprise bean will use when it makes calls.

Of course, as I said maybe I have not understood your explanation very well or the explanation from the core spec.

Thank you again for the great job you do.
Regards,
Alex

[admin]

Hi Alex,
You are right. RunAs applies to roles and getCallerPrincipal will return the actual caller identity. What I am saying is that even within the bean code, the role will be the one specified in RunAs. Of course, in 3.0, isCallerInRole not allowed for MDB but in 3.1, isCallerInRole(roleSpecifiedInRunAs) should return true if called within the bean code.

HTH,
Paul.