geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <>
Subject Changes to OpenEJB interceptor stack
Date Tue, 25 May 2004 21:08:40 GMT
Posted here as its really about how it integrates with the Geronimo 

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 
* 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.


View raw message