Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Date: Wed, 6 Jun 2012 20:46:54 +0100 (BST)
From: "smillidge@c2b2.co.uk" <smillidge@c2b2.co.uk>
Reply-To: "smillidge@c2b2.co.uk" <smillidge@c2b2.co.uk>
To: Tomcat Users List <users@tomcat.apache.org>,
 Mark Thomas <markt@apache.org>
Message-ID: 
 <320206308.264096.1339012014540.JavaMail.open-xchange@email.1and1.co.uk>
In-Reply-To: <4FCFA485.1090201@apache.org>
References: <017901cd4403$089d9c70$19d8d550$@c2b2.co.uk>
 <4FCFA485.1090201@apache.org>
Subject: Re: getting frustrated with web sockets
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_264095_995670617.1339012014492"
Importance: Medium

------=_Part_264095_995670617.1339012014492
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thinking off the top of my head. How about passing in an unmodifiable map o=
f the
session attributes to give some context to the creation of the MessageInbou=
nd
class?

Hmm however then some bright spark will probably want the URL and the reque=
st
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 <markt@apache.org> wrote:

> On 06/06/2012 17:40, Steve Millidge wrote:
> > Mark,
> >
> >=20
> >
> > I think it would be useful to get access to the session at least when y=
ou
> > are bootstrapping the web socket and creating the MessageInBound subcla=
ss
> > instance. It is very likely that a user will have accessed a web applic=
ation
> > and logged in etc. prior to bootstrapping the websocket connection.
> > Therefore there's likely to be a whole bunch of useful context informat=
ion I
> > want in my MessageInbound class when I create it.
> >
> > Looking at the code it would be a simple change to pass Session into th=
e
> > 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=C3=A7ade 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 h=
ack
> > 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
------=_Part_264095_995670617.1339012014492--