tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: getting frustrated with web sockets
Date Wed, 06 Jun 2012 20:31:38 GMT
Hash: SHA1


On 6/6/12 2:42 PM, Mark Thomas wrote:
> 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.

This was going to be my suggestion. There are a number of frameworks
out there that avoid tightly binding application with the servlet API
by exposing things as a java.util.Map instead of, say,
javax.servlet.http.HttpSession or javax.servlet.http.HttpServletRequest.

This strategy gives access to the underlying data (that is, the
attributes), hides the real source of the data, and allows
interception of arbitrary calls. So, we could either throw an NPE when
the session/request goes "out of scope" with respect to the WebSocket
message, or we could even throw a more useful exception that informs
the client that the data is no longer accessible.

- -chris
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Mozilla -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message