You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Andrea Del Bene <an...@gmail.com> on 2013/04/02 17:16:25 UTC
Re: Question on native Websocket support
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?
>> 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
Re: Question on native Websocket support
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Apr 2, 2013 at 7:41 PM, Mikko Tiihonen <
mikko.tiihonen@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/>
Re: Question on native Websocket support
Posted by Mikko Tiihonen <mi...@nitorcreations.com>.
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
>