Hi Jonathan,
developing against a recent trunk I made a strange obeservation which
might be connected to this.
I have a page with several wicketAjaxGet calls. Some of em work fine.
The others behave strange, if clicked/called right after the page was
loaded they are answered with a Page
I commented out the DefaultServlet that comes with Tomcat and that seems to
have resolved the issue (at least I can no longer replicate it on my local
machine). I don't know why, but I'm guessing that since my app is mapped to
/ and tomcat's DefaultServlet is mapped to / it creates a session for
I haven't found a solution yet. I'm still debugging stuff and have no
solution. The problem definitely occurs when the initial redirect occurs
from /context to /context/YourHomePage.
On 5/17/07, Jonathan Locke [EMAIL PROTECTED] wrote:
Did we find a resolution for this yet? We are having
i discovered in my case that this was related to cookie overflow created
by some errant javascript on the page doing ajax callbacks. it had nothing
to do with wicket. you might try modifying a build of wicket to diagnose
your problem. i wound up putting some print statements in wicket where
Interesting. I'm only using Wicket for my AJAX, so are you saying that
something is wrong with the Wicket AJAX JavaScript?
On 5/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i discovered in my case that this was related to cookie overflow created
by some errant javascript on the page doing
sorry, no. that was not wicket's javascript.
Andrew Berman wrote:
Interesting. I'm only using Wicket for my AJAX, so are you saying that
something is wrong with the Wicket AJAX JavaScript?
On 5/19/07, Jonathan Locke [EMAIL PROTECTED] wrote:
i discovered in my case that this was
Did we find a resolution for this yet? We are having the same problem in
Wicket 1.3 trunk and I'm about to start investigating. Any definite
information or conclusions (whether complete or not) would be very much
appreciated.
Andrew Berman wrote:
I am having a strange issue. If I access
HomePage is the actual page itself. The mount is just what I mounted in the
Application class using: mount(/app, PackageName.forClass(getHomePage()));
On 5/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
if your homepage is mounted to /app then the url should be /context/app.
so where does
So I've been debugging this pretty extensively now. I put a breakpoint in
WicketServlet.
1. On the first request (http://blah.com/context), the session id in the
URL and in the session all match and when I look at the cookie the
jsessionid also matches.
2. On the last request, the session id
can you look at the first request if the wicket session is really
pushed to the http session (so is the http session created?) you can
look at that in the set atribute of the session store
On 5/15/07, Andrew Berman [EMAIL PROTECTED] wrote:
I think I found the crux of the problem. When you first
Also, sessions are managed by the app server, not by Wicket or Spring
MVC. I had a problem a while ago losing sessions going from
foo.mydomain.com to bar.mydomain.com, and that only worked well when I
configured Jetty's session manager to use .mydomain.com as it's
session domain. Maybe your
I'm going to debug it a bit more to see what's going on. The jsessionid is
not appended to the URL until Wicket performs a redirect from the context to
the actual home page (e.g. from http://blah.com/context redirects to
http://blah.com/context/app/HomePage), so I'm wondering if the redirect is
i dont think that is it. jsessionid is only appended when there is a
session.
when you hit blah.com/context you are probably hitting index.html that does
a metaredirect to blah.com/context/app/homepage. so on the first hit to
blah.com/context there is no session. now when you hit /app/home a
I'm not doing any redirect using index.html and a meta redirect. I just
call blah.com/context and Wicket is doing the redirect to /app/homepage.
/app is what I use for the mount point.
On 5/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
i dont think that is it. jsessionid is only appended when
so wicket is mapped to /* but homepage is mounted to /app/homepage?
-igor
On 5/15/07, Andrew Berman [EMAIL PROTECTED] wrote:
I'm not doing any redirect using index.html and a meta redirect. I just
call blah.com/context and Wicket is doing the redirect to /app/homepage.
/app is what I use
It's mapped to /context/* and the HomePage class is mounted to /app, so the
url for the homepage is http://blah.com/context/app/HomePage. Going
directly to http://blah.com/context redirects to
http://blah.com/context/app/HomePage
On 5/15/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
so wicket is
if your homepage is mounted to /app then the url should be /context/app. so
where does HomePage come from?
-igor
On 5/15/07, Andrew Berman [EMAIL PROTECTED] wrote:
It's mapped to /context/* and the HomePage class is mounted to /app, so
the url for the homepage is
I'm willing to try anything to try to workaround or fix this problem. Does
anyone have any suggestions where I should start looking or playing around
in the Wicket code to figure out possibly what is going on?
On 5/13/07, Jonathan Locke [EMAIL PROTECTED] wrote:
we're getting some issue like
place a breakpoint in: WebRequestCycleProcessor
and then line 78: boolean processRequest = true;
then look what happens the code should go into: target =
resolveRenderedPage(requestCycle, requestParameters); (line 137)
Then Session.getPage() is called and that should also return the page..
There is no WebRequestCycleProcessor class in Wicket 1.2.6.
On 5/14/07, Johan Compagner [EMAIL PROTECTED] wrote:
place a breakpoint in: WebRequestCycleProcessor
and then line 78: boolean processRequest = true;
then look what happens the code should go into: target =
Ok, if I paste the jsessionid into the URL for the second request, all works
well. ON the third request, it works fine without pasting the jsessionid.
How can I append the jsessionid to all requests?
On 5/14/07, Andrew Berman [EMAIL PROTECTED] wrote:
I've debugged in
On 5/14/07, Andrew Berman [EMAIL PROTECTED] wrote:
Ok, if I paste the jsessionid into the URL for the second request, all works
well. ON the third request, it works fine without pasting the jsessionid.
How can I append the jsessionid to all requests?
Turn cookie support off at your servlet
Definitely not what I want, but it's the only thing that works. There's
clearly a problem in how Wicket is getting the session from the cookie. My
Spring MVC app which uses the same WAR has no issues pulling the session
info.
On 5/14/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
On 5/14/07,
actually wicket does not get session from a cookie, tomcat/servlet container
does.
-igor
On 5/14/07, Andrew Berman [EMAIL PROTECTED] wrote:
Definitely not what I want, but it's the only thing that works. There's
clearly a problem in how Wicket is getting the session from the cookie. My
Spring MVC does put the jsessionid in the URL. What I don't understand is
that when coming into the Wicket app for the first time, it goes to the home
page fine with the jsessionid in the URL, and then I click any link and all
session attributes are gone. Literally a brand new session is
I think I found the crux of the problem. When you first go to the app, as
I've mentioned, it puts the jsessionid in the URL. Well, I compared that
sessionid to the one in the cookie created and they are different! That has
to be the reason it creates a new session. Now to figure out why it's
can you debug it some how?
Can you figure out why the page is not found?
Do you get the second time the same httpsession (that should be created on
the first request)
johan
On 5/13/07, Andrew Berman [EMAIL PROTECTED] wrote:
There's two things here:
1. When I click the Ajax link and it
I've been trying to debug, but am not sure what to really look for. No, I
do not get the same session. One is definitely created on the first request
and then I see another one created on the second request.
On 5/13/07, Johan Compagner [EMAIL PROTECTED] wrote:
can you debug it some how?
Can
maybe because ajax links do not have the jsessionid in them? but then again,
the cookie should kick in by second request, so jsessionid in the ajax links
is not really necessary. still, passing those urls through request.rewrite()
might be something we want to think about.
-igor
On 5/13/07,
we're getting some issue like this too and on only one server.
Eelco Hillenius wrote:
Are you working on multiple servers?
On 5/12/07, Andrew Berman [EMAIL PROTECTED] wrote:
Igor, Eelco, anyone? This issue is pretty major as I'm losing all the
session info when they first come into
Are you working on multiple servers?
On 5/12/07, Andrew Berman [EMAIL PROTECTED] wrote:
Igor, Eelco, anyone? This issue is pretty major as I'm losing all the
session info when they first come into the app
On 5/11/07, Andrew Berman [EMAIL PROTECTED] wrote:
Could there be an issue with
what is your url you are comming into your app?
do you redirect then? What is the final url?
johan
On 5/12/07, Andrew Berman [EMAIL PROTECTED] wrote:
Igor, Eelco, anyone? This issue is pretty major as I'm losing all the
session info when they first come into the app
On 5/11/07, Andrew
Hey Guys,
Thanks for your replies.
James: I'll try what you are talking about and see if that fixes the
problem. I hope it does
Eelco: No multiple servers. I am able to replicate the issue on my local
machine as well.
Johan: The url coming in is http://localhost/consumer which Wicket
There's two things here:
1. When I click the Ajax link and it doesn't work and the page redirects to
the home page, the links are exactly the same
2. When I do a refresh on the browser, the Ajax links are different and
there is no jsessionid in the url in the browser.
Is this the same problem
I have an issue with links and page expiration about which I posted a
jira entry here:
https://issues.apache.org/jira/browse/WICKET-557
I haven't the least idea about whether this is related or not to your problem.
Cheers,
Carlos
On 5/12/07, Andrew Berman [EMAIL PROTECTED] wrote:
There's two
Could there be an issue with the PageMap?
On 5/11/07, Andrew Berman [EMAIL PROTECTED] wrote:
I am having a strange issue. If I access my site for the first time (I
clear all cookies, sessions, and cache before going to the site), the page
comes up fine. However, if I click one of the AJAX
Igor, Eelco, anyone? This issue is pretty major as I'm losing all the
session info when they first come into the app
On 5/11/07, Andrew Berman [EMAIL PROTECTED] wrote:
Could there be an issue with the PageMap?
On 5/11/07, Andrew Berman [EMAIL PROTECTED] wrote:
I am having a strange
the ajax stuff is still a work in progress, and the expiration issue is
something that remains to be solved. the problem is that each request
creates a new version of the page and so if you use any non-ajax link
it will calse the page expired page since the link points to an older
version of the
oh, and yes, the only way to never have timeouts is to use
bookmarkable page links as bookmarkable pages do not use a prior
session (in fact, if you don't have a session yet and you navigate to
a bookmarkable page, a new session is created).
Eelco
On 11/1/05, Eelco Hillenius [EMAIL PROTECTED]
39 matches
Mail list logo
