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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
