You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@managingpartners.com> on 2001/10/25 17:46:11 UTC
Using ThreadContext
I remembered seeing Pete's message a few weeks back about the new
ThreadContext code so I thought I would check it out when I was revamping a
piece of my project that uses ThreadLocal's (the never-ending quest to use
avalon to its fullest :)
Maybe I'm missing something here, I can't see how to read data from a
ThreadContext.
You create a new ThreadContext (MyTC) by using its 2-part constructor that
takes a policy and a Map. The ThreadContext class uses the policy to
validate all items in the Map before propogating them to its own internal Map.
I would then take MyTC and use ThreadContext.setThreadContext() to assign
it to the current thread. (Stored in the internal InheritableThreadLocal).
I can then also retrieve MyTC by using ThreadContext.getThreadContext()..
but then what? There isn't any way to get at the internal Map of my data
that I can see.
Pete, I'm not sure what your vision was for accessing the data in that map,
be it exposing a ThreadContextAccessor or what. If you tell me what you
want it to do, I can write the code.
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Using ThreadContext
Posted by Peter Donald <do...@apache.org>.
On Sat, 27 Oct 2001 06:38, Peter Royal wrote:
> At 09:56 PM 10/26/2001 +1000, you wrote:
> > > Maybe I'm missing something here, I can't see how to read data from a
> > > ThreadContext.
> >
> >you can't because that would break the pattern. Users can set the
> >ThreadContext if they have the correct permission but it is completely and
> >utterly up to the Policy to determine what happens. The users can never
> >directly interfer with that part of process.
>
> i think i'm starting to follow it a bit more... ThreadContext is just an
> assistant to push values from that Map thru the ThreadContextPolicy. It is
> up to the policy to do something/anything with those values. correct? Thus
> the code in the DefaultThreadContextPolicy that takes the ClassLoader from
> the Context and assigns it as the thread's classloader.
right.
> >The only reason ThreadContext.getThreadContext() exists is because
> > sometimes you may want to cache current context, apply another context,
> > call another method. After the method finishes you can set your old
> > thread context back in place.
>
> okie.
>
> I'm trying to assign a username/session ID to a thread. My RMI server
> answers, establishes username/session, stores that local to the current
> thread, does its duty, and returns.
>
> Currently I have a component with ThreadLocal variables to store that
> information. The RMI component that establishes username/session tells that
> component which values to store for the current thread, and then other
> components can lookup the session component to query current
> user/sessionid/otherstuffinthefuture.
>
> I'm not quite sure how to handle that using the ThreadContext. (The
> javadocs for that class mention that userID/transaction id are candidates
> for storage in the ThreadContext).
>
> Should the ThreadContextPolicy itself be my component that stores
> username/session ID?
I would not do it this way. I would instead create application specific
objects that contain thread local variables.
Somethine like
class User
{
private final static ThreadLocal c_user = new ThreadLocal();
//This is called by application code
public static User getCurrentUser()
{
return (User)c_user.get();
}
//This is called by thread policy code
public static void setCurrentUser(User user)
{
//check security here
c_user.set( user );
}
}
> Should I read the appropriate variables from the
> ThreadContextAccessor and store them in my own ThreadLocals, or should I
> keep a copy of the ThreadContextAccessor?
I wouldn't. The main reason for having ThreadContext is to make sure it is
easy to change "contexts" without forgetting something. For instance in one
of my old applications I always had to do something like
Thread.currentThread().setContextClassLoader();
ContextMap.bind();
User.setUser();
Transaction.setTransaction();
...
Unfortunately this can be error prone when you have to repeat this code
everywhere (and also back it out after you are done with it). So instead of
the above you now just go
ThreadContext.setThreadContext()
and hopefully if you have written the policy correctly all should be well ;)
> Once I get it all down I'll be able to write a nice little tutorial for the
> ThreadContext's :)
excellent.
--
Cheers,
Pete
-----------------------------------------------------------
I don't suffer from insanity. I enjoy every minute of it.
-----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Using ThreadContext
Posted by Peter Royal <pr...@managingpartners.com>.
At 09:56 PM 10/26/2001 +1000, you wrote:
> > Maybe I'm missing something here, I can't see how to read data from a
> > ThreadContext.
>
>you can't because that would break the pattern. Users can set the
>ThreadContext if they have the correct permission but it is completely and
>utterly up to the Policy to determine what happens. The users can never
>directly interfer with that part of process.
i think i'm starting to follow it a bit more... ThreadContext is just an
assistant to push values from that Map thru the ThreadContextPolicy. It is
up to the policy to do something/anything with those values. correct? Thus
the code in the DefaultThreadContextPolicy that takes the ClassLoader from
the Context and assigns it as the thread's classloader.
>The only reason ThreadContext.getThreadContext() exists is because sometimes
>you may want to cache current context, apply another context, call another
>method. After the method finishes you can set your old thread context back in
>place.
okie.
I'm trying to assign a username/session ID to a thread. My RMI server
answers, establishes username/session, stores that local to the current
thread, does its duty, and returns.
Currently I have a component with ThreadLocal variables to store that
information. The RMI component that establishes username/session tells that
component which values to store for the current thread, and then other
components can lookup the session component to query current
user/sessionid/otherstuffinthefuture.
I'm not quite sure how to handle that using the ThreadContext. (The
javadocs for that class mention that userID/transaction id are candidates
for storage in the ThreadContext).
Should the ThreadContextPolicy itself be my component that stores
username/session ID? Should I read the appropriate variables from the
ThreadContextAccessor and store them in my own ThreadLocals, or should I
keep a copy of the ThreadContextAccessor?
Once I get it all down I'll be able to write a nice little tutorial for the
ThreadContext's :)
-pete
--
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: Using ThreadContext
Posted by Peter Donald <do...@apache.org>.
On Fri, 26 Oct 2001 01:46, Peter Royal wrote:
> I remembered seeing Pete's message a few weeks back about the new
> ThreadContext code so I thought I would check it out when I was revamping a
> piece of my project that uses ThreadLocal's (the never-ending quest to use
> avalon to its fullest :)
;)
> Maybe I'm missing something here, I can't see how to read data from a
> ThreadContext.
you can't because that would break the pattern. Users can set the
ThreadContext if they have the correct permission but it is completely and
utterly up to the Policy to determine what happens. The users can never
directly interfer with that part of process.
> You create a new ThreadContext (MyTC) by using its 2-part constructor that
> takes a policy and a Map. The ThreadContext class uses the policy to
> validate all items in the Map before propogating them to its own internal
> Map.
>
> I would then take MyTC and use ThreadContext.setThreadContext() to assign
> it to the current thread. (Stored in the internal InheritableThreadLocal).
>
> I can then also retrieve MyTC by using ThreadContext.getThreadContext()..
> but then what? There isn't any way to get at the internal Map of my data
> that I can see.
right - see above ;)
The only reason ThreadContext.getThreadContext() exists is because sometimes
you may want to cache current context, apply another context, call another
method. After the method finishes you can set your old thread context back in
place.
> Pete, I'm not sure what your vision was for accessing the data in that map,
> be it exposing a ThreadContextAccessor or what. If you tell me what you
> want it to do, I can write the code.
Well I was almost finished it as it is. My intention is that the policy
object is the only object in the system that actually does anything and it is
completely up to it to determine how a context is applied.
Does that make sense ?
--
Cheers,
Pete
*-----------------------------------------------------*
| Never argue with an idiot, they'll drag you down to |
| their level, and beat you with experience |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org