> From: Marcus Crafter [mailto:[EMAIL PROTECTED]]
>
> 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.
Ok. For the purpose of this discussion--to avoid confusion--let's use
the following definitions:
user -- the person using the application. i.e. the person that clicks
a link in a browser that makes a request, or the person that
presses a button on a SWING GUI.
client -- the code that uses a component. Analogous to client/server
concept.
> 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 ?)
Yes.
> 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 ?
Yep, that's right. In essence, you can have a pool of components with
the same configuration information, and each instance will act as if it
were the last one you communicated with. It provides the illusion of
threadsafety to the user.
<snip type="lots of code"/>
> Is that what you mean't ?
Pretty much. Now, there are some implications. If we have one Map
per client, that map should probably be used for all components. That
way we can have the User object stored by another component, and used
by this one.
There are probably more things to work out, but we won't know what they
are until we start using it.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
