This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Under Section 5.5.1 (Operations Allowed in the Methods of a Message-Driven Bean Class) of EJB 3.0 Core Specs, there is a table (Table 3) which shows that "getCallerPrincipal" is an allowed operation in the message listener method, business method interceptor method and timeout callback method of an MDB.
My understanding is that for a MDB, there is no concept of a caller client. The message listener method, business method interceptor method and timeout callback method are invoked by the container.
So why is "getCallerPrincipal" an allowed operation? What is its returned value? And if "getCallerPrincipal" an allowed operation then why is "isCallerInRole" not an allowed operation?
In case of MDB, though there is no concept of client view, when you receive the message to MBD's message listener method, it come form the JMS messaging agent configured for this purpose. This agent have it's own security mechnism and it apply this security when the message is passed to MDB, So there is security Principal associated with message. How the security is implemented and propagated is specific to messaging system. That is the reason you can not call isUserInRole() is these methods as the security Principals are propagated through external system.
I tried calling "getCallerPrincipal()" of "MessageDrivenContext" within the "onMessage" method of a MDB deployed in JBoss 4.2.2. It gives an "IllegalStateException". This is the stacktrace:
Caused by: java.lang.IllegalStateException: No valid security context for the caller identity at org.jboss.ejb3.BaseSessionContext.getCallerPrincipal(BaseSessionContext.java:190) at com.titan.reservationprocessor.ReservationProcessorBean.onMessage(ReservationProcessorBean.java:38) at sun.reflect.GeneratedMethodAccessor102.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112) at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166) at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47) at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101) at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126) ... 17 more
Is either the specs is wrong or JBoss 4.2.2 is wrong. I suspect the former.