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 a
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 a
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 objec
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 en
- 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
> 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
Christopher K. St. John wrote:> > All I'm saying is that
it's dangerous to rely on behavior> > that's not clearly defined by
the spec, > >> But give me a break: what JServ
is doing in this case> is just fantastically counterintiutive.
I agree with Chris on this.
> This probably needs t
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 cont
"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 o
"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
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
> a
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 tha
"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
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
"Christopher K. St. John" 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
>
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 container-o
> Another solution, IMHO, is to make sure all these objects are only used
> within the thread they where allocated for. Briefly, add a package scope
> setThreadID() method to the classes that implement pooled objects like
> this and let the container call this method with the current thread ID
>
[EMAIL PROTECTED] wrote:
>
> > 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
> >
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 re
> 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 agr
- Original Message -
From: Craig R. McClanahan
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Thanks for looking into the problem. I think the I was not able to convey
the problem properly. I have some clarifications below.
> The session object is valid for more than one request, but only u
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
22 matches
Mail list logo
