Re: Accessing ServletContext from WebSocket endpoint
On 07/12/2013 14:33, Christopher Schultz wrote: > 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. The spec doesn't say the container can't put its own objects in to the session user properties collection :) We already have a custom property to enable users to control the blocking read/write timeout (another spec oversight). I'd have no objection to an org.apache.tomcat.websocket.SERVLET_CONTEXT property being added. If the WebSocket spec adds a property it will be in the javax.websocket namespace and we can always support both. They may opt to simply add a property on the session. The patch to do this looks to be pretty minimal. > I'm certainly not going to commit that myself. :) Trunk and 7.0.x are CTR so you would be well within your rights to commit first. It is often useful to discuss more complex / invasive patches before the commit but I don't think there is much more to discuss here. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Accessing ServletContext from WebSocket endpoint
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 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 eyhpw
Re: Accessing ServletContext from WebSocket endpoint
-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 > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Accessing ServletContext from WebSocket endpoint
On 7 December 2013 04:48, Christopher Schultz 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.. problem is that i don't want to create a session, i just want to ServletContext to read some files. 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. -- Johan Compagner Servoy
RE: org.apache.catalina.session.PersistentManager
Hm... no opinions? > -Original Message- > From: spr...@gmx.eu [mailto:spr...@gmx.eu] > Sent: Donnerstag, 5. Dezember 2013 20:08 > To: 'Tomcat Users List' > Subject: org.apache.catalina.session.PersistentManager > > Hi, > > if I want to use > org.apache.catalina.session.PersistentManager but do not > want the async storage of session data is it sufficient to > add a valve which > stores the session data after the request via > manager.getStore().save(..)? > > And how can I prevent that the session is stored again by the > background > process of the manager? > > Any drawbacks with this approach (besides performance)? > > Thank you > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: On one particular box, Tomcat 7.0.25 runs just fine, but 7.0.47 crashes on takeoff -- some authority problem
2013/12/7 James H. H. Lampert : > We've been systematically updating our customers from Tomcat 7.0.25 to > 7.0.47 this week, after we've determined that our webapp runs just fine on > 47, and 47 runs just fine on AS/400s. > > Until now. > > We have one customer box on which, if you launch Tomcat 7.0.25, it works > just fine. But if you try to launch 7.0.47 instead, it crashes on takeoff, > with this error message (directory name changed to protect the innocent): > >> qsh: 001-0018 Error found running command /foo/tomcat/bin/startup.sh. >> Permission denied. > The above error is printed by the shell, before Tomcat (java) even launches. Check your permissions. Note that if the logs directory is not writable, you wouldn't have any logs even if Tomcat crashes. > > Both of the Tomcat versions are within what I'm calling "foo"; I'm swapping > them in and out by changing the tomcat directory of the one I want active to > "tomcat," and the other to "tomcat.new" or "tomcat.bak." The authorities > look exactly the same, from one to the other, on the two Tomcat directories, > on the corresponding objects within the two directories, and on the > corresponding objects within their respective bin directories. > Just wondering, what do you mean by "objects"? Files? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org