That is the simplest usage of the SecurityClient interface. The deprecated SecurityAssociation usage in the ejb3 test suite is probably failing because the test suite is using an older library of JBossSX in the 2.0.x series. There have been a lot of things broken with the SecurityAssociation api (as I have migrated to a SecurityContext approach). I have still not taken care of all the SA fallouts.

But we try to discourage folks from using SecurityAssociation in the JBoss AS5 arena.

Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)

Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)

"anil.saldhana@jboss.com" wrote:Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)

As soon as you stop mucking in ejb3-core and create a clean separation in ejb3-security. EJBContext.getCallerPrincipal() should delegate to the security component (either directly or via plugin). The only question is whether it is possible to test ejb3-security stand alone. (It should only be a question of how.)

"anil.saldhana@jboss.com" wrote:Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)