Hi, On Fri, Mar 7, 2014 at 2:50 AM, Henrik Østerlund Gram <henrik.g...@gmail.com > 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! > > 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 <mgrigo...@apache.org > >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 < > > henrik.g...@gmail.com> 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 > > > > > >
