A. A transactional client cannot change its principal association within a transaction.
A client may invoke a few methods that formed a single transaction. And these business methods could have declared method permissions. So the client should not be allowed to change its security context during the transaction. If it is allowed to do so, not all methods in the transaction may be allowed to be invoked.
B. A session bean's client cannot change its principal asociation for the duration of the communication with the session object.
I guess this solution is refering to stateful session beans. During the session, a client's security context is propagated to the bean & this shouldn't be changed. Take the shopping cart example, the stateful session bean shopping cart is meant for John but along the way John changes to Mary, this shouldn't be allowed (unless Mary wishes to pay for John? Or they're identical...).
Originally posted by Vince Hon: I have got some confuse, for the tag: If the client IS NOT in a transaction, then, can it change the principal association ? If yes, how can he change ? Thanks
For stateful session beans, a client is tied to the particular bean for the entire bean's lifetime. Unless the bean "dies" (removed), the client will always be tied to that bean. Regardless of transactional state, it is not posible to change principal association at runtime. For stateless session beans, there is no concept of clients, so the concept of principals doesn't make any sense. Besides, stateless session beans do not know its client in the first place.
paul.com<br />SCJP, SCWCD, SCBCD, SCEA
What are you doing in my house? Get 'em tiny ad!
Devious Experiments for a Truly Passive Greenhouse!