I've been lurking and searching through the archives searching for an
answer to the issue which was eventually reported as bug #739 I've
found some excellent descriptions of the problem but have been unable to
discover a solution in the archives. I was hoping that someone can
point me towards
Gokul Singh wrote:
- Original Message -
From: "Hans Bergsten" [EMAIL PROTECTED]
Gokul Singh wrote:
Hans Bergsten wrote:
[...]
I am trying to disallow a single user to have multiple login sessions
valid at any given time. I have to enforce this even if the user
Craig R. McClanahan typed the following on 03:44 PM 1/14/2001 -0800
"Christopher K. St. John" wrote:
If your server implements session swapping or distribution (as we are
currently
developing in the 4.1 repository), it is pretty much guaranteed that
different
session object instances
Gokul Singh wrote:
Hans Bergsten wrote:
> [...]
> The spec may not be explicit enough about this, but the session object
> you get back from the getSession() object is a container-managed
object
> that the application is not supposed/allowed to keep long-lived
> references
> to. It's the same
"Christopher K. St. John" wrote:
"Craig R. McClanahan" wrote:
If your server implements session swapping or distribution (as we are currently
developing in the 4.1 repository), it is pretty much guaranteed that different
session object instances may be used during the lifetime of the
Hans Bergsten wrote: [...] The spec may not be explicit
enough about this, but the session object you get back from the
getSession() object is a container-managed object that the application
is not supposed/allowed to keep long-lived references to. It's
the same as with all other
Gokul Singh wrote:
Hans Bergsten wrote:
[...]
The spec may not be explicit enough about this, but the session
object
you get back from the getSession() object is a container-managed
object
that the application is not supposed/allowed to keep long-lived
references
to. It's the
- Original Message -
From: "Hans Bergsten" [EMAIL PROTECTED]
Gokul Singh wrote:
Hans Bergsten wrote:
[...]
I am trying to disallow a single user to have multiple login sessions
valid at any given time. I have to enforce this even if the user tried
to login from two
"Christopher K. St. John" wrote:
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,
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
Hans Bergsten wrote:
I agree that it's reasonable to assume that the same HttpSession
instance is used throughout the session in the most common case,
but I don't agree that the spec mandates this implementation (and
I don't think it should mandate implementation details unless it's
"Craig R. McClanahan" wrote:
If your server implements session swapping or distribution (as we are currently
developing in the 4.1 repository), it is pretty much guaranteed that different
session object instances may be used during the lifetime of the same session.
But don't you get
There lies the catch and the source of problem in my understanding.
In different requests relating to
the same session, I may get referance to HttpSessionFacade instances which
are different, but I expect them to be same (although not guarantied by
specs but I thought it was a tacit
Gokul Singh wrote:
[...]
The reason you see a behavior difference is that Tomcat 3.1 did not
recycle session object instances, but Tomcat 3.2 does.
There lies the catch and the source of problem in my understanding.
In different requests relating to
the same session, I may get referance
Hans Bergsten wrote:
The spec may not be explicit enough about this, but the session object
you get back from the getSession() object is a container-managed object
that the application is not supposed/allowed to keep long-lived
references
to. It's the same as with all other
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
Hi,I am trying to build a login servlet and get a
NullPointerException from HttpSessionFacade class in Tomcat 3.2.1.The code
of the simple version of the servlet which reproduces theproblem is attached
at the end of this mail along with the stack trace of the Exception
thrown.This piece of
17 matches
Mail list logo
