Questions on EJB3.1 security management & timers

[Bell Katapa]

Hello Fritz,

I have used your study notes as well as those from krizsan, eventually falling back on the spec itself while preparing for the exam. I hope to write next week. I have 2 questions nevertheless;
1. Security Management: The spec says calls made on EJBContext.getCallerPrincipal() should retain the original java.security.Principal object in cases where the bean method making this call was invoked with the @RunAs annotation and was passed a different role name as attribute from the one originally enlisting the caller identity. It should not retain the Principal associated with the role specified in the @RunAs annotation. Now, suppose the bean method in the onMessage(Message m) of a MDB specified with @RunAs annotation, what should be retained from calling EJBContext.getCallerPrincipal() in the onMessage(Message m) on any other MDB method? Is it the containers representation of an unauthorized identity?

2. Timers: If a call to EJBContext.setRollbackOnly() is made within timeout method and there is still a balance of timeouts for the timer in the future, the spec says the container should try calling the timeout method at-least one more time, thereafter "rescinding the timer expiration". What's the meaning of this? Does the spec imply the timer should be cancelled after all retries result in transaction rollbacks? Should the container continue to call the said timeout method even though the result continues to be a transaction rollback? I have glassfish with me and have noticed that on a few occasions it does not strictly adhere to the spec and relying on it can cost me a few marks on the exam (for instance glassfish allows annotating a business interface view with @Asynchronous while the spec says this should be specified on the concrete bean method).

Please help,

Bell.

[Frits Walraven]

Hi Bell,

Good to hear that you are using my notes. I wish you well on your exam!

Bell Katapa wrote:
1. Security Management: The spec says calls made on EJBContext.getCallerPrincipal() should retain the original java.security.Principal object in cases where the bean method making this call was invoked with the @RunAs annotation and was passed a different role name as attribute from the one originally enlisting the caller identity. It should not retain the Principal associated with the role specified in the @RunAs annotation. Now, suppose the bean method in the onMessage(Message m) of a MDB specified with @RunAs annotation, what should be retained from calling EJBContext.getCallerPrincipal() in the onMessage(Message m) on any other MDB method? Is it the containers representation of an unauthorized identity?

In general it is important to remember that a MDB doesn't have a client, in other words: there is no Principal flowing in from the client. The EJBContext.getCallerPrincipal() will always return a Principal (never null, important for the exam!) and you are right it will be the containers representation of an unauthorized identity. Putting a @RunAs annotation on your MDB won't change anything on the EJBContext.getCallerPrincipal() of the next MDB.

Bell Katapa wrote:
2. Timers: If a call to EJBContext.setRollbackOnly() is made within timeout method and there is still a balance of timeouts for the timer in the future, the spec says the container should try calling the timeout method at-least one more time, thereafter "rescinding the timer expiration". What's the meaning of this? Does the spec imply the timer should be cancelled after all retries result in transaction rollbacks? Should the container continue to call the said timeout method even though the result continues to be a transaction rollback? I have glassfish with me and have noticed that on a few occasions it does not strictly adhere to the spec and relying on it can cost me a few marks on the exam (for instance glassfish allows annotating a business interface view with @Asynchronous while the spec says this should be specified on the concrete bean method).

"rescinding the timer expiration" means putting back the timer (in the state before the transaction started). The same applies to when you cancel a timer in your business method (that runs in a transaction) and the transaction is rolled back: the timer cancellation is reversed to the state it was before it was cancelled (i.e. running).

If the EJBContext.setRollbackOnly() is called inside a timeout callback method the container has to put back the timer in the state before it timed-out and try at least once more (typically there will be a setting in the container of how many retries should be done).

Regards,
Frits

[Bell Katapa]

Thanks Frits for promptly responding.

Am i safe to believe that once a timer is rescinded and restored to its state before it got 'fired' and is retried at least once by the container (... and repeats the same sequence consequently), the container 'forgets' or considers that particular turn of expiration as gone or 'done' and shifts attention to the next future timeout expiration as specified in the schedule?

Thanks once again and enjoy your weekend,

Bell.

[Frits Walraven]

That is exactly what I expect to happen although the specifications are not so clear about it. (by the way the differences between Glassfish and the specs are sometimes subtle, but mostly those kind of details won't be on the exam)