jakarta-cactus-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject RE: [patch] Two Cactus feature requests (was RE: Cactus - possible bug)
Date Thu, 18 Jul 2002 19:48:24 GMT
Charles,

I have reverted my patch as it was unnecessary. Indeed, after closer
look at the code, Cactus was *not* creating any HTTP session when
getting the test result (I have tested this : request.getSession(false)
always returns null).

Thus there is only one HTTP session per test being created at most (less
if you pass the jsessionid cookie).

FYI, there is no getSession() called anywhere in the code when getting
the test results. In any case, getSession(false) will not create a
session (this is the spec).

I believe your problem is elsewhere.

I need more information in order to help you further.

Thanks
-Vincent

> -----Original Message-----
> From: Charles Massey [mailto:CMassey@corp.classmates.com]
> Sent: 18 July 2002 19:28
> To: 'Cactus Users List'
> Subject: RE: [patch] Two Cactus feature requests (was RE: Cactus -
> possible bug)
> 
> Hi Vincent,
> 
> I had tried setAutomaticSession(false) originally, and unfortunately
it
> does
> not work.  I went ahead and implemented your solution and tried it,
and it
> still doesn't work.  I'm not sure if this is particular to how ATG
Dynamo
> handles the HttpRequest when the getSession method is called.  Perhaps
it
> doesn't find a relevant current session, and wants to create one?
Does it
> work for you?
> 
> Charley
> 
> > -----Original Message-----
> > From: Vincent Massol [mailto:vmassol@octo.com]
> > Sent: Thursday, July 18, 2002 8:43 AM
> > To: 'Cactus Users List'
> > Subject: RE: [patch] Two Cactus feature requests (was RE: Cactus -
> > possible bug)
> >
> >
> > Hi Charles,
> >
> > > -----Original Message-----
> > > From: Charles Massey [mailto:CMassey@corp.classmates.com]
> > > Sent: 17 July 2002 21:59
> > > To: 'cactus-user@jakarta.apache.org'
> > > Subject: RE: [patch] Two Cactus feature requests (was RE: Cactus -
> > > possible bug)
> > >
> > > Hi Vincent,
> > >
> > > We are using the JSESSIONID as a session tracking
> > mechanism.  We keep
> > the
> > > JSESSIONID cookie from the first session that is created, and then
> > > associate
> > > this cookie with further WebRequests.
> > >
> > > The Cactus client code right now makes calls to the
> > ServletTestRedirector,
> > > once to call the testXXX method and once to retrieve the
> > result.  The
> > > beginXXX method allows the user to modify the WebRequest
> > object before
> > the
> > > call to the testXXX method on the server.  The WebRequest to get
the
> > test
> > > results does not use the WebRequest that is initialized in the
> > beginXXX
> > > method -- it is brand new, and therefore it does not use our
> > JSESSIONID
> > > cookie.
> >
> > Yes, and this is normal and intended by design! :-)
> >
> > Indeed, the result of the test is stored in the application
> > scope (i.e.
> > servlet context) :
> >
> >
this.webImplicitObjects.getServletContext().setAttribute(TEST_RESULTS,
> > result);
> >
> > You don't need any HTTP session to retrieve the value.
> >
> > >
> > > I would like the WebRequest that is used to get the test
> > results to be
> > > same
> > > that is initialized in the beginXXX method, although my feature
> > request
> > > only
> > > specifies that the cookies be added to the WebRequest.  The
> > reason is
> > that
> > > for each call to get the test results, a new session is
> > created on the
> > > Dynamo server, and we currently have a maximum of 20 sessions on
our
> > > developer licenses.
> > >
> > > What do you think?
> >
> > Ah yes, I remember now the reason ... Hum ... The problem is that
the
> > Cactus code is perfectly correct ... What I can do, which seems
better
> > to me is ensure that no HTTP session is created when
> > retrieving the Test
> > result (this would be normal as a session is not needed).
> >
> > I'll implement that now ... done ... I have just added one line:
> >
> >     private WebTestResult callGetResult(
> >         AbstractAuthentication theAuthentication) throws Throwable
> >     {
> >  [...]
> >         // Do not create an HTTP session as it is not needed
> > to retrieve
> > the
> >         // results
> >         resultsRequest.setAutomaticSession(false);
> > [...]
> >
> > Can you try this and tell me if it solves your problem (it should!).
> >
> > Thanks a lot
> > -Vincent
> >
> > >
> > > Thanks,
> > > Charley
> > >
> > >
> > > ---
> > > From: Vincent Massol
> > > Subject: RE: [patch] Two Cactus feature requests (was RE: Cactus -
> > > possible
> > > bug)
> > > Date: Tue, 16 Jul 2002 15:18:43 -0700
> > >
> > > Hi Charles,
> > >
> > > I was starting to apply your patch WRT setting the cookies in the
> > > request when I started to ask myself some question about
> > this ... :-)
> > >
> > > Could you provide more details ? Certainly it is not about
> > the session
> > > cookie (jsessionid) as I don't see how it can relate to the
Servlet
> > > Config object ?
> > >
> > > Can you send us the list of cookies that you need to set up when
> > calling
> > > a servlet ? Do you always need to set these cookies ?
> > >
> > > My point is that Cactus need to abide by the Servlet 2.2
> > and 2.3 spec
> > > and I don't see how what it is doing is not conformant to
> > any part of
> > > the spec.
> > >
> > > The 2 HTTP request (run the test, get the result) are completely
> > > independent (and are meant to be independent by design).
> > The result of
> > > the first request is saved in the application scope (not in the
> > session
> > > scope) and thus there doesn't need to be any cookie in the second
> > > request.
> > >
> > > I'm not against applying your patch, but I need more details to
> > > understand the rationale.
> > >
> > > Thanks
> > > -Vincent
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:cactus-user-
> > > unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:cactus-user-
> > > help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:cactus-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:cactus-user-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:cactus-user-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:cactus-user-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:cactus-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-user-help@jakarta.apache.org>


Mime
View raw message