Marco Springer created WICKET-5051:
--------------------------------------
Summary: Incorrect URL rendered when using Comet
Key: WICKET-5051
URL: https://issues.apache.org/jira/browse/WICKET-5051
Project: Wicket
Issue Type: Bug
Components: wicket-atmosphere
Affects Versions: 6.6.0, 6.5.0
Environment: Ubuntu 12.04 using Oracle JAVA 1.7.0_13
Reporter: Marco Springer
Assignee: Emond Papegaaij
Priority: Minor
Initially I had a problem using Apache as a proxy in-front of a running Jetty
instance with WebSockets enable, with CometD as fallback.
I used the Apache config as described on
https://github.com/Atmosphere/atmosphere/wiki/How-to-run-Atmosphere-behind-Apache-WebServer.
With the above scenario running I only had problems with re-rendered markup
with link(s) in them. Links that are rendered through the usual client-server
requests are fine, even if they through normal Ajax calls.
As soon as a piece of markup was re-rendered through a push event the link was
bad, trying to open a website one path above the usual link, for example:
The application context path is '/appl/test', the link that comes from the
UrlRenderer was pointing to "/test" instead.
I thought it was a fault in my proxy config because directly accessing the
Jetty server on port 8080 is working fine!
What I seem to have missed was that somehow through the Apache proxy the
Atmosphere Framework was switching back to CometD.
How did I found out?
When I forcefully disabled WebSockets, forcing the CometD way to kick in, I had
the same URL problems again. Even though I'm accessing the Jetty instance
directly again on port 8080. Actually, using CometD the web application is
behaving very incorrect.
Sometimes the function(s) annotated with @Subscribe get called multiple times
without reason, again without the proxy.
If I turn on WebSockets again, all is fine.
The reason why I'm Apache using is because a whole lot of legacy applications
in our company are configured through Apache. I got some really bug-eyed views
when I proposed to migrate to Nginx at this stage. So using lighthttpd or Nginx
is out of the question unfortunately.
To nail things down a bit more, I have debugged back to the UrlRenderer class
in the "renderRelativeUrl" function, some mangling with the URL goes on in
here, prepending the "../" in the URL when the baseUrlSegments consists out of
more than 1 segment.
I don't know the internal reasons for this to be done but I can only see that
in my "push" event, this starts screwing things up a bit when using CometD.
I've attached a quickstart that contains 2 urls.
When "push" is clicked, the other browser instance should display (unhide) the
"aaaaaaaa" link.
In case of WebSockets, this works fine.
In case of CometD... well, meh. Sometimes the link unhides, sometimes it
doesn't. When the link unhides, it can't be clicked properly since it directs
to an incorrect context path.
I've also attached my very basic Apache proxy config, which is, well, the same
as the 1st link describes.
Thanks in advance.
Kind regards,
Marco
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
