Hi Berin,
Thanks for the RT, nice stuff!
On Tue, Jul 23, 2002 at 08:41:30AM -0400, Berin Loritsch wrote:
> The real interesting solutions for lifecycle extensions require some
> sort
> of "session" information. Consider the process of setting the
> SecurityManager
> based on the user credentials, or using the proper private key for
> encrypted
> communication. Each of these require knowledge about the user. We need
> some
> sort of session information.
>
> Now it is easy to implement if we change a couple contracts, and one of
> the
> interfaces in the Lifecycle Extension. The main contract to change is
> that
> each client has a unique ServiceManager/ServiceSelector. That means
> each
> component has its ServiceManager, as well as what we expose externally.
> Within each ServiceManager would be a Map. That Map exists as long as
> the
> ServiceManager exists. By virtue of the fact that the SM is unique to
> the
> client, so is the Map.
>
> The interface that needs to be changed is the LifecycleExtension
> interface.
> We need to add a new parameter to both access() and release():
>
> public interface LifecycleExtension
> {
> // .... Everything else is the same ....
>
> void access( Object component, Context context, Map session );
> void release( Object component, Context context, Map session );
> }
>
> 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 ?)
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'.
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 ?
Cheers,
Marcus
BTW - Something I still find vexing is getting information into the
extension object itself - ie. getting the current user' identity
in the first place.
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.
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
