You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Blevins <da...@visi.com> on 2007/01/09 01:44:15 UTC
ThreadContext changes
The work on the Geronimo integration is bringing back some old
memories....
If you look at the top of ThreadContext it's got some stuff in there
to be "pluggable."
public class EnvProps {
...
public final static String THREAD_CONTEXT_IMPL = "org/openejb/
core/ThreadContext/IMPL_CLASS";
...
}
public class ThreadContext implements Cloneable {
...
protected static Class implClass = ThreadContext.class;
...
static {
String className = System.getProperty
(EnvProps.THREAD_CONTEXT_IMPL);
if (className != null) {
...
ClassLoader cl =
ClassLoaderUtil.getContextClassLoader();
implClass = Class.forName(className, true, cl);
...
}
}
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.
-David
Re: ThreadContext changes
Posted by Dain Sundstrom <da...@iq80.com>.
On Jan 16, 2007, at 9:01 AM, Alan D. Cabrera wrote:
> On Jan 9, 2007, at 11:17 AM, Dain Sundstrom wrote:
>
>> * The deploymentInfo and securityIdentity are now final fields.
>> * When constructing a ThreadContext the deploymentInfo must not be
>> null.
>> * The primaryKey is mutable because ejbCreate for Stateful and
>> Entity beans changes it (we should consider just pushing a new
>> context).
>
> Why not move these fields into the data map?
I was talking to David about this the other day. One thing I like
about OpenEJB is that is is very readable and easy to follow because
there has been a compromise between generic flexible code and static
inflexible code. The former is easy to extend and integrate, and the
latter is easy to read, understand and debug. There are a lot of
systems that go off the deep-end where everything is completely
generic, and it makes it almost impossible to learn the code base
because you must know the exact runtime layout components in memory
(e.g., the OpenEJB 2 interceptor stack). Other code bases, go off
the deep-end where everything is static, protected, and very
difficult to change. These code bases are very difficult to work
with because there is no where to extend (for example, the Sun ORB).
What I like about OpenEJB is that there are places to put your data
and there are hooks at the most important places to get your
processing in the execution path, but in general the OpenEJB code
doesn't use these, generic data structures and hooks, which makes the
code obvious.
In this specific case, these fields are final and it makes it obvious
that certain data is expected and that most if it will not change.
This is also a compromise between typed java fields which are fast
and untyped maps which are slow. The fields that are specifically
declared in the ThreadContext are used all the time and therefore get
a big benefit from being declared as a field.
-dain
Re: ThreadContext changes
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2007, at 11:17 AM, Dain Sundstrom wrote:
> * The deploymentInfo and securityIdentity are now final fields.
> * When constructing a ThreadContext the deploymentInfo must not be
> null.
> * The primaryKey is mutable because ejbCreate for Stateful and
> Entity beans changes it (we should consider just pushing a new
> context).
Why not move these fields into the data map?
Regards,
Alan
Re: ThreadContext changes
Posted by David Blevins <da...@visi.com>.
On Jan 9, 2007, at 11:17 AM, Dain Sundstrom wrote:
> I committed a first attempt at a listener interface. I had to
> split the functionality setThreadContext method so I can tell the
> difference between a context entering and leaving. The new
> standard template for ThreadContext is:
>
> ThreadContext callContext = new ThreadContext(deployInfo,
> primKey, securityIdentity);
> ThreadContext oldCallContext = ThreadContext.enter(callContext);
> try {
> doSomething();
> } finally {
> ThreadContext.exit(oldCallContext);
> }
Looks good.
> A few items to take note of:
>
> * The ThreadContext code automatically manages the thread context
> class loader. I have removed code from the CMP and MDB containers
> that was also managing the TCCL.
> * You can listen for contextEntered and contextExited events by
> adding a ThreadContextListener to the ThreadContext.
> * The deploymentInfo and securityIdentity are now final fields.
> * When constructing a ThreadContext the deploymentInfo must not be
> null.
> * The primaryKey is mutable because ejbCreate for Stateful and
> Entity beans changes it (we should consider just pushing a new
> context).
All good.
-David
Re: ThreadContext changes
Posted by Dain Sundstrom <da...@iq80.com>.
I committed a first attempt at a listener interface. I had to split
the functionality setThreadContext method so I can tell the
difference between a context entering and leaving. The new standard
template for ThreadContext is:
ThreadContext callContext = new ThreadContext(deployInfo,
primKey, securityIdentity);
ThreadContext oldCallContext = ThreadContext.enter(callContext);
try {
doSomething();
} finally {
ThreadContext.exit(oldCallContext);
}
A few items to take note of:
* The ThreadContext code automatically manages the thread context
class loader. I have removed code from the CMP and MDB containers
that was also managing the TCCL.
* You can listen for contextEntered and contextExited events by
adding a ThreadContextListener to the ThreadContext.
* The deploymentInfo and securityIdentity are now final fields.
* When constructing a ThreadContext the deploymentInfo must not be null.
* The primaryKey is mutable because ejbCreate for Stateful and Entity
beans changes it (we should consider just pushing a new context).
WDYT?
-dain
Re: ThreadContext changes
Posted by David Blevins <da...@visi.com>.
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
Re: ThreadContext changes
Posted by Dain Sundstrom <da...@iq80.com>.
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.
-dain
Re: ThreadContext changes
Posted by David Blevins <da...@visi.com>.
On Jan 8, 2007, at 4:44 PM, David Blevins wrote:
> The work on the Geronimo integration is bringing back some old
> memories....
>
> If you look at the top of ThreadContext it's got some stuff in
> there to be "pluggable."
>
> public class EnvProps {
> ...
> public final static String THREAD_CONTEXT_IMPL = "org/openejb/
> core/ThreadContext/IMPL_CLASS";
> ...
> }
>
> public class ThreadContext implements Cloneable {
> ...
> protected static Class implClass = ThreadContext.class;
> ...
>
> static {
> String className = System.getProperty
> (EnvProps.THREAD_CONTEXT_IMPL);
>
> if (className != null) {
> ...
> ClassLoader cl =
> ClassLoaderUtil.getContextClassLoader();
> implClass = Class.forName(className, true, cl);
> ...
> }
> }
>
>
> 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.
-David