On Fri, Mar 7, 2014 at 8:12 AM, Martin Grigorov <[email protected]>wrote:
> Hi, > > On Fri, Mar 7, 2014 at 2:50 AM, Henrik Østerlund Gram < > [email protected]> wrote: > >> I just tried it out by building 7.x, copying over just the >> wicket-native-websocket-javax >> artifact, modded the pom to depend on the 6.14 parent, and it pretty much >> worked as expected (using jdk7 + wildfly 8) >> > > Good! > > >> >> WebSocketBehavior seems to be missing code to handle WebSocketPushPayload, >> both in 6.x and 7.x, so I had to override onEvent() instead of a more >> regular onPush method or something. >> > > OK. I will improve this! > Done! https://issues.apache.org/jira/browse/WICKET-5529 > > >> >> Finally, I was wondering if it's not possible to support sessionscope >> somehow. I know the docs said it doesn't work, but it seems logical to me >> that a message to a page, whether it comes from the client itself or >> pushed >> from a server-side event, should run in the client's session scope. >> Certainly, it should not matter to the server whether a req from a client >> comes in one way of the other. Has anyone looked into it and deemed it >> impossible or just not worth the bother? >> > > This is something that I also don't quite understand what are the > technical problems for the web container to support it. > The APIs provided by JSR356 and the old custom impls of WebSocket APIs in > Tomcat and Jetty don't have a method that will return the current (or to > create a new) HttpSession. > > If you talk about Spring session beans then the explanation is that the > servlet filters (like WicketFilter) and servlets (like Spring's > DispatcherServlet) are not used/executed at all when there is a websocket > message sent to the server. So Spring has no chance to do its work - > prepare the proxies that will resolve request or session scoped beans and > put them as attributes in the HttpServletRequest and HttpSession. Mainly > because there are no HttpServletRequest and HttpSession in websocket > connection. > > Here is what Wicket Native WebSocket does to simulate all this: > During the upgrade of the initial http connection to a websocket > connection Wicket makes a copy of the current HttpServletRequest > (org.apache.wicket.protocol.ws.api.ServletRequestCopy ) and a copy of the > HttpSession (org.apache.wicket.protocol.ws.api.HttpSessionCopy). Those > copies are used later when a > org.apache.wicket.protocol.ws.api.WebSocketRequest is craeted. This is the > request returned by RequestCycle#getRequest(). > If the user application code needs to use: > RequestCycle#getRequest().getContainerRequest() it will receive a > HttpServletRequest as if it needs to do this in a Page or a IResource. If > the application needs to use > RequestCycle#getRequest().getContainerRequest().getHttpSession() then it > will receive the HttpSessionCopy. Again no surprises. > The Wicket Session is stored in both the real HttpSession (the one that is > managed by the web container) and in the HttpSessionCopy (the one that is > associated with the current IWebSocketConnection) so it is the same > reference and changes to it are visible for both the http and websocket > requests. > *But *if you add/edit/remove any custom attribute in the HttpSessionCopy > then it won't propagate to the real HttpSession (the one returned by the > web container in a http request). > > I guess Spring will have to do something similar to be able to support > request and session scoped beans in websocket connections. > > See https://issues.apache.org/jira/browse/WICKET-5487 and > https://jira.springsource.org/browse/SPR-11305 > > >> >> Regards, >> Henrik >> >> >> >> On Thu, Mar 6, 2014 at 10:59 AM, Martin Grigorov <[email protected] >> >wrote: >> >> > Hi, >> > >> > The main reason to not backport it to wicket-6.x is that JSR356 >> > (websocket-api.jar) is built with Java 7. >> > And Wicket 6.x is being build with Java 6 ... >> > >> > One option is to wait for Wicket 7.0.0.M1 (we talk about it for a month >> > now, so I hope it will be released soon!). >> > Another option is to port wicket-native-websocket-javax to wicket-6.x >> and >> > explain somewhere that you have to run on Java 7 to be able to use it. >> > Please file a ticket and if no one else objects against this then we >> will >> > do it for 6.15.0. >> > >> > And yes, we will have to find a better way to explain in the guide which >> > feature is new and available only in 7.x ... >> > >> > Martin Grigorov >> > Wicket Training and Consulting >> > >> > >> > On Thu, Mar 6, 2014 at 11:20 AM, Henrik Østerlund Gram < >> > [email protected]> wrote: >> > >> > > I'm been anxious to use websockets with Wicket (I'm tied to the JBoss >> > > appserver and do not wish to use Atmosphere) and as I just upgraded to >> > > WildFly 8, I thought finally it would be possible. >> > > >> > > The instructions on >> > > http://wicket.apache.org/guide/guide/nativewebsockets.html (which >> states >> > > the guide applies to version 6.x) instructs you to just include the >> > > wicket-native-websocket-javax dependency, but that doesn't work as >> that >> > > artifact does not seem to exist for the latest 6.x branch and I was >> also >> > > unable to find it in the git repo. >> > > >> > > Now I do see it in the master branch for 7.x, and I'm wondering if >> anyone >> > > tried using the same classes for 6.14? Is there some reason it's not >> been >> > > backported, or is it just hiding somewhere? >> > > >> > > Regards, >> > > Henrik >> > > >> > >> > >
