tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enrico Olivelli <eolive...@gmail.com>
Subject Re: Accessing ServletContext from WebSocket endpoint
Date Sat, 07 Dec 2013 18:41:10 GMT
I'm trying the example from Tyrus, hoping that it could work on tomcat
https://tyrus.java.net/documentation/1.3/index/deployment.html

this is the simplest code to put ServletContext in userproperties

@WebListener
public class MyWebSocket implements ServletContextListener {

     @Override
     public void contextInitialized(ServletContextEvent 
servletContextEvent) {
         final ServerContainer serverContainer = (ServerContainer) 
servletContextEvent.getServletContext()
.getAttribute("javax.websocket.server.ServerContainer");

         try {
             ServerEndpointConfig c = 
ServerEndpointConfig.Builder.create(MyWebSocket.class, "/endpoint").build();
             c.getUserProperties().put("servletContext", 
servletContextEvent.getServletContext());
             serverContainer.addEndpoint(c);
         } catch (DeploymentException e) {
             e.printStackTrace();
         }
     }

     @OnOpen
     public void onOpen(Session session, EndpointConfig config) {
         try {
             session.getBasicRemote().sendText("hello" + 
config.getUserProperties());
         } catch (IOException e) {
             e.printStackTrace();
         }
     }

     @Override
     public void contextDestroyed(ServletContextEvent servletContextEvent) {
     }
}


unfortunately I got this exception onOpen
java.lang.NullPointerException
     at 
org.apache.tomcat.websocket.pojo.PojoEndpointBase.doOnOpen(PojoEndpointBase.java:56)
     at 
org.apache.tomcat.websocket.pojo.PojoEndpointServer.onOpen(PojoEndpointServer.java:70)
     at 
org.apache.tomcat.websocket.server.WsHttpUpgradeHandler.init(WsHttpUpgradeHandler.java:129)
     at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:629)
     at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
     at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
     at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
     at java.lang.Thread.run(Thread.java:724)

Thanks
Enrico


Il 07/12/2013 15:33, Christopher Schultz ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Johan,
>
> On 12/7/13, 4:30 AM, Johan Compagner wrote:
>> On 7 December 2013 04:48, Christopher Schultz
>> <chris@christopherschultz.net>wrote:
>>
>>>> because i only see currently api to get the HttpSession and
>>>> then through that the ServletContext, problem is that there is
>>>> no http session..
>>> Aah... if there is no session, getHttpSession doesn't
>>> automatically create one(). Boo.
>>
>>
>> and can it create one?
>>
>> if a browser does a ws: request that will be first just a http
>> request i guess that is then "upgraded" But in that first request
>> can cookies be send over? Because if a websocket creates a http
>> session then a jsessionid cookie must be set in the browser over
>> the websocket request. And that jsession cookie must then be used
>> by also normal http request a browser does to that server..
> I'm no WebSocket expert, but the server has to first handle the
> request as HTTP, and then upgrade it to WebSocket. The client can
> establish a session first, then switch over to WebSocket and inherit
> the session. I'm not sure if a "pure" WebSocket request can create a
> session, since WebSocket is /not/ HTTP and therefore cookies are a bit
> meaningless.
>
>> problem is that i don't want to create a session, i just want to
>> ServletContext to read some files.
> Yup, I get it.
>
>> So something like:
>>
>> EndpointConfig.getUserProperties().put("ServletContext",request.get
>>
>>
> Context());
>> That context can then just return an object which i need to cast
>> and is then up to the container to provide.
> I would lobby to have the container put the ServletContext into the
> user properties -- just as you have above -- automatically during
> connection set-up. There's nothing stopping Tomcat from doing that
> right now, except that it would technically violate the spec and
> introduce a non-standard vendor extension.
>
> In this case, it's pretty clear that there is a quite desirable
> feature missing from the spec and I think it might be reasonable to
> violate it in this instance. I'd prefer to get Mark or Konstantin to
> weigh-in on such a step, because it might set a bad precedent for Tomcat.
>
> I'm certainly not going to commit that myself. :)
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSozG4AAoJEBzwKT+lPKRYwHUP/1/rTzHMuYnG0PydbKAffDOo
> 5D+/YABdkxvmAs49MhVJyAFs9QLZn3NNmuNLoLnxirkAx2lG1RHxOrnS2VdHWrgE
> g5WH5gEoMFyl52rl6QOiaXBFNDfBG7X3kqn8TzUWRMkoxZbwoN5GGG6Uhk3jWv9x
> rWw/Bos7DqmssfrT+Y8Uk9+TbegkP0s9r56FY9PUvVPFSqjALX9sFd7WpzEPS8up
> NwbAMJpiFydgIwXTmMy69kmTgcvYacfrcbyZuhQmV2PllfKDbNt4THxgop6TXlYp
> KrDu3YzINf0DSFUgXNkjz5WGXnstLxjgn943YX54Xy5WBe9zxndOPedMBW/gHGM+
> 3LdlnPaOM8OGWSu0PZxXXuLIu+oWUcB8oUKaeIMa8Yv1Zb9WIPXe6m3AlAebkfDB
> 9yDFjcmWS5Fpc/qaXYqrxGMoVZc22GyhijdVn1jd7tK9TJAtGpoMQrQArfcQdJb3
> qcifW5iHraTeE8iDSFIj94puv4XoE5u2GwRIx+qRs9mtHdu36GUj9GfVy6tEhsFA
> eyhpw8cpM9DrePMus9O0OecYiTQv4eXDPhzYhj+zsjipmIhza7dzedIg12l+gnaY
> TONnC3tXsOOl5cioJPaRgwl4jVKBrlg1xMIA937ncPiqKFoX//8nJq9LaCds7Vrq
> 33lj6jBuGweANjNxGsRC
> =qMXW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message