Upon further thought and nudging...
the ejb 2.1 spec section 21.5 seems to imply that all calls within a transaction must be with the same principal.
I therefore think that skipping the policycontext interceptor, runas interceptor, and security interceptor are all fine.
Given that all ejbStore calls will be under the same principal as a preceding business method, one half of the ConnectionTrackingInterceptor's job is unnecessary. I can split this into 2 interceptors, one before the EntityInstanceInterceptor, and one after. This will fix the immediate test failures.
I am still very unclear about whether the EJBIdentityInterceptor can be skipped. My impression is that it is needed to make sure that (in the presence of a security policy) the ejb bean code is executing with the correct permissions (for such things as permission to open a socket). However I could easily be completely wrong about this. I think this is plain non-jacc jaas security.
I'm going to modify the ConnectionTrackingInterceptor to fix the tests while waiting for a more informed voice on the identity interceptor.
thanks david jencks
On Monday, May 24, 2004, at 06:32 PM, Dain Sundstrom wrote:
On May 24, 2004, at 7:53 PM, David Jencks wrote:
(this is jira http://jira.codehaus.org/browse/OPENEJB-5 but the jira-mailing list link seems to be broken)
The EntityInstanceInterceptor calls flush on the context after the actual invocation has completed. This results in ejbStore being called on the ejb instance. However, the call is not routed through the rest of the interceptor stack. This results in:
wrong security permissions for the ejbStore call (EJBIdentityInterceptor skipped)
possible wrong identity (EJBRunAsInterceptor skipped)
What are the correct security permissions for ejbStore?
wrong environment for connector framework (ConnectionTrackingInterceptor skipped)
Currently the missing ConnectionTrackingInterceptor is causing npes for bmp tests as the framework attempts to find out if the connection requested in ejbStore is supposed to be shareable or unshareable. With container managed security and a realm mapping, a connection obtained under these circumstances could be for the wrong subject as well (runas interceptor missing).
I suspect similar problems hold for ejbActivate, ejbPassivate, and ejbLoad.
I'm not sure what we do here. Since these call backs can happen at any time, I'm not sure what the "right" identity will be.
-dain
