Session problem - object stays in after invalidate()
Hi,
i am trying to implement a simple authentization.
I've basically copied what's in the auth example #2 in wicket examples,
and have a Logout button:
add( new Link(logoutLink) {
@Override public void onClick() {
sess.invalidateNow();
setResponsePage( HomePage.class );
}
}
.add( new Label(label, Logout +
sess.getUser().getName()) )
Which, when clicked, is performed, but in the second request, the User
object, which set to null in my overriden signOut(), is back in my
session object. Not sure if the same obj, but the same values.
What could be wrong?
Thanks,
Ondra
Re: Session problem - object stays in after invalidate()
Which, when clicked, is performed, but in the second request, the User object, which set to null in my overriden signOut(), is back in my when are you exactly calling signOut? cant be deduced from your snippet and comment. Session.invalidateNow won't remove your custom session properties by itself, but only the Wicket components. session object. Not sure if the same obj, but the same values. may you debug and verify hashCode to validate same object or not - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Session problem - object stays in after invalidate()
Hi,
You need to use Session#invalidate() actually.
#invalidate() schedules a call to #invalidateNow() at the end of the
request cycle.
By using #invalidateNow() you invalidate the current http session and
right after this your app creates a new Session because it needs to
finish the request cycle and the new one is what you see later. You
can print the hashcodes to see whether I'm right.
On Thu, Sep 27, 2012 at 9:04 AM, Ondrej Zizka ozi...@redhat.com wrote:
Hi,
i am trying to implement a simple authentization.
I've basically copied what's in the auth example #2 in wicket examples,
and have a Logout button:
add( new Link(logoutLink) {
@Override public void onClick() {
sess.invalidateNow();
setResponsePage( HomePage.class );
}
}
.add( new Label(label, Logout +
sess.getUser().getName()) )
Which, when clicked, is performed, but in the second request, the User
object, which set to null in my overriden signOut(), is back in my
session object. Not sure if the same obj, but the same values.
What could be wrong?
Thanks,
Ondra
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Solved // Re: Session problem - object stays in after invalidate()
Solved.
I was writing an original reply, using I think I have something
conceptually wrong, when it hit my mind:
One of the components (the login/logout box) has this:
final EsscAuthSession sess = (EsscAuthSession)getSession();
and the onClick() was like
add( new Link(logoutLink) {
@Override public void onClick() {
sess.invalidate();
}
}
I.e. using the old request's session in onClick()'s request.
It's a bit leaky abstraction, as I got used not to think much about
requests, but in this case I had to realize.
So now it's
add( new Link(logoutLink) {
@Override public void onClick() {
getSession().invalidate();
}
}
Maybe it should be stressed in the wicket examples to call getSession()
to warn beginners.
Thanks for replies.
Ondra
On Thu, 2012-09-27 at 10:34 +0300, Martin Grigorov wrote:
Hi,
You need to use Session#invalidate() actually.
#invalidate() schedules a call to #invalidateNow() at the end of the
request cycle.
By using #invalidateNow() you invalidate the current http session and
right after this your app creates a new Session because it needs to
finish the request cycle and the new one is what you see later. You
can print the hashcodes to see whether I'm right.
On Thu, Sep 27, 2012 at 9:04 AM, Ondrej Zizka ozi...@redhat.com wrote:
Hi,
i am trying to implement a simple authentization.
I've basically copied what's in the auth example #2 in wicket examples,
and have a Logout button:
add( new Link(logoutLink) {
@Override public void onClick() {
sess.invalidateNow();
setResponsePage( HomePage.class );
}
}
.add( new Label(label, Logout +
sess.getUser().getName()) )
Which, when clicked, is performed, but in the second request, the User
object, which set to null in my overriden signOut(), is back in my
session object. Not sure if the same obj, but the same values.
What could be wrong?
Thanks,
Ondra
Re: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponentInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: stateless, not versioned pages - session problem
Hi, I see there is a big misunderstanding of what stateless/ful actually is. Having an http session or not is related only to the fact that stateful pages are stored there. Nothing more. You still can have an authenticated user (i.e. http session) and show stateless pages. All user info panels that you mentioned below doesn't require stateful page by itself. A page is stateful if it has at least one stateful component or behavior. A stateful component/behavior (C/B)is one that keeps a state with it and that state is needed by the C/B in the next request(s). Such C/B may have a callback url - an url which uniquely identifies this C/B and this C/B can be requested. In the simple and most used case imagine a Link with its onClick() method. So if you keep your pages stateless (by avoiding components and behaviors which makes it stateful. See StatelessChecker in wicket-devutils.jar) you can still show user's account info. A common use case is with Ajax C/Bs. An Ajax call updates just a part of the page. By default Wicket provides stateful Ajax C/Bs, i.e. they update parts of the same page instance. Jolira's Ajax C/Bs are stateless - i.e. an Ajax call creates a completely new page, then updates the part(s) it needs, then delivers the markup for the updated components in the Ajax response and discards the newly created page. I guess we need to create a Wiki page that better explains what is the difference between stateless and stateful. On Mon, Jan 9, 2012 at 1:39 PM, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy
Re: stateless, not versioned pages - session problem
this should go to separate conversation I created stateless (no stateful components) page if user is authorized i put his id to session so I can load it on each page creation (since it is stateless and not versioned it will be created on each request) pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ On 9 January 2012 12:39, Chris Colman chr...@stepaheadsoftware.com wrote: The stateless/stateful issue, on the surface at least, seems to be trivially easy because it's so black and white. Obviously in an ideal world most pages should be made stateless but in all but trivial sites this is near impossible. I'd like to suggest there is a fair amount of 'gray' - that things aren't so 'black and white' in the real world. For example - the content on most of the pages on our sites are essentially stateless - showing product details or FAQ pages or About Us pages until you realize that *every* web app that has authentication (which one doesn't these days?) shows the currently logged on user's username in an 'account details' component in the top/right of each page with an option to change profile settings and log out etc,. This has become much more than just a convention - it's virtually a defacto standard. Once we add that very common account details component to the top of each page the pages essentially become stateful so essentially a site with predominantly stateless pages now has to be stateful. The main issue that I am trying to avoid by removing page versions is SEO confusion whereby each time a search engine looks at a URL it sees a different page version parameter in the URL. It's a similar problem to the famous jsessionid parameter issue. Given that search engines never authenticate it prompts the question: is it possible for a given page to have multiple personalities? i.e. stateless if no authentication has taken place and stateful if authentication has taken place. User's don't really care if there is an extra page version parameter in the URL and this can be of great assistance in making the back button function correctly - especially if their interactions have changed content on the various pages (eg. showing contents of their shopping cart - hmmm, that's a problem - probably always want to show the 'current' shopping cart contents no matter how much they have gone 'back' otherwise things could get quite confusing) Search engines, on the other hand, don't really want to see the extra page version parameter. Setting up pages to have dual personalities would be a most excellent solution methinks. Is this possible/easy/a good idea in Wicket? Is it something that is such a common requirement that it could be added to the Wicket framework as a built in feature and save hours of work for both experienced and newbie Wicketeers? If it were a switchable option built into the framework wicket would only need to query the AuthenticatedWebSession.isSignedIn() to determine if each page should be stateless or stateful. Or perhaps an IAuthenticator interface needs to be supplied to allow it to work for developers who implement their own authenticated session object. Just thinking aloud ... again ;) Regards, Chrisco -Original Message- From: Martin Grigorov [mailto:mgrigo...@apache.org] Sent: Monday, 9 January 2012 8:37 PM To: users@wicket.apache.org Subject: Re: stateless, not versioned pages - session problem On Sun, Jan 8, 2012 at 4:29 PM, Chris Colman chr...@stepaheadsoftware.com wrote: On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? Make your page stateless to not have page ids in the URL (and the page wont be saved in the page stores too). Otherwise you'll need special version of org.apache.wicket.request.mapper.MountedMapper#mapHandler that doesn't org.apache.wicket.request.mapper.AbstractComponentMapper#encodePageComponen tInfo for IPageRequestHandler. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: stateless, not versioned pages - session problem
any ideas about #base_domain=mydomain.com problem ;] pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok I found the reason oAuth provider adds this #base_domain to callback url. I just dont understand why it stayed after redirection. the other issue (that after redirect urls looks like callback) is that I use ReplaceHandlerException and I rewrite data from original response to preserve cookies. so I will look at this pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
Hej, On Sun, Jan 8, 2012 at 12:24 AM, kamiseq kami...@gmail.com wrote: hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). To solve it do: Session.get().bind() when you add the attribute(s). I think Wicket should do that for you automatically. Please file a ticket and we will consider it. can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies can you try with Wicket 1.5-SNAPSHOT ? Recently we fixed something that automatically added the page parameters to the generated urls. thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
2012/1/8 Chris Colman chr...@stepaheadsoftware.com: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. which worked. The interesting thing was it was not necessary to call: getPageSettings().setVersionPagesByDefault(false); explicitly. -Original Message- From: kamiseq [mailto:kami...@gmail.com] Sent: Sunday, 8 January 2012 9:25 AM To: users@wicket.apache.org Subject: stateless, not versioned pages - session problem hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStr ategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - 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 -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: stateless, not versioned pages - session problem
ok currently im using 1.5.3 i ll check with snapshot pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
On Sun, Jan 8, 2012 at 11:31 AM, Chris Colman chr...@stepaheadsoftware.com wrote: Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); Actually this just turns off the redirecting. The pages are still versioned. So would getPageSettings().setVersionPagesByDefault(false); have been a better/safer option for turning off page versioning? Yes. I tried setVesionPagesByDefault(false) on its own but the version parameters still appeared in the URL in the browser address bar. Should we use both of the above to make page versioning disappear so as to make Wicket 1.5 behave just like version 1.5? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - 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: stateless, not versioned pages - session problem
ok so bind on session does the trick. now I looked at setAttribute method and I dont understand why the flow is altered when session is temporary. unfortunately I still get this #base_domain=mydoamin. so 1.5-SNAPSHOT behaves like 1.5.3 now I looked closely to url after last redirect to homepage (using ONE_PASS_RENDER strategy) and it is exactly the same as oauth callback plus this #base_domain=mydomain.com parameter :/ when I use default RenderStrategy.REDIRECT_TO_BUFFER then I just get #base_domain=mydomain parameter any ideas? pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
stateless, not versioned pages - session problem
hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: stateless, not versioned pages - session problem
Not sure if I have an answer to your question but recently I asked how to turn off page versioning and was told to do: getRequestCycleSettings(). setRenderStrategy(IRequestCycleSettings.RenderStrategy.ONE_PASS_RENDER); which worked. The interesting thing was it was not necessary to call: getPageSettings().setVersionPagesByDefault(false); explicitly. -Original Message- From: kamiseq [mailto:kami...@gmail.com] Sent: Sunday, 8 January 2012 9:25 AM To: users@wicket.apache.org Subject: stateless, not versioned pages - session problem hej I have weird problem with session that I cannot explain and that I don't fully understand. I started with default application settings and stateful web page. and the flow is that I 1. request homepage 2. put data to session 3. redirect to authorize with oauth provider (facebook, gmail, etc) which in turn redirects back to my page 4. get data saved before in session 5. redirect to homepage then I made page stateless and it works perfectly fine until I set getPageSettings().setVersionPagesByDefault(false); (I dont need back button functionality) then session was not created even though I put there something (well it is not quite right session is created but not persisted between requests - just after I put to session I can get the data from session, but on next request to wicket data is gone). can you explain why is that? one more thing after last redirect (step 5) wicket added ?#base_domain=mydomain.com to url. when I set getRequestCycleSettings().setRenderStrategy(IRequestCycleSettings.RenderStr ategy.ONE_PASS_RENDER); url is as oauth callback (from step 3) and I would expect it to be clean homepage url (ex mydomain.com/) for both render strategies thanks for help pozdrawiam Paweł Kamiński kami...@gmail.com pkaminski@gmail.com __ - 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
Major session problem [GAE]
Hi,
I have really serious problems with my sessions - or rather getting and
displaying data with it. It works great when tested locally, but when
deployed to GAE it acts weird. In bad way. I have no idea if it's wicket or
GAE issue, but maybe I can get some hints here.
Problem is that:
- it quite often fails to load data, so when user logs it it shows blank
pages, without any data, that should com from session
[MySession.loggedInUser.get...]
- on very rare occasions it can show old values, that were changed long time
ago, some residue must be left over somewhere and is not cleaned and somehow
it can switch between
- and there was a case when one user could see data from other user [so
sessions switched?]
Of course situations 23 can never happen. Situation 1 neither - but maybe
it can be solved by some check and reload of data?
Some code to illustrate:
MySession:
public class MySession extends WebSession {
public MySession(Request request) {
super(request);
}
public boolean isAuthenticated() {
return (loggedInUser != null);
}
public static User loggedInUser;
public User getLoggedInUser() {
return loggedInUser;
}
public void setLoggedInUser(User loggedInUser) {
this.loggedInUser = loggedInUser;
}
}
In Login:
((MySession) MySession.get()).setLoggedInUser(user);
Later data is accessed by MySession.loggedInUser.[getters/setters here] and
persisted to datastore when anything changes.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3584894.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: Major session problem [GAE]
On 2011.06.09. 10:48, Zeldor wrote: public static User loggedInUser; Is it correct? I think it is better without static! GeZo - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Major session problem [GAE]
Storing the User in a static field doesn't seem wise: the static field is
shared between all session instances, so this will break.
Besides that, I'd advise not to store the User instance itself in the session,
but only the user ID (or username, or email). The User instance can be cached
in a transient field, which can be checked and loaded on request by a
(non-static) getUser() method.
Something like this:
public class MySession extends WebSession {
private int userId = -1;
private transient User user;
public void setUser(User user) {
userId = user.getId();
this.user = user;
}
public User getUser() {
if (userId == -1) return null;
if (user == null) {
user = UserDAO.loadUser(userId);
}
return user;
}
@Override
public void detach() {
user = null;
super.detach();
}
}
On 9 jun 2011, at 10:48, Zeldor wrote:
Hi,
I have really serious problems with my sessions - or rather getting and
displaying data with it. It works great when tested locally, but when
deployed to GAE it acts weird. In bad way. I have no idea if it's wicket or
GAE issue, but maybe I can get some hints here.
Problem is that:
- it quite often fails to load data, so when user logs it it shows blank
pages, without any data, that should com from session
[MySession.loggedInUser.get...]
- on very rare occasions it can show old values, that were changed long time
ago, some residue must be left over somewhere and is not cleaned and somehow
it can switch between
- and there was a case when one user could see data from other user [so
sessions switched?]
Of course situations 23 can never happen. Situation 1 neither - but maybe
it can be solved by some check and reload of data?
Some code to illustrate:
MySession:
public class MySession extends WebSession {
public MySession(Request request) {
super(request);
}
public boolean isAuthenticated() {
return (loggedInUser != null);
}
public static User loggedInUser;
public User getLoggedInUser() {
return loggedInUser;
}
public void setLoggedInUser(User loggedInUser) {
this.loggedInUser = loggedInUser;
}
}
In Login:
((MySession) MySession.get()).setLoggedInUser(user);
Later data is accessed by MySession.loggedInUser.[getters/setters here] and
persisted to datastore when anything changes.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3584894.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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Major session problem [GAE]
Yeah, no idea why Static is there, must be some leftover from early code. It's good to have someone else take a look at your code and point the obvious :) I will check if it solves my problems. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3585007.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: Major session problem [GAE]
Using static non-final fields in a multi user environment is very very very very bad. The only cases you should use static are for example a logger (log4j etc) a global variable defining a number or string. If you do need to keep track of something using final then wrap this using the ThreadLocal class. final static Logger log; final static String applicationName = Zeldors application; final static String maxNumUsers = 2; Hielke -Original Message- From: Zeldor [mailto:pgronkiew...@gmail.com] Sent: donderdag 9 juni 2011 11:32 To: users@wicket.apache.org Subject: Re: Major session problem [GAE] Yeah, no idea why Static is there, must be some leftover from early code. It's good to have someone else take a look at your code and point the obvious :) I will check if it solves my problems. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3 584894p3585007.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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Major session problem [GAE]
norckon: Getting whole entity is good in my case. User can modify only his data and no one else can even access or see it. It speeds up things too. Anyway, how do you invoke the rest? Without static you of course get non-static method cannot be referenced from a static context compilation error. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3585460.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: Major session problem [GAE]
The Wicket websession has a static .get(), which will always return the
ThreadLocal session instance for the current user.
So you can use that and cast the result to your session, or add your own get()
to your session:
public static MySession get() {
return (MySession) WebSession.get();
}
WebPage also has his own getSession() you could use.
On 9 jun 2011, at 15:02, Zeldor wrote:
norckon:
Getting whole entity is good in my case. User can modify only his data and
no one else can even access or see it. It speeds up things too.
Anyway, how do you invoke the rest? Without static you of course get
non-static method cannot be referenced from a static context compilation
error.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3585460.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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Major session problem [GAE]
So... MySession.get().getUser().getLand() to properly get a value from session? Looks like it could have some performance issues, or does it just look so scary? :) -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Major-session-problem-GAE-tp3584894p3585657.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
session problem
Hi all, I have problem with a Wicket app deployed to a new host with shared tomcat : Not Found The requested URL /Pharmaco/;jsessionid=77264BF90D4FC51FD38AEF8259D8AD91 was not found on this server. Wicket seems to need a directory /work/Catalina/localhost/Pharmaco/WicketFilter-filestore in the Tomcat install directory for saving session information. I dont have any right at this path. Any idea to save this information in my own app ? Thanks in advance Pierre
