Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Emperorlou
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Inconsistent transport implementation

Created: 10/Jun/11 09:36 AM   Updated: 22/Jun/11 12:31 PM   Resolved: 22/Jun/11 12:31 PM
Component/s: runtime
Affects Version/s: 0.7.2
Fix Version/s: 0.8

Time Tracking:
Not Specified

Participants: Emperorlou and jfarcand

 Description  « Hide

It appears as though there is no consistent method for implementing the various transports in an application's handler. I expected websockets to create "fake" onRequest() calls generating "fake" GET requests for incoming messages but this is not the case. However it is done, we need to have a consistent model providing us the incoming messages from the browser for any transport: Comet, Websocket, Long-Polling or Polling.

There seems to be a second related issue (possibly closely related enough to put in the same task)...
It appears as though there is no way to communicate with a server from a browser effectively using Websockets. Overriding the provided atomsphere handlers will force all communication to reflect back to the browser. Overriding the onStateChange() will allow you to stop it but the connection fails as you must call super.onStateChange() to handle the websocket upgrade request, however this re-enables the reflection!

jfarcand added a comment - 22/Jun/11 11:52 AM

First drop of the WebSocketProcessor pluggable architecture

Right now it use the EchoWebSocketProcessor. And HttpServletRequestWebSocketProcessor will soon be added to allow the onRequest() method to be invoked like normal Comet.

jfarcand added a comment - 22/Jun/11 12:31 PM

Fixed in 0.8. See

for more information on how it works (need to configure the WebSocketProcessor in web.xml)