Hans Bergsten wrote:
>
> But in a container that
> saves sessions to disk to conserve memory, or during server restart,
> you will most definitely see more than one instance. Same thing
> for a distributable application, where the session may migrate
> to another server.
>
You can see more than one instance, but you will always
be notified by an HttpSessionEvent. That's part of the
"normal session lifecyle" I mentioned, and I think that
we agree there is no ambiguity in that case.
> and that I'm pretty sure that
> whatever it is you want to do can be done in a way that's more
> likely to be portable
>
You may very well be right, but that's irrelevant. It
doesn't matter if there's a better way, it matters that
according to a reasonable interpretation of the current
spec, it should be legal.
> All I'm saying is that it's dangerous to rely on behavior
> that's not clearly defined by the spec,
>
Well, yes, but you have to be able to make _some_
assumptions, or the spec would be 12 feet thick. In
general, you can assume that if the spec doesn't
specifically allow counterintuitive behavior, then
it's disallowed.
There is admittedly a very fine balancing act that the
spec has to pull off: it must be loose enough to allow
innovative implementations, but strict enough to allow
interoperability.
But give me a break: what JServ is doing in this case
is just fantastically counterintiutive.
This probably needs to be summarized and sent as
spec feedback, but unless he says otherwise I will
assume Gokul Singh is going to do it (Gokul?)
-cks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
