On Tue, Jul 23, 2002 at 09:59:09AM -0400, Berin Loritsch wrote:
>
> 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.
ok.
I'm happy to change any part of the LifecycleExtensions to make it
easier and more flexible to use. Just want to make sure I
understand all the changes correctly.
> :/ We can't make the assumption that thread==request.
good :)
> 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.
>
> > ... 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.
Yes, I think we're misunderstanding each other due to terminology -
good idea! :)
I read 'client' to be the person using the application. ie. the
person that clicks on a link in a browser that makes a request, or
the person that presses a button on a swing gui.
Their identity doesn't change while they're using the application,
so I thought your session was to be set across all components they
use (hence the thread==user mixup).
If I understand you correctly, your concept of a 'client' is the
user of a particular component instance ? in which case any
component could be the 'client' of any others it looks up via the
SM passed in during service() ? (is this right ?)
Ok, so following this, each SM passed into service() has its own
session store, which is passed to the LifecycleExtension
implementor for sharing data. Multiple components used by the same
client (client component) will share the same session, allowing
data to be shared across multiple invocations of the
same LifecycleExtensions object.
hmm.. is that right ? perhaps we should get together a little
example to make sure I've understood it correctly ?
> > 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.
So, instead of doing:
public class SomeExtensions extends AbstractLifecycleExtension
{
public void access( Object component, Context context )
{
if ( component instanceof SecurityManageable )
{
// somehow need to get the SecurityManager for this
// user, how ?
// this is what I thought the Context could be used
// for, but for dynamic info like the user on a multi
// user system you need to get some sort of object
// that's updated outside of the container with the
// current user's identity, ie:
UserManager m = (UserManager) context.get(USER_MGR);
User user = m.getCurrentUser();
SecurityManager sm = new UserSecurityManager(user);
// a sessions lets us store the user object, which
// is great, but we still need to get it in the
// place and put it into the session - where?
// now we have the security manager with the users
// credentials, pass it to the component
((SecurityManageable) component).secure(sm);
}
// next component extension interface
}
}
we would end up doing:
public class SomeComponentImpl extends ....
implements SessionEnabled
{
public void setSession(Map session)
{
// set the user object here, so that LifecycleExtension
// implementors can get the user object for later use
UserManager m = m_manager.lookup(UserManager.ROLE);
User user = m.getCurrentUser()
session.set(CURRENT_USER, user);
}
...
}
public class SomeExtensions extends AbstractLifecycleExtension
{
public void access( Object component, Context context, Map session )
{
if ( component instanceof SecurityManageable )
{
// get user from session
User user = (User) session.get(CURRENT_USER);
SecurityManager sm = new UserSecurityManager(user);
// a sessions lets us store the user object, which
// is great, but we still need to get it in the
// place and put it into the session - how and where?
// now we have the security manager with the users
// credentials, pass it to the component
((SecurityManageable) component).secure(sm);
}
// next component extension interface
}
}
Is that what you mean't ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, 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]>
