Thinking off the top of my head. How about passing in an unmodifiable map of the session attributes to give some context to the creation of the MessageInbound class?
Hmm however then some bright spark will probably want the URL and the request parameters, then the cookies etc. of the initiating HTTP request. I assume the JSR 356 expert group is grappling with this question as well. Steve On 06 June 2012 at 19:42 Mark Thomas <ma...@apache.org> wrote: > On 06/06/2012 17:40, Steve Millidge wrote: > > Mark, > > > > > > > > I think it would be useful to get access to the session at least when you > > are bootstrapping the web socket and creating the MessageInBound subclass > > instance. It is very likely that a user will have accessed a web application > > and logged in etc. prior to bootstrapping the websocket connection. > > Therefore there's likely to be a whole bunch of useful context information I > > want in my MessageInbound class when I create it. > > > > Looking at the code it would be a simple change to pass Session into the > > createWebSocketInbound(String subProtocol) call. > > I'd rather not pass in the session object since it just encourages folks > to retain a copy of it and I am not at all convinced that is a good idea > for WebSockets. > > I have no objection to making session attributes available at that point > (or data from the request) but I don't like the idea of providing direct > access to the Request and Session objects. Neither do I like the idea of > having to proxy every getter... > > Hmm. We could wrap them with a façade and null out the underlying > objects once the HTTP request ends to "discourage" folks from retaining > references to them since all they'll get is NPEs. > > > Any chance we can get it added as a parameter, otherwise I'll have to hack > > about with thread locals in the subclass of WebSocketServlet. > > If the above seems reasonable then that is probably doable with the > caveat I haven't thought too hard about it at this point. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
