We have a problem with certain callbacks like ejbLoad & ejbStore not being invoked with the correct context - things like AccessControlContext for thread and support for connection handle tracking.
One solution seems to be to eliminate the direct calls into the EJBs and replace them with invocations that go down the interceptor stack - basically converting the callbacks into VOPs and handling them in the same way as business methods.
The VOP would be responsible for setting up the environment *specific to the individual method.* This would include:
* the appropriate EJBContext state
* the AccessControlContext of the thread - in other words the
switch from container code to application code for the purpose
of sandboxing, possibly calling doP
Just before Dispatch, there would be a collection of interceptors that applied for both client and container initiated invocations. These would include:
* JNDI component context
* Connection handle tracking
*Every* invocation would need to go through these - this would include, for example, the calls to ejbStore performed at a sync point (e.g. on query or at the end of a tx).
The top of the stack would contain the interceptors that dealt with invocations from clients:
* Instance location
* Transaction context
* Security identity - determine which identity should be used when the
instance is invoked, the caller or the run-as identity
* System exception handling
These interceptors manage things that apply to all J2EE components - servlets as well as EJBs. These are:
* JNDI component context
* Connection handle tracking
* Thread identity
* Transaction context
These are all handled by separate ThreadLocals right now, which provides a clean separation between the different handlers but at the cost of needing to initialize them all separately. It seems to be easier to set up a 'ComponentThreadInstanceContext' (bad name) which would provide access to all this information from one place. On the other hand, this is really a performance optimization so perhaps should be deferred.
Thoughts? -- Jeremy
