Anyway, there is a solution for it now... deferred session creation :). It's in 2.0, didn't make 1.2 unfortunately, as it would mean two API breaks, but it is scheduled for 1.3 whenever that comes out (I guess that depends on how badly people want it) and you can apply the patch I sent earlier for 1.2.
Eelco On 6/12/06, Alexandru Popescu <[EMAIL PROTECTED]> wrote: > > > Unfortunately this is not completely accurate information. > > > > I was writing about my experience and I wrote it down accurately. > > > > Timo, sorry if you found my comments as offending. There was no such > intention. > > > The session id is stripped from the link in the search result page. At > > least in the cases I had to deal with. That means that the user doesn't > > get a message like "session expired". > > Probably, I am missunderstanding the "session id is stripped from the > link in the search result page" part. I can see it there, and so the > user request will go to the /tralala;jsessionid=value. > > For me stripped from the link means: the link will not contain the > jsessionid part. But this is not true. It is there. Indeed the > application may continue to work correctly as it may create a new > session (so no error message will be displayed), but this is something > that happens on the application side and not on the search engine > side. > > hth, > > ./alex > -- > .w( the_mindstorm )p. > > > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user > _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
