You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Daniel Stoch <da...@gmail.com> on 2015/12/23 14:21:53 UTC
Native WebSockets - cookies and last handler question
Hi,
I am during replacement Atmosphere push implementation to Wicket
Native WebSockets. I have an abstraction layer over it, so I can
replace only implementation and easily switch between these two
solutions and compare them. I have a couple of questions about Native
WebSockets:
1. In WebSocketResponse many methods throws
UnsupportedOperationException. I have a situation when component sets
cookie during its lifecycle, so this exeption is raised when it is
refreshed during push response. Is it any chance to implement these
methods or do they necessary throw exceptions? In Atmosphere
implementation this works.
2. I have a code which checks
PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
page for current request (is it a best method?). During processing
push request this method returns null. Is it a correct behavior? In
Atmosphere implementation this works too ;).
More questions to come later ;)
PS. I am using Wicket 6.x.
--
Best regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Native WebSockets - cookies and last handler question
Posted by Daniel Stoch <da...@gmail.com>.
On Wed, Dec 23, 2015 at 3:41 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch <da...@gmail.com>
> wrote:
>
>> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi,
>> >
>> >
>> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <da...@gmail.com>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I am during replacement Atmosphere push implementation to Wicket
>> >> Native WebSockets. I have an abstraction layer over it, so I can
>> >> replace only implementation and easily switch between these two
>> >> solutions and compare them. I have a couple of questions about Native
>> >> WebSockets:
>> >>
>> >> 1. In WebSocketResponse many methods throws
>> >> UnsupportedOperationException. I have a situation when component sets
>> >> cookie during its lifecycle, so this exeption is raised when it is
>> >> refreshed during push response. Is it any chance to implement these
>> >> methods or do they necessary throw exceptions? In Atmosphere
>> >> implementation this works.
>> >>
>> >
>> > Although an HTTP request is being *upgraded* to WebSocket, the websocket
>> > response is not an HTTP response.
>> > You can only write String and binary data that is processed by the
>> > application client code. The browser doesn't read/intercept the data
>> > transfered on the websocket connection so any headers (like cookies)
>> could
>> > not be processed.
>> >
>> > We could change the impl to log a warning whenever one of those methods
>> is
>> > used instead of throwing exception.
>> > Just like
>> >
>> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
>> > Please file a ticket if you think this is a better implementation.
>>
>> Logging a warning is not a good solution in my case, because when I
>> call addCookie() I don't know if current response implementation
>> supports it or not (to avoid logging warns). So there will be many
>> unnecessary WARN logs in my application. So a better solution for me
>> is simply do nothing (empty mehod). I think it is probably not a good
>> solution for you, but as I can see in WICKET-5737 there is a factory
>> method for the WebSocketResponse so I will be able to use my own
>> implementation of WebSocketResponse where addCookie() will not throws
>> exception.
>> Can this patch be backported to 6.x?
>>
>
> Sure. Please file a ticket.
WICKET-6054
>> >> 2. I have a code which checks
>> >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
>> >> page for current request (is it a best method?). During processing
>> >> push request this method returns null. Is it a correct behavior? In
>> >> Atmosphere implementation this works too ;).
>> >>
>> >
>> > I think this should work.
>> > There must be a bug somewhere.
>>
>> What should I check, how to investigate it?
>>
>
> Put a breakpoint at
> https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L237
> and see why the request cycle listeners are not notified.
This probably has been fixed in WICKET-5701 (in 6.18.0). I am using
6.17.0 and there is not scheduleRequestHandlerAfterCurrent() call.
So I have to upgrade and then check if it works ok.
Thanks for your help!
--
Best regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Native WebSockets - cookies and last handler question
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch <da...@gmail.com>
wrote:
> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi,
> >
> >
> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <da...@gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> I am during replacement Atmosphere push implementation to Wicket
> >> Native WebSockets. I have an abstraction layer over it, so I can
> >> replace only implementation and easily switch between these two
> >> solutions and compare them. I have a couple of questions about Native
> >> WebSockets:
> >>
> >> 1. In WebSocketResponse many methods throws
> >> UnsupportedOperationException. I have a situation when component sets
> >> cookie during its lifecycle, so this exeption is raised when it is
> >> refreshed during push response. Is it any chance to implement these
> >> methods or do they necessary throw exceptions? In Atmosphere
> >> implementation this works.
> >>
> >
> > Although an HTTP request is being *upgraded* to WebSocket, the websocket
> > response is not an HTTP response.
> > You can only write String and binary data that is processed by the
> > application client code. The browser doesn't read/intercept the data
> > transfered on the websocket connection so any headers (like cookies)
> could
> > not be processed.
> >
> > We could change the impl to log a warning whenever one of those methods
> is
> > used instead of throwing exception.
> > Just like
> >
> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
> > Please file a ticket if you think this is a better implementation.
>
> Logging a warning is not a good solution in my case, because when I
> call addCookie() I don't know if current response implementation
> supports it or not (to avoid logging warns). So there will be many
> unnecessary WARN logs in my application. So a better solution for me
> is simply do nothing (empty mehod). I think it is probably not a good
> solution for you, but as I can see in WICKET-5737 there is a factory
> method for the WebSocketResponse so I will be able to use my own
> implementation of WebSocketResponse where addCookie() will not throws
> exception.
> Can this patch be backported to 6.x?
>
Sure. Please file a ticket.
>
>
> >
> >>
> >> 2. I have a code which checks
> >> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
> >> page for current request (is it a best method?). During processing
> >> push request this method returns null. Is it a correct behavior? In
> >> Atmosphere implementation this works too ;).
> >>
> >
> > I think this should work.
> > There must be a bug somewhere.
>
> What should I check, how to investigate it?
>
Put a breakpoint at
https://github.com/apache/wicket/blob/master/wicket-native-websocket/wicket-native-websocket-core/src/main/java/org/apache/wicket/protocol/ws/api/AbstractWebSocketProcessor.java#L237
and see why the request cycle listeners are not notified.
>
>
> >
> >
> >>
> >> More questions to come later ;)
> >> PS. I am using Wicket 6.x.
> >>
> >> --
> >> Best regards,
> >> Daniel
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Native WebSockets - cookies and last handler question
Posted by Daniel Stoch <da...@gmail.com>.
On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
>
> On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <da...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I am during replacement Atmosphere push implementation to Wicket
>> Native WebSockets. I have an abstraction layer over it, so I can
>> replace only implementation and easily switch between these two
>> solutions and compare them. I have a couple of questions about Native
>> WebSockets:
>>
>> 1. In WebSocketResponse many methods throws
>> UnsupportedOperationException. I have a situation when component sets
>> cookie during its lifecycle, so this exeption is raised when it is
>> refreshed during push response. Is it any chance to implement these
>> methods or do they necessary throw exceptions? In Atmosphere
>> implementation this works.
>>
>
> Although an HTTP request is being *upgraded* to WebSocket, the websocket
> response is not an HTTP response.
> You can only write String and binary data that is processed by the
> application client code. The browser doesn't read/intercept the data
> transfered on the websocket connection so any headers (like cookies) could
> not be processed.
>
> We could change the impl to log a warning whenever one of those methods is
> used instead of throwing exception.
> Just like
> https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
> Please file a ticket if you think this is a better implementation.
Logging a warning is not a good solution in my case, because when I
call addCookie() I don't know if current response implementation
supports it or not (to avoid logging warns). So there will be many
unnecessary WARN logs in my application. So a better solution for me
is simply do nothing (empty mehod). I think it is probably not a good
solution for you, but as I can see in WICKET-5737 there is a factory
method for the WebSocketResponse so I will be able to use my own
implementation of WebSocketResponse where addCookie() will not throws
exception.
Can this patch be backported to 6.x?
>
>>
>> 2. I have a code which checks
>> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
>> page for current request (is it a best method?). During processing
>> push request this method returns null. Is it a correct behavior? In
>> Atmosphere implementation this works too ;).
>>
>
> I think this should work.
> There must be a bug somewhere.
What should I check, how to investigate it?
>
>
>>
>> More questions to come later ;)
>> PS. I am using Wicket 6.x.
>>
>> --
>> Best regards,
>> Daniel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Native WebSockets - cookies and last handler question
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <da...@gmail.com>
wrote:
> Hi,
>
> I am during replacement Atmosphere push implementation to Wicket
> Native WebSockets. I have an abstraction layer over it, so I can
> replace only implementation and easily switch between these two
> solutions and compare them. I have a couple of questions about Native
> WebSockets:
>
> 1. In WebSocketResponse many methods throws
> UnsupportedOperationException. I have a situation when component sets
> cookie during its lifecycle, so this exeption is raised when it is
> refreshed during push response. Is it any chance to implement these
> methods or do they necessary throw exceptions? In Atmosphere
> implementation this works.
>
Although an HTTP request is being *upgraded* to WebSocket, the websocket
response is not an HTTP response.
You can only write String and binary data that is processed by the
application client code. The browser doesn't read/intercept the data
transfered on the websocket connection so any headers (like cookies) could
not be processed.
We could change the impl to log a warning whenever one of those methods is
used instead of throwing exception.
Just like
https://github.com/apache/wicket/commit/8a5508e117991faf43f53d770b64568842d8d557
Please file a ticket if you think this is a better implementation.
>
> 2. I have a code which checks
> PageRequestHandlerTracker.getLastHandler(requestCycle) to get actual
> page for current request (is it a best method?). During processing
> push request this method returns null. Is it a correct behavior? In
> Atmosphere implementation this works too ;).
>
I think this should work.
There must be a bug somewhere.
>
> More questions to come later ;)
> PS. I am using Wicket 6.x.
>
> --
> Best regards,
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>