because maurice has a patch!

On Tue, Mar 11, 2008 at 11:02 AM, Maurice Marrink <[EMAIL PROTECTED]> wrote:

> >  I've tried setting statelessHint to true in my login page's constructor
> (and
> >  in the same constructor printing out the result of isStateless(),
> seeing
> >  that it returns true), but still I can see my app's session object
> created
> >  and stored in HttpSession (I've tried also with a completely empty
> login
> >  page, same result). Am I doing something wrong now?
>
> Are you talking about test behavior or real life app behavior?
>
> Maurice
>
> On Tue, Mar 11, 2008 at 10:20 AM, Roberto Fasciolo
>  <[EMAIL PROTECTED]> wrote:
> >
> >  I finally found some time for getting back to this...
> >
> >  The tests are modeled on real user behaviours, so they are not
> invalidating
> >  the session because the user has never logged in (we have failing test
> >  scenarios for login, registration, forget password and so on).
> >
> >  I've tried setting statelessHint to true in my login page's constructor
> (and
> >  in the same constructor printing out the result of isStateless(),
> seeing
> >  that it returns true), but still I can see my app's session object
> created
> >  and stored in HttpSession (I've tried also with a completely empty
> login
> >  page, same result). Am I doing something wrong now?
> >
> >  -Roberto
> >
> >
> >
> >
> >  igor.vaynberg wrote:
> >  >
> >  > no, its not like that. yes, wicket will create a new session object,
> >  > but if the page is stateless that session object is never actually
> >  > saved into httpsession...
> >  >
> >  > you have 20 session active after your tests...do your test cases
> >  > always cleanup/invalidate the session? if not then servlet container
> >  > will keep the session around until it times out...
> >  >
> >  > -igor
> >  >
> >  > On Mon, Mar 3, 2008 at 9:29 AM, Roberto Fasciolo
> >  > <[EMAIL PROTECTED]> wrote:
> >  >>
> >  >>  I think Session has also the responsibility of verifying if a
> component
> >  >> can
> >  >>  be instantiated.
> >  >>
> >  >>  But anyway, I'm asking all these questions because I'm hunting a
> memory
> >  >> leak
> >  >>  in my application and I've found that after running a 120+ tests
> >  >> selenium
> >  >>  test suite I've 20+ sessions still in memory retained by Jetty (e.g
> .
> >  >> active
> >  >>  sessions in the web container) and I'm wondering if that's a
> problem or
> >  >> not.
> >  >>  I've understood now that I have no way to control that, everytime a
> user
> >  >>  opens a page in a wicket app a new Session is created just for
> checking
> >  >> if
> >  >>  that user can instantiate components, regardless of wether the page
> is
> >  >>  stateless or stateful and also if the user has never signed in the
> site.
> >  >> Is
> >  >>  it like that?
> >  >>
> >  >>  -Roberto
> >  >>
> >  >>
> >  >>
> >  >>  igor.vaynberg wrote:
> >  >>  >
> >  >>  > session represents a user's session, while application represents
> the
> >  >>  > application that users access.
> >  >>  >
> >  >>  > -igor
> >  >>  >
> >  >>
> >  >>  --
> >  >>  View this message in context:
> >  >>
> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15808987.html
> >  >>
> >  >>
> >  >> Sent from the Wicket - User mailing list archive at 
> > Nabble.com<http://nabble.com/>
> .
> >  >>
> >  >>
> >  >>
>  ---------------------------------------------------------------------
> >  >>  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  >>  For additional commands, e-mail: [EMAIL PROTECTED]
> >  >>
> >  >>
> >  >
> >  > ---------------------------------------------------------------------
> >  > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  > For additional commands, e-mail: [EMAIL PROTECTED]
> >  >
> >  >
> >  >
> >
> >  --
> >  View this message in context:
> http://www.nabble.com/Strange-thing-in-Application-constructor-tp15786017p15975715.html
> >
> >
> > Sent from the Wicket - User mailing list archive at 
> > Nabble.com<http://nabble.com/>
> .
> >
> >
> >  ---------------------------------------------------------------------
> >  To unsubscribe, e-mail: [EMAIL PROTECTED]
> >  For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Reply via email to