Hans Bergsten wrote:
>
> "Christopher K. St. John" wrote:
> >
> > 7.3 Session Scope
> >
> > HttpSession objects must be scoped at the
> > application / servlet context level. The
> > underlying mechanism, such as the cookie
> > used to establish the session, can be shared
> > between contexts, but the object exposed, and
> > more importantly the attributes in that object,
> > must not be shared between contexts.
> >
> > By mentioning that the HttpSession object cannot
> > be shared outside the ServletContext, it strongly
> > implies that it can be shared within the context.
> > If that sort of thing isn't allowed, then 7.3 might
> > need to be clarified.
>
> This section refers to the fact that a servlet in one context should
> not be able to gain access to the same session data as a servlet
> in another context (i.e., resources in two different context's can
> not "be part" of the same session) for security reasons .
>
> It has nothing to do with whether a servlet in one context is allowed
> to hold on to the actual session object or not, which has to do with
> how much freedom the spec gives to container vendors in terms of
> pooling and life-cycle management for the internal objects.
>
Because Section 7.3 explicity discusses the HttpSession
object itself (as opposed to the objects it contains), it
suggests that the HttpSession object has an identity.
I don't think there is any question that after the end
of the lifecycle of an HttpSession object, it can be
recycled. But what earlier messages in this thread suggested
was that JServ was recycling HttpSession objects _during_
the lifetime of the session, so that req.getSession(false) could
return two different objects even within the same session.
That would mean that the practice of synchronzing on the
HttpSession object was also not kosher? Since two servlets
within the same session at the same time could not be sure
of getting the same HttpSession object? Are you really
suggesting that that behavior is allowed by the spec?
If so, I find that very unintuitive.
-cks
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
