avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT] Improving Lifecycle Extensions
Date Tue, 23 Jul 2002 13:59:09 GMT
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net] 
> > 
> > That session can be used to store information about a 
> component before 
> > and after the access and release.
> 
> 	Interesting idea.
> 	
> 	How do we differentiate	between clients ? (ie. what represents a
> 	client - a particular thread running through the system ?)


When I describe a client, I am referring to the traditional container/
component/client model.  Container manages Components.  Clients use
Components.  That means that potentially every Component that uses
other Components is a different client.

> 	If that's the case, another option might be to define a
> 	SessionedLifecycleExtension base class:
> 	
> 	eg. a quick and dirty example:
> 	
> 	public abstract class SessionedLifecycleExtension 
> extends AbstractLifecycleExtension
> 	{
> 		protected Map getSession()
> 		{
> 			return (Map) 
> sessions.get(Thread.currentThread());
> 		}
> 		
> 		// ...
> 	}
> 	
> 	or did you have some other way of defining a 'client'.

:/  We can't make the assumption that thread==request.

There are a number of different session management policies that
we can take.  We might even need to provide a pluggable mechanism.
So we have stuff like this:

* Thread==Request (use a ThreadLocal, they are more optimized and
                   clean up after themselves)

* component user==client (the current way Fortress works--and the
                          easiest to implement)

* something new.  In event based systems the session information
                  has to travel with the request.  Exact mechanism
                  isn't known immediately.



> 	Still, a more general solution at the ServiceManager 
> level might have
> 	other advantages outside of lifecycle extensions too. I 
> guess my main
> 	question is defining what a client in the system is 
> represented by ?

What are your perceptions of client?  I want to see if we can speek
the same language.

> 	
> 	BTW - Something I still find vexing is getting 
> information into the
> 	extension object itself - ie. getting the current user' identity
> 	in the first place.

We can expose the Session to the component itself.  Something like
a SessionEnabled interface:

interface SessionEnabled
{
    setSession(Map session);
    unsetSession(Map session);
}

The setSession() is called on access, and the component reads all the
information it needs from the session object.  The unsetSession() is
called on release, and the component can store the information it needs
for later.

Anyway, that is one possibility.


> 	This is what I thought the context could provide, but 
> it means one
> 	has to write some UserManager class which is updated 
> externally to
> 	the system with the current user's identity, and then retrieved
> 	from the context and called upon to deliver the right value. I
> 	keep wondering if there's a better way to do this.

We could possible replace the Context with a Map.  The thing is that
Context is read-only, and we need the ability to both read and write
information.  As long as the Context/Session is managed in the
Component/Service Managers then we can effectively do the same thing.



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message