On Wed, Dec 23, 2015 at 3:41 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > On Wed, Dec 23, 2015 at 2:52 PM, Daniel Stoch <daniel.st...@gmail.com> > wrote: > >> On Wed, Dec 23, 2015 at 2:34 PM, Martin Grigorov <mgrigo...@apache.org> >> wrote: >> > Hi, >> > >> > >> > On Wed, Dec 23, 2015 at 2:21 PM, Daniel Stoch <daniel.st...@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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
