> -----Original Message----- > From: Jeremy Boynes [mailto:[EMAIL PROTECTED] > > Posted here as its really about how it integrates with the Geronimo > environment. > > 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?
Seems like a good idea to me. I also share your reservations and think that we should stick with separate ThreadLocals for the moment. Regards, Alan
