Re: Session creation with stateless pages in Chrome
Hi! Ok, so just to confirm: your original post states that you see a bound wicket session when loading a stateless page with google chrome, but Session.bind() is never called? For as far as I know when wicket binds a sessions it always does so through Session.bind(). So if that is not called, there's another piece of code outside wicket which binds the session. Do you have any other servlets or servlet filters in place? How do you know a wicket session is bound? And how are you checking if Session.bind() is called? Met vriendelijke groet, Kind regards, Bas Gooren Op 29-5-2013 8:36, schreef ChambreNoire: That's the problem. Session.bind() isn't called. I put a breakpoin in AbstractHttpSessionStore.bind() but still it's hard to tell what's causing this to be called... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659122.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session creation with stateless pages in Chrome
That's the problem. Session.bind() isn't called. I put a breakpoin in AbstractHttpSessionStore.bind() but still it's hard to tell what's causing this to be called... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659122.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session creation with stateless pages in Chrome
Simply by having a look at your tomcat (or reverse proxy) access log? Of course this is only needed if the page you are hitting has links to other, stateful pages. You can also set a breakpoint in Session.bind() to see when it's called. Met vriendelijke groet, Kind regards, Bas Gooren Op 28-5-2013 15:59, schreef ChambreNoire: How would I check this? I disabled "Predict network actions to improve page load performance" but that hasn't changed anything. Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659111.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session creation with stateless pages in Chrome
How would I check this? I disabled "Predict network actions to improve page load performance" but that hasn't changed anything. Thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106p4659111.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session creation with stateless pages in Chrome
Have you checked if Chrome is prefetching other pages (which may be stateful)? Met vriendelijke groet, Kind regards, Bas Gooren Op 28-5-2013 12:14, schreef ChambreNoire: Hello folks, I have rendered all of my pre-login wicket pages fully stateless. I have just noticed that while no wicket sessions are created until a valid login occurs using most browsers, when accessing the site via Google Chrome, the wicket session is bound after the initial rendering. As for various reasons I have opted to extract cetain pageparameters within the wicket session constructor, this is problematic. I suppose could always move this pageparameter extraction into the various stateless pages which need these parameters (and thus duplicate it) however I'd like to know why on earth this happens exclusively with Google Chrome (in case it's symptomatic of some other undetected problem). Any ideas? Thanks, Anthony -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Session-creation-with-stateless-pages-in-Chrome-tp4659106.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: session creation and stateless
see wicket-dev-utils, there is a stateless checker there that can help you. wicket's session object is created on every request, but while the app is not stateful it is not persisted/put into httpsession. so you will always have a session object during a wicket request. there is page.ispagestateless() that will tell you if the page is stateless or not after render. -igor On Wed, May 20, 2009 at 6:49 AM, adrien le roy wrote: > Hello, > > I am a little bit confuse about about how to test if a session have > been created in a Panel > I was using Session.get() but it is creating session if it don't exists. > Regarding stateless page, how to test if a page is stateless ? > If I have understood well, a page is considered statefull when a > session is created during requestcycle? > > Thanks > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session creation
Okay, that makes sense. Thanks a lot! On Sun, Aug 24, 2008 at 3:00 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote: > yes. Explicitly binding won't have an adverse effect if that is your > intention. Delayed (http) session creation is done to prevent an easy > DoS vector (though if your application at some point does create a > session, someone will find out and there you are...), and improve > scalability—having no session means not having to distribute that data > across the cluster. > > Martijn > > On Sun, Aug 24, 2008 at 11:14 PM, nate roe <[EMAIL PROTECTED]> wrote: >> The use of Session.bind() has resolved my problem. >> >> If I have a bookmarkable login page, then, I suppose I should bind the >> session before storing the user's data to the session? >> >> On Sat, Aug 23, 2008 at 9:15 PM, brian.diekelman <[EMAIL PROTECTED]> wrote: >>> >>> It depends on the situation and your logging setup. Do this to verify: >>> >>> - First put a logging statement in WebApplication.newSession(), not >>> MySession.get() >>> >>> - Open a new browser window and go to your 'verify' bookmarkable page. You >>> should see a new session created on each refresh >>> >>> - Now put 'getSession().bind()' somewhere in your page constructor. >>> >>> - Cycle/redeploy the app and go to the 'verify' bookmarkable page. You >>> should only see one session created, and it should reuse that session on >>> each refresh. >>> >>> >>> If any of the above didn't happen as described, that's what I would call >>> unexpected behavior. Otherwise, what was the expected vs actual behavior? >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Session-creation-tp19123581p19127645.html >>> Sent from the Wicket - User mailing list archive at 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] >> >> > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com > Apache Wicket 1.3.4 is released > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. > > - > 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]
Re: Session creation
yes. Explicitly binding won't have an adverse effect if that is your intention. Delayed (http) session creation is done to prevent an easy DoS vector (though if your application at some point does create a session, someone will find out and there you are...), and improve scalability—having no session means not having to distribute that data across the cluster. Martijn On Sun, Aug 24, 2008 at 11:14 PM, nate roe <[EMAIL PROTECTED]> wrote: > The use of Session.bind() has resolved my problem. > > If I have a bookmarkable login page, then, I suppose I should bind the > session before storing the user's data to the session? > > On Sat, Aug 23, 2008 at 9:15 PM, brian.diekelman <[EMAIL PROTECTED]> wrote: >> >> It depends on the situation and your logging setup. Do this to verify: >> >> - First put a logging statement in WebApplication.newSession(), not >> MySession.get() >> >> - Open a new browser window and go to your 'verify' bookmarkable page. You >> should see a new session created on each refresh >> >> - Now put 'getSession().bind()' somewhere in your page constructor. >> >> - Cycle/redeploy the app and go to the 'verify' bookmarkable page. You >> should only see one session created, and it should reuse that session on >> each refresh. >> >> >> If any of the above didn't happen as described, that's what I would call >> unexpected behavior. Otherwise, what was the expected vs actual behavior? >> >> -- >> View this message in context: >> http://www.nabble.com/Session-creation-tp19123581p19127645.html >> Sent from the Wicket - User mailing list archive at 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] > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
The use of Session.bind() has resolved my problem. If I have a bookmarkable login page, then, I suppose I should bind the session before storing the user's data to the session? On Sat, Aug 23, 2008 at 9:15 PM, brian.diekelman <[EMAIL PROTECTED]> wrote: > > It depends on the situation and your logging setup. Do this to verify: > > - First put a logging statement in WebApplication.newSession(), not > MySession.get() > > - Open a new browser window and go to your 'verify' bookmarkable page. You > should see a new session created on each refresh > > - Now put 'getSession().bind()' somewhere in your page constructor. > > - Cycle/redeploy the app and go to the 'verify' bookmarkable page. You > should only see one session created, and it should reuse that session on > each refresh. > > > If any of the above didn't happen as described, that's what I would call > unexpected behavior. Otherwise, what was the expected vs actual behavior? > > -- > View this message in context: > http://www.nabble.com/Session-creation-tp19123581p19127645.html > Sent from the Wicket - User mailing list archive at 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]
Re: Session creation
Your application consists currently of only stateless pages. Wicket
will try to remain stateless until it is necessary, and keep
creating/discarding session objects until a stateful page comes along
(or rather, a session relative URL).
Read [1] for more information.
Martijn
[1] http://www.nabble.com/Status-of-Delayed-Session-Creation-td10999236.html
On Sat, Aug 23, 2008 at 7:48 PM, nate roe <[EMAIL PROTECTED]> wrote:
> I've created a new Wicket application following the session creation
> pattern illustrated in Wicket in Action, but for reasons not obvious
> to me, every web request returns an entirely new session.
>
> This is my application:
>
> public class MyApplication extends WebApplication {
>Logger logger = Logger.getLogger(MyApplication.class);
>
>public MyApplication() {
>mountBookmarkablePage("verify", VerificationPage.class);
>mountBookmarkablePage("register", RegistrationPage.class);
>}
>
>public Class getHomePage() {
>return LoginPage.class;
>}
>
>@Override
>public Session newSession(Request request, Response response) {
>logger.debug("new session!");
>
>return new MySession(request);
>}
> }
>
>
> And this is my session:
>
> public class MySession extends WebSession {
>
>private static final long serialVersionUID = 1L;
>
>private Account account;
>
>public MySession(Request request) {
>super(request);
>setLocale(Locale.ENGLISH);
>}
>
>public static MySession get() {
>return (MySession) Session.get();
>}
>
>public boolean isAuthenticated() {
>return account != null;
>}
>
>public Account getAccount() {
>return account;
>}
>
>public void setAccount(Account account) {
>this.account = account;
>}
> }
>
> What have I done wrong?
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
It depends on the situation and your logging setup. Do this to verify: - First put a logging statement in WebApplication.newSession(), not MySession.get() - Open a new browser window and go to your 'verify' bookmarkable page. You should see a new session created on each refresh - Now put 'getSession().bind()' somewhere in your page constructor. - Cycle/redeploy the app and go to the 'verify' bookmarkable page. You should only see one session created, and it should reuse that session on each refresh. If any of the above didn't happen as described, that's what I would call unexpected behavior. Otherwise, what was the expected vs actual behavior? -- View this message in context: http://www.nabble.com/Session-creation-tp19123581p19127645.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
I would get errors or at least warnings in that case though, yes? On Sat, Aug 23, 2008 at 3:31 PM, brian.diekelman <[EMAIL PROTECTED]> wrote: > > Something I just saw... make sure Account implements java.io.Serializable > > If it doesn't the session won't be persisted, so it would try to re-create > it each request. > -- > View this message in context: > http://www.nabble.com/Session-creation-tp19123581p19125999.html > Sent from the Wicket - User mailing list archive at 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]
Re: Session creation
Something I just saw... make sure Account implements java.io.Serializable If it doesn't the session won't be persisted, so it would try to re-create it each request. -- View this message in context: http://www.nabble.com/Session-creation-tp19123581p19125999.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
I've tried this with both IE and Firefox, both with cookies on and no exceptions, but it looks like my app is not writing a jsessionid cookie. Maybe I've misconfigured tomcat? On Sat, Aug 23, 2008 at 12:27 PM, brian.diekelman <[EMAIL PROTECTED]> wrote: > > > Are you running another server/service on the same machine that would > overwrite the 'jsessionid' cookie? > > I was running into this when my CI server (java-based) and auto-built dev > server were on the same machine/IP address. When I would switch from my dev > build to my CI server interface it would overwrite 'jsessionid'. > > > Along those same lines, do you have cookies turned off in the browser? > -- > View this message in context: > http://www.nabble.com/Session-creation-tp19123581p19124374.html > Sent from the Wicket - User mailing list archive at 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]
Re: Session creation
Are you running another server/service on the same machine that would overwrite the 'jsessionid' cookie? I was running into this when my CI server (java-based) and auto-built dev server were on the same machine/IP address. When I would switch from my dev build to my CI server interface it would overwrite 'jsessionid'. Along those same lines, do you have cookies turned off in the browser? -- View this message in context: http://www.nabble.com/Session-creation-tp19123581p19124374.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
If I log from MySession.get(), I observe the session changing between
requests. For a given request, the session seems stable, but it looks
like every request gets a new session. If I reload a page, I get a
new session.
On Sat, Aug 23, 2008 at 11:47 AM, francisco treacy
<[EMAIL PROTECTED]> wrote:
> with that exact setup in my webapps, if i do something like
>
> public static MySession get() {
> logger.debug(Session.get());
> return (MySession) Session.get();
> }
>
> i always observe the same session in the logs, for any page that
> requests it ([EMAIL PROTECTED]). don't you? you mean
> newSession is called several times during the app's lifecycle?
>
> francisco
>
>
> On Sat, Aug 23, 2008 at 7:48 PM, nate roe <[EMAIL PROTECTED]> wrote:
>> I've created a new Wicket application following the session creation
>> pattern illustrated in Wicket in Action, but for reasons not obvious
>> to me, every web request returns an entirely new session.
>>
>> This is my application:
>>
>> public class MyApplication extends WebApplication {
>>Logger logger = Logger.getLogger(MyApplication.class);
>>
>>public MyApplication() {
>>mountBookmarkablePage("verify", VerificationPage.class);
>>mountBookmarkablePage("register", RegistrationPage.class);
>>}
>>
>>public Class getHomePage() {
>>return LoginPage.class;
>>}
>>
>>@Override
>>public Session newSession(Request request, Response response) {
>>logger.debug("new session!");
>>
>>return new MySession(request);
>>}
>> }
>>
>>
>> And this is my session:
>>
>> public class MySession extends WebSession {
>>
>>private static final long serialVersionUID = 1L;
>>
>>private Account account;
>>
>>public MySession(Request request) {
>>super(request);
>>setLocale(Locale.ENGLISH);
>>}
>>
>>public static MySession get() {
>>return (MySession) Session.get();
>>}
>>
>>public boolean isAuthenticated() {
>>return account != null;
>>}
>>
>>public Account getAccount() {
>>return account;
>>}
>>
>>public void setAccount(Account account) {
>>this.account = account;
>>}
>> }
>>
>> What have I done wrong?
>>
>> -
>> 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]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session creation
with that exact setup in my webapps, if i do something like
public static MySession get() {
logger.debug(Session.get());
return (MySession) Session.get();
}
i always observe the same session in the logs, for any page that
requests it ([EMAIL PROTECTED]). don't you? you mean
newSession is called several times during the app's lifecycle?
francisco
On Sat, Aug 23, 2008 at 7:48 PM, nate roe <[EMAIL PROTECTED]> wrote:
> I've created a new Wicket application following the session creation
> pattern illustrated in Wicket in Action, but for reasons not obvious
> to me, every web request returns an entirely new session.
>
> This is my application:
>
> public class MyApplication extends WebApplication {
>Logger logger = Logger.getLogger(MyApplication.class);
>
>public MyApplication() {
>mountBookmarkablePage("verify", VerificationPage.class);
>mountBookmarkablePage("register", RegistrationPage.class);
>}
>
>public Class getHomePage() {
>return LoginPage.class;
>}
>
>@Override
>public Session newSession(Request request, Response response) {
>logger.debug("new session!");
>
>return new MySession(request);
>}
> }
>
>
> And this is my session:
>
> public class MySession extends WebSession {
>
>private static final long serialVersionUID = 1L;
>
>private Account account;
>
>public MySession(Request request) {
>super(request);
>setLocale(Locale.ENGLISH);
>}
>
>public static MySession get() {
>return (MySession) Session.get();
>}
>
>public boolean isAuthenticated() {
>return account != null;
>}
>
>public Account getAccount() {
>return account;
>}
>
>public void setAccount(Account account) {
>this.account = account;
>}
> }
>
> What have I done wrong?
>
> -
> 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]
Re: Session Creation Problem
stateless form generates a bookmarkable action url so the page instance is recreated when the form submits rather then pulled from session. -igor On Fri, Jun 20, 2008 at 1:12 PM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > Hi, > > thanks again for your help, replacing the form by the stateless form has > done > the job as I could verify by lowering the http session timeout. What I still > do > not fully understand is why the error has now disappeared because still a > full > http session is created as I can see from the Tomcat Management Console. > Anyway, > perhaps I will take me some time to figure it out by looking into the > source... > > Thanks, > > J. > > Igor Vaynberg wrote: >> >> once the wicket sesson object is "bound" (stored in httpsesson) their >> lifecycles are the same. it is httpsession timing out that causes page >> expired errors. >> >> -igor >> >> On Fri, Jun 20, 2008 at 9:08 AM, Jürgen Lind <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi Igor, >>> >>> thanks for your support. Still I am a bit confused about the two types >>> of sessions we are dealing with: as far as I understood, there is a >>> wicket >>> session that is stored within the http session of the container. Now, >>> which >>> session is responsible for the "Page Expired" situations? The Wicket >>> session >>> or the http session? If it would be the http session then it should not >>> matter >>> whether a wicket session is created or not as long as the wicket session >>> is >>> not bound to a http session, right? BTW: for not wasting your time, any >>> links >>> to documentation on the matter would be great as well. I looked through >>> the >>> wicket docs but did not find anything relevant. >>> >>> Cheers, >>> >>> J. >>> >>> Igor Vaynberg wrote: wicket will create session instances for every request if there is no session stored in httpsession. the session is stored into httpsession only when the user encounters a stateful page. i am guessing that since you changed the form to stateless the page itself is no longer stateful and so wicket will not save it into session, thus it creates an interim session for the duration of the request. if you want to manually bind the session then call bind() on it. -igor On Fri, Jun 20, 2008 at 8:43 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > > Hi, > > I tried using a stateless form for the Login page, but it seems that a > new > session is created before the page is even called. I inserted a > stacktrack > output in the constructor of my Wicket-Session (which happens to be s > subclass > of AuthenticatedWebSession) and that trace shows me that > AuthenticatedWebApplication.newSession is called by wicket somewhere in > the > application lifecycle. > > I can reproduce the behavior by adding a "logout" link that invalidates > the > current session and redirects to the Homepage (implying a redirect to > the > Login > page). Again, a new session is created immediately by wicket. Any > clues? > > J. > > Igor Vaynberg wrote: >> >> use a stateless form >> >> -igor >> >> On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind >> <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> >>> I am facing a little annoyance in conjunction with session creation >>> that >>> I >>> have >>> been unable to fix until now: >>> >>> 1. My pages are guarded using MetaDataRoleAuthorizationStrategy >>> 2. When the homepage is opened, the user is redirected to the Login >>> page >>> 3. Now, if the user does not fill out the form immediately but waits >>> very >>> long, >>> a "Page Expired" error is thrown when the form is submitted >>> >>> As I said, this is not a big problem but rather an annoyance that I >>> would >>> like >>> to have fixed. Can anybody tell me what the problem is? I assume that >>> a >>> session >>> is created immediately when the user opens the home page. How can I >>> avoid >>> this >>> behavior? >>> >>> Kind Regards, >>> >>> Jürgen >>> >>> -- >>> Dr. Jürgen Lind >>> iteratec GmbHFon: +49 (0)89 614551-44 >>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 >>> 82008 Unterhaching Web: www.iteratec.de >>> >>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519 >>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf >>> Menzel >>> >>> >>> - >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands,
Re: Session Creation Problem
Hi, thanks again for your help, replacing the form by the stateless form has done the job as I could verify by lowering the http session timeout. What I still do not fully understand is why the error has now disappeared because still a full http session is created as I can see from the Tomcat Management Console. Anyway, perhaps I will take me some time to figure it out by looking into the source... Thanks, J. Igor Vaynberg wrote: once the wicket sesson object is "bound" (stored in httpsesson) their lifecycles are the same. it is httpsession timing out that causes page expired errors. -igor On Fri, Jun 20, 2008 at 9:08 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi Igor, thanks for your support. Still I am a bit confused about the two types of sessions we are dealing with: as far as I understood, there is a wicket session that is stored within the http session of the container. Now, which session is responsible for the "Page Expired" situations? The Wicket session or the http session? If it would be the http session then it should not matter whether a wicket session is created or not as long as the wicket session is not bound to a http session, right? BTW: for not wasting your time, any links to documentation on the matter would be great as well. I looked through the wicket docs but did not find anything relevant. Cheers, J. Igor Vaynberg wrote: wicket will create session instances for every request if there is no session stored in httpsession. the session is stored into httpsession only when the user encounters a stateful page. i am guessing that since you changed the form to stateless the page itself is no longer stateful and so wicket will not save it into session, thus it creates an interim session for the duration of the request. if you want to manually bind the session then call bind() on it. -igor On Fri, Jun 20, 2008 at 8:43 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi, I tried using a stateless form for the Login page, but it seems that a new session is created before the page is even called. I inserted a stacktrack output in the constructor of my Wicket-Session (which happens to be s subclass of AuthenticatedWebSession) and that trace shows me that AuthenticatedWebApplication.newSession is called by wicket somewhere in the application lifecycle. I can reproduce the behavior by adding a "logout" link that invalidates the current session and redirects to the Homepage (implying a redirect to the Login page). Again, a new session is created immediately by wicket. Any clues? J. Igor Vaynberg wrote: use a stateless form -igor On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi, I am facing a little annoyance in conjunction with session creation that I have been unable to fix until now: 1. My pages are guarded using MetaDataRoleAuthorizationStrategy 2. When the homepage is opened, the user is redirected to the Login page 3. Now, if the user does not fill out the form immediately but waits very long, a "Page Expired" error is thrown when the form is submitted As I said, this is not a big problem but rather an annoyance that I would like to have fixed. Can anybody tell me what the problem is? I assume that a session is created immediately when the user opens the home page. How can I avoid this behavior? Kind Regards, Jürgen -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - 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] -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - 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] -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt
Re: Session Creation Problem
once the wicket sesson object is "bound" (stored in httpsesson) their lifecycles are the same. it is httpsession timing out that causes page expired errors. -igor On Fri, Jun 20, 2008 at 9:08 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > Hi Igor, > > thanks for your support. Still I am a bit confused about the two types > of sessions we are dealing with: as far as I understood, there is a wicket > session that is stored within the http session of the container. Now, which > session is responsible for the "Page Expired" situations? The Wicket session > or the http session? If it would be the http session then it should not > matter > whether a wicket session is created or not as long as the wicket session is > not bound to a http session, right? BTW: for not wasting your time, any > links > to documentation on the matter would be great as well. I looked through the > wicket docs but did not find anything relevant. > > Cheers, > > J. > > Igor Vaynberg wrote: >> >> wicket will create session instances for every request if there is no >> session stored in httpsession. the session is stored into httpsession >> only when the user encounters a stateful page. >> >> i am guessing that since you changed the form to stateless the page >> itself is no longer stateful and so wicket will not save it into >> session, thus it creates an interim session for the duration of the >> request. >> >> if you want to manually bind the session then call bind() on it. >> >> -igor >> >> On Fri, Jun 20, 2008 at 8:43 AM, Jürgen Lind <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> >>> I tried using a stateless form for the Login page, but it seems that a >>> new >>> session is created before the page is even called. I inserted a >>> stacktrack >>> output in the constructor of my Wicket-Session (which happens to be s >>> subclass >>> of AuthenticatedWebSession) and that trace shows me that >>> AuthenticatedWebApplication.newSession is called by wicket somewhere in >>> the >>> application lifecycle. >>> >>> I can reproduce the behavior by adding a "logout" link that invalidates >>> the >>> current session and redirects to the Homepage (implying a redirect to >>> the >>> Login >>> page). Again, a new session is created immediately by wicket. Any clues? >>> >>> J. >>> >>> Igor Vaynberg wrote: use a stateless form -igor On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > > Hi, > > I am facing a little annoyance in conjunction with session creation > that > I > have > been unable to fix until now: > > 1. My pages are guarded using MetaDataRoleAuthorizationStrategy > 2. When the homepage is opened, the user is redirected to the Login > page > 3. Now, if the user does not fill out the form immediately but waits > very > long, > a "Page Expired" error is thrown when the form is submitted > > As I said, this is not a big problem but rather an annoyance that I > would > like > to have fixed. Can anybody tell me what the problem is? I assume that a > session > is created immediately when the user opens the home page. How can I > avoid > this > behavior? > > Kind Regards, > > Jürgen > > -- > Dr. Jürgen Lind > iteratec GmbHFon: +49 (0)89 614551-44 > Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 > 82008 Unterhaching Web: www.iteratec.de > > Sitz und Registergericht der iteratec GmbH: München HRB 113 519 > Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf > Menzel > > > - > 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] >>> -- >>> Mit freundlichen Grüßen, >>> >>> Jürgen Lind >>> >>> -- >>> Dr. Jürgen Lind >>> iteratec GmbHFon: +49 (0)89 614551-44 >>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 >>> 82008 Unterhaching Web: www.iteratec.de >>> >>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519 >>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel >>> >>> >>> - >>> 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] >> > > -- > Mit freundlichen Grüßen, > > Jürgen Lind > > -- > Dr. Jürgen Lind > iteratec GmbHFon: +49 (0)89 614551-44 > Inselkammerstrasse 4 Fax: +49 (0)89 614551-1
Re: Session Creation Problem
Hi Igor, thanks for your support. Still I am a bit confused about the two types of sessions we are dealing with: as far as I understood, there is a wicket session that is stored within the http session of the container. Now, which session is responsible for the "Page Expired" situations? The Wicket session or the http session? If it would be the http session then it should not matter whether a wicket session is created or not as long as the wicket session is not bound to a http session, right? BTW: for not wasting your time, any links to documentation on the matter would be great as well. I looked through the wicket docs but did not find anything relevant. Cheers, J. Igor Vaynberg wrote: wicket will create session instances for every request if there is no session stored in httpsession. the session is stored into httpsession only when the user encounters a stateful page. i am guessing that since you changed the form to stateless the page itself is no longer stateful and so wicket will not save it into session, thus it creates an interim session for the duration of the request. if you want to manually bind the session then call bind() on it. -igor On Fri, Jun 20, 2008 at 8:43 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi, I tried using a stateless form for the Login page, but it seems that a new session is created before the page is even called. I inserted a stacktrack output in the constructor of my Wicket-Session (which happens to be s subclass of AuthenticatedWebSession) and that trace shows me that AuthenticatedWebApplication.newSession is called by wicket somewhere in the application lifecycle. I can reproduce the behavior by adding a "logout" link that invalidates the current session and redirects to the Homepage (implying a redirect to the Login page). Again, a new session is created immediately by wicket. Any clues? J. Igor Vaynberg wrote: use a stateless form -igor On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi, I am facing a little annoyance in conjunction with session creation that I have been unable to fix until now: 1. My pages are guarded using MetaDataRoleAuthorizationStrategy 2. When the homepage is opened, the user is redirected to the Login page 3. Now, if the user does not fill out the form immediately but waits very long, a "Page Expired" error is thrown when the form is submitted As I said, this is not a big problem but rather an annoyance that I would like to have fixed. Can anybody tell me what the problem is? I assume that a session is created immediately when the user opens the home page. How can I avoid this behavior? Kind Regards, Jürgen -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - 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] -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - 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] -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Creation Problem
wicket will create session instances for every request if there is no session stored in httpsession. the session is stored into httpsession only when the user encounters a stateful page. i am guessing that since you changed the form to stateless the page itself is no longer stateful and so wicket will not save it into session, thus it creates an interim session for the duration of the request. if you want to manually bind the session then call bind() on it. -igor On Fri, Jun 20, 2008 at 8:43 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > Hi, > > I tried using a stateless form for the Login page, but it seems that a new > session is created before the page is even called. I inserted a stacktrack > output in the constructor of my Wicket-Session (which happens to be s > subclass > of AuthenticatedWebSession) and that trace shows me that > AuthenticatedWebApplication.newSession is called by wicket somewhere in the > application lifecycle. > > I can reproduce the behavior by adding a "logout" link that invalidates the > current session and redirects to the Homepage (implying a redirect to the > Login > page). Again, a new session is created immediately by wicket. Any clues? > > J. > > Igor Vaynberg wrote: >> >> use a stateless form >> >> -igor >> >> On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> >> wrote: >>> >>> Hi, >>> >>> I am facing a little annoyance in conjunction with session creation that >>> I >>> have >>> been unable to fix until now: >>> >>> 1. My pages are guarded using MetaDataRoleAuthorizationStrategy >>> 2. When the homepage is opened, the user is redirected to the Login page >>> 3. Now, if the user does not fill out the form immediately but waits very >>> long, >>> a "Page Expired" error is thrown when the form is submitted >>> >>> As I said, this is not a big problem but rather an annoyance that I would >>> like >>> to have fixed. Can anybody tell me what the problem is? I assume that a >>> session >>> is created immediately when the user opens the home page. How can I avoid >>> this >>> behavior? >>> >>> Kind Regards, >>> >>> Jürgen >>> >>> -- >>> Dr. Jürgen Lind >>> iteratec GmbHFon: +49 (0)89 614551-44 >>> Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 >>> 82008 Unterhaching Web: www.iteratec.de >>> >>> Sitz und Registergericht der iteratec GmbH: München HRB 113 519 >>> Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel >>> >>> >>> - >>> 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] >> > > -- > Mit freundlichen Grüßen, > > Jürgen Lind > > -- > Dr. Jürgen Lind > iteratec GmbHFon: +49 (0)89 614551-44 > Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 > 82008 Unterhaching Web: www.iteratec.de > > Sitz und Registergericht der iteratec GmbH: München HRB 113 519 > Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel > > > - > 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]
Re: Session Creation Problem
Hi, I tried using a stateless form for the Login page, but it seems that a new session is created before the page is even called. I inserted a stacktrack output in the constructor of my Wicket-Session (which happens to be s subclass of AuthenticatedWebSession) and that trace shows me that AuthenticatedWebApplication.newSession is called by wicket somewhere in the application lifecycle. I can reproduce the behavior by adding a "logout" link that invalidates the current session and redirects to the Homepage (implying a redirect to the Login page). Again, a new session is created immediately by wicket. Any clues? J. Igor Vaynberg wrote: use a stateless form -igor On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: Hi, I am facing a little annoyance in conjunction with session creation that I have been unable to fix until now: 1. My pages are guarded using MetaDataRoleAuthorizationStrategy 2. When the homepage is opened, the user is redirected to the Login page 3. Now, if the user does not fill out the form immediately but waits very long, a "Page Expired" error is thrown when the form is submitted As I said, this is not a big problem but rather an annoyance that I would like to have fixed. Can anybody tell me what the problem is? I assume that a session is created immediately when the user opens the home page. How can I avoid this behavior? Kind Regards, Jürgen -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - 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] -- Mit freundlichen Grüßen, Jürgen Lind -- Dr. Jürgen Lind iteratec GmbHFon: +49 (0)89 614551-44 Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 82008 Unterhaching Web: www.iteratec.de Sitz und Registergericht der iteratec GmbH: München HRB 113 519 Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session Creation Problem
use a stateless form -igor On Fri, Jun 20, 2008 at 1:21 AM, Jürgen Lind <[EMAIL PROTECTED]> wrote: > Hi, > > I am facing a little annoyance in conjunction with session creation that I > have > been unable to fix until now: > > 1. My pages are guarded using MetaDataRoleAuthorizationStrategy > 2. When the homepage is opened, the user is redirected to the Login page > 3. Now, if the user does not fill out the form immediately but waits very > long, > a "Page Expired" error is thrown when the form is submitted > > As I said, this is not a big problem but rather an annoyance that I would > like > to have fixed. Can anybody tell me what the problem is? I assume that a > session > is created immediately when the user opens the home page. How can I avoid > this > behavior? > > Kind Regards, > > Jürgen > > -- > Dr. Jürgen Lind > iteratec GmbHFon: +49 (0)89 614551-44 > Inselkammerstrasse 4 Fax: +49 (0)89 614551-10 > 82008 Unterhaching Web: www.iteratec.de > > Sitz und Registergericht der iteratec GmbH: München HRB 113 519 > Geschäftsführer: Klaus Eberhardt, Mark Goerke, Inge Hanschke, Ralf Menzel > > > - > 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]
