On 04/02/2013 06:16 PM, Andrea Del Bene wrote:
After some time spent on the code of websocket integration I came to the same
conclusions you expressed in point 1 and 2. However it's not completely clear to
me how a message can be broadcast by a session and received by another one. Can
you provide and example?
The main api to use is WebSocketPushBroadcaster. It has two methods:
broadcast - send message to a specific websocket session
broadcastAll - send message to all websocket sessions in wicket application
In both cases the components that want to update their state in the browser can
override onEvent and handle the message inside WebSocketPushPayload.
The onEvent handler receives a WebSocketRequestHandler which implements AjaxRequestTarget. This allows the component to do the necessary model updates and add
itself or any other component to the updated target in a familiar style used by wicket ajax events.
You can look at an example my coworker created to showcase the feature before
it was accepted to wicket:
https://github.com/jsyrjala/blogs/tree/websocket-broadcast-example/wicket6-websocket-broadcast/src/main/java/com/wicketinaction
-Mikko
Hi,
I'm looking at the implementation of the native websocket support. I see that
mehod broadcastMessage of class AbstractWebSocketProcessor exports the thread
local variables before broadcasting the message. Why we need to do this? Why
can't we use the current variables (session, request cycle, etc...)?
Three reasons:
1) In many cases they have to be set since the broadcast can be called from
non-wicket and non-servlet code.
2) in many cases broadcasting is only deadlock safe through a queue and thread
pool, in which case the threads will again not have any wicket threadlocals set
3) when you broadcast a message (for example from ajax request) it is often
delivered to another session. when invoking component callbacks in another
session
it would be confusing (or even a security problem) for the called code to see
the actual initiator session stuff
But I'm interested in hearing if you have a use case where having the original
session, etc available for the event handlers would be useful?
-Mikko
