On Tue, Apr 2, 2013 at 7:41 PM, Mikko Tiihonen < mikko.tiiho...@nitorcreations.com> wrote:
> 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<https://github.com/jsyrjala/blogs/tree/websocket-broadcast-example/wicket6-websocket-broadcast/src/main/java/com/wicketinaction> Or the updated version at https://github.com/martin-g/blogs/tree/master/wicket6-websocket-broadcast > > > -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 >>> >> >> > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com <http://jweekend.com/>
