Re: Assigning a new Session does not change Session.ID
Use the source, Luke! That's the great thing about open source. You can read it to see what's going on and perhaps learn something along the way. You'd be surprised what kind of tricks you can pick up by reading other people's code. So, I'd say start working your way through it to try to see what it does. If you still can't figure it out, by all means, ping the list again. I'm sorry, I forgot to mention in my first post that I already dug quite deep into the code and had a look at quite a bit of code from the Session, RequestCycle and what not classes. I definitely agree with you, that one can learn lots of things from other people's code. So I did from diggin in the Wicket code. I'd say, I understood quite a few pieces of that code, but however it did not help me to grasp the bigger picture in terms of how it all plays together. I also got to confess, that I don't have much experience yet with web programming, so I stopped digging into the code about when I left Wicket and got down to e.g. HttpRequests. So if anybody could give me that bigger picture, nudge me in the right direction, or tell me what crucial point I have been missing, I'd still be very thankful. Cheers, Andreas Maly - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Assigning a new Session does not change Session.ID
On Sat, Dec 18, 2010 at 4:02 PM, RainbirdTheElder wrote: > > I would be very grateful if you could try to explain this behavior to me in > order to give me a better understanding of what Wicket is doing here and > why, with my approach, I don't seem to be able to generate the result > expected by me. > Use the source, Luke! That's the great thing about open source. You can read it to see what's going on and perhaps learn something along the way. You'd be surprised what kind of tricks you can pick up by reading other people's code. So, I'd say start working your way through it to try to see what it does. If you still can't figure it out, by all means, ping the list again. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Assigning a new Session does not change Session.ID
Hello Wicket community,
I'm relatively new to Wicket and I have a problem that I have not been
able to solve so far by means of Google and crawling through the user
mailing list archive.
What I want to do is change or replace the current Session of somebody
using my Wicket web application.
After having found this discussion
(https://issues.apache.org/jira/browse/WICKET-1767), the task at hand
was pretty simple.
Here's how I do it:
...
private void assignNewSession() {
log.debug("Assigning new session to user.");
RequestCycle.get().getSession().replaceSession();
}
...
This also works perfectly if I try it out in a browser. I can see, that
the session ID changes, as soon as this code has been executed.
What I have not been able to do so far, however, is finding a way to
Unit-test, if the session has really been changed.
If I, for instance, include the following lines in the method above:
...
private void assignNewSession() {
log.debug("Assigning new session to user.");
Session oldSession = RequestCycle.get().getSession();
String oldSessionID = oldSession.getId();
// same way of replacing session as above
RequestCycle.get().getSession().replaceSession();
Session newSession = RequestCycle.get().getSession();
String newSessionID = newSession.getId();
System.out.println(oldSession == newSession);
System.out.println(oldSessionID == newSessionID);
}
...
then I will find that the ID of the Session I'm getting from the
RequestCycle has not changed at all. The oldSession and newSession
objects are even the same object.
So, my question is:
Why does the code replacing the Session work when executed within the
browser? But why can't I seem to reproduce the replacement of the
session or a change in the session id with that piece of code?
Does the session stay the same within one request cycle, and will it
only change when the next request is issued (a difference I can see
between the code above and running the same thing in a browser)?
I would be very grateful if you could try to explain this behavior to me
in order to give me a better understanding of what Wicket is doing here
and why, with my approach, I don't seem to be able to generate the
result expected by me.
Also, if you could probably point out any way that I could actually use
to unit-test the replacement of a session, that would be very helpful.
Thanks in advance,
Andreas Maly
Assigning a new Session does not change Session.ID
Hello Wicket community,
I'm relatively new to Wicket and I have a problem that I have not been
able to solve so far by means of Google and crawling through the user
mailing list archive.
What I want to do is change or replace the current Session of somebody
using my Wicket web application.
After having found this discussion
(https://issues.apache.org/jira/browse/WICKET-1767), the task at hand
was pretty simple.
Here's how I do it:
...
private void assignNewSession() {
log.debug("Assigning new session to user.");
RequestCycle.get().getSession().replaceSession();
}
...
This also works perfectly if I try it out in a browser. I can see, that
the session ID changes, as soon as this code has been executed.
What I have not been able to do so far, however, is finding a way to
Unit-test, if the session has really been changed.
If I, for instance, include the following lines in the method above:
...
private void assignNewSession() {
log.debug("Assigning new session to user.");
Session oldSession = RequestCycle.get().getSession();
String oldSessionID = oldSession.getId();
// same way of replacing session as above
RequestCycle.get().getSession().replaceSession();
Session newSession = RequestCycle.get().getSession();
String newSessionID = newSession.getId();
System.out.println(oldSession == newSession);
System.out.println(oldSessionID == newSessionID);
}
...
then I will find that the ID of the Session I'm getting from the
RequestCycle has not changed at all. The oldSession and newSession
objects are even the same object.
So, my question is:
Why does the code replacing the Session work when executed within the
browser? But why can't I seem to reproduce the replacement of the
session or a change in the session id with that piece of code?
Does the session stay the same within one request cycle, and will it
only change when the next request is issued (a difference I can see
between the code above and running the same thing in a browser)?
I would be very grateful if you could try to explain this behavior to me
in order to give me a better understanding of what Wicket is doing here
and why, with my approach, I don't seem to be able to generate the
result expected by me.
Also, if you could probably point out any way that I could actually use
to unit-test the replacement of a session, that would be very helpful.
Thanks in advance,
Andreas Maly
