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.