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 jam...@touchtonecorp.com: 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
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: Accessing ServletContext from WebSocket endpoint
On 7 December 2013 04:48, Christopher Schultz ch...@christopherschultz.netwrote: 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: 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 ch...@christopherschultz.netwrote: 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
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
ch...@christopherschultz.netwrote:
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
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
