Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Security Methods of EJBContext

 
Padma Priya
Ranch Hand
Posts: 125
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all

Chapter 4 from EJB3.0 Core Spec says

The PostConstruct lifecycle callback interceptor methods execute in an unspecified transaction
and security context.
The PreDestroy lifecycle callback interceptor methods execute in an unspecified transaction and
security context.
The PrePassivate and PostActivate lifecycle callback interceptor methods execute in an
unspecified transaction and security context.


and Chapter 17 on Security says

The Bean Provider can invoke the getCallerPrincipal and isCallerInRole methods only in
the enterprise bean’s business methods


Then why does the PostConstruct, PreDestroy , PrePassivate and PostActivate methods of a stateful session beans have access to these methods getCallerPrincipal and isCallerInRole(Table 1 Operations Allowed in the Methods of a Stateful Session Bean on page 79) when they are not associated with any Security context and it being said that only business methods have access to these security methods.

With Regards
Deepthi




 
Prasad Kumbhare
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I also stuck across same question. I was wondering about not only Unspecified Security Context but about Unspecified Transaction Centext also. I didn't get exact answer but I could understood it little bit when I read specs, EJB-Core 13.6.5. It talks about "Handling of Methods that Run with “an unspecified transaction context."

The EJB specification does not prescribe how the container should manage the execution of a method
with an unspecified transaction context—the transaction semantics are left to the container implementation.


What specification mandates is Table 1 Operations Allowed in the Methods of a Stateful Session Bean on page 79. So it is container providers responsibility to handle such special cases.
I think same holds true for Unspecified Security Context also.

Still if somebody can make it more clearer that would be great.

Thanks,
Prasad
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic