On Jan 8, 2007, at 7:12 PM, Dain Sundstrom wrote:
On Jan 8, 2007, at 6:54 PM, David Blevins wrote:
On Jan 8, 2007, at 4:44 PM, David Blevins wrote:
I remember this was used in our OpenORB/Tyrex/Castor/OpenJMS
integration (also used by WebObjects) where Tyrex provided the
JNDI and JTA support in conjunction with OpenORB's XA support.
There was an alternate ThreadContext implementation that we
plugged in and took advantage of knowing when changes in the
ThreadContext happened to perform JNDI and TX related work. I
remember making the suggestion to Richard that we should just
allow them to plug *in* to our impl via a listener type interface
rather than having to replace our impl to get those hooks.
Well here we are now facing the same issues with our Geronimo
integration and well... I think I'm going to win that old debate ;-)
Going to make this change in the ThreadContext as well as
implement a generics based map as I did in the Server's CallContext:
http://svn.apache.org/repos/asf/incubator/openejb/trunk/openejb3/
server/openejb-ejbd/src/main/java/org/apache/openejb/server/ejbd/
CallContext.java
So heads up on changes to the ThreadContext. Will let you know
when I'm done. Shouldn't be long.
Ok, I've made some changes in the ThreadContext, but implementing
the full listener type concept in there will perhaps be tricky.
Several things about the ThreadContext can change including the
DeploymentInfo, primary key, and Operation. We could fire an
event at any change at all but that may be expensive.
I'm definitely going to need this for the Geronimo integration for
changes in component instance boundary. How about I take look at
this with an eye for what we need right now? If someone comes
along later wanting more events we can add them. This way we keep
the design pragmatic.
Go for it.
-David
