You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by ptruche <pt...@yahoo.com.INVALID> on 2015/10/13 17:09:13 UTC
Unable to deploy app with Tomcat Manager Text interface using a
Context Descriptor
My application context is defined as an XML file located in `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
<Context docBase='/my/path/to/myApp/myAppWarFile.war'> <Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/> </Context>
`/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring.
Tomcat is configured with autoDeploy turned off. When I start Tomcat, it creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets unpacked into this location as expected, and the application of course can run as expected.
When I want to deploy a new version without restarting Tomcat, I run the undeploy command as follows:
curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password
... and that works. But when I instruct Tomcat to deploy with the following curl statement, I get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password # Tomcat response FAIL - Invalid context path null was specified
Adding the path does not help much, I still get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password
# Tomcat response FAIL - Failed to deploy application at context path /my-app
The worst part is that tailing catalina.out does not yield any insight. And on top of that, Tomcat deletes the application context XML file `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!
Naturally I have reviewed Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) and I have googled all day to figure this out, but I have not found anything that can help me with this particular configuration.
It feels as though the choice is:
1. Tomcat with autoDeploy on (not recommended for production) in which case simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot deploy the app. 2. Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart because the deploy API does not seem to be working as advertised.
Has anybody made this work with this configuration?
ADDITIONAL INFORMATION
I turned up the logging on Catalina. When I run the first deploy command without the path, I get this set of log entries:
FINE: Start processing with input [config=file:/my/path/to/tomcat/conf/Catalina/localhost/my-app.xml] Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [OPEN] Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor process FINE: Error parsing HTTP request header java.io.EOFException: Unexpected EOF read on the socket at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:744)
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [CLOSED] Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown FINE: Counting down[http-bio-8080-exec-16] latch=1
SERVER CONFIG
Apache Tomcat 7.0.55 (but confirmed same problem with 7.0.59 and 8.0.12. Tomcat configured to run as a service with tomcat user and group owning the catalina base and subfolders, and the docBase folders outside of the appBase Centos 6.5
Re: Unable to deploy app with Tomcat Manager Text interface using a
Context Descriptor
Posted by Mark Thomas <ma...@apache.org>.
On 13/10/2015 16:31, ptruche wrote:
> Sorry about the formatting issue. Here is the corrected version.-------------------------------------------------------------------------------
>
> My application context is defined as an XML file located in `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
>
> <Context docBase='/my/path/to/myApp/myAppWarFile.war'>
> <Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/>
> </Context>
>
> `/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring.
>
> Tomcat is configured with autoDeploy turned off. When I start Tomcat, it creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets unpacked into this location as expected, and the application of course can run as expected.
That is an odd looking location for the WAR to be unpacked to. I'd
expect "my/path/to/Tomcat/webapps/my-app/"
> When I want to deploy a new version without restarting Tomcat, I run the undeploy command as follows:
>
> curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password
Note: Undeploy removes the xml from
"my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml"
> ... and that works. But when I instruct Tomcat to deploy with the following curl statement, I get a failure.
>
> curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password
> # Tomcat response
> FAIL - Invalid context path null was specified
>
> Adding the path does not help much, I still get a failure.
>
> curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password
>
> # Tomcat response
> FAIL - Failed to deploy application at context path /my-app
Those are expected since the context.xml no longer exists. Better error
messages would be nice in those cases. Patches welcome.
> The worst part is that tailing catalina.out does not yield any insight. And on top of that, Tomcat deletes the application context XML file `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!
>
> Naturally I have reviewed Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) and I have googled all day to figure this out, but I have not found anything that can help me with this particular configuration.
This page might also be useful:
http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html
> It feels as though the choice is:
>
> 1. Tomcat with autoDeploy on (not recommended for production) in which case simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot deploy the app.
There are reasons not to enable autoDeploy in production (mainly
security) but I wouldn't go as far as to say you should never use
autoDeploy in production.
> 2. Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart because the deploy API does not seem to be working as advertised.
>
> Has anybody made this work with this configuration?
If you want to do this with autoDeploy disabled, I think what you need
to do is:
- Update the external WAR file. Tomcat should ignore this since
autoDeploy is disabled.
- Then, without undeploying the old version, trigger a redeployment via
the Manager using the same curl command as the original deployment but
include the update=true
HTH,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Unable to deploy app with Tomcat Manager Text interface using a
Context Descriptor
Posted by ptruche <pt...@yahoo.com.INVALID>.
My application context is defined as an XML file located in `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`.
<Context docBase='/my/path/to/myApp/myAppWarFile.war'> <Environment name='my_config_dir' value='/my/path/to/myApp' type='java.lang.String'/> </Context>
`/my/path/to/myApp` contains the WAR file myAppWarFile.war and a number of externalized properties that are read by Spring.
Tomcat is configured with autoDeploy turned off. When I start Tomcat, it creates `my/path/to/Tomcat/conf/webapps/my-app/` and the WAR file gets unpacked into this location as expected, and the application of course can run as expected.
When I want to deploy a new version without restarting Tomcat, I run the undeploy command as follows:
curl http://localhost:8080/manager/text/undeploy?path=/my-app --user my-username:my-password
... and that works. But when I instruct Tomcat to deploy with the following curl statement, I get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml --user my-username:my-password # Tomcat response FAIL - Invalid context path null was specified
Adding the path does not help much, I still get a failure.
curl http://localhost:8080/manager/text/deploy?config=file:/my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml\&path=/my-app --user my-username:my-password
# Tomcat response FAIL - Failed to deploy application at context path /my-app
The worst part is that tailing catalina.out does not yield any insight. And on top of that, Tomcat deletes the application context XML file `my/path/to/Tomcat/conf/Catalina/localhost/my-app.xml`!
Naturally I have reviewed Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/manager-howto.html#Deploy_using_a_Context_configuration_%22.xml%22_file) and I have googled all day to figure this out, but I have not found anything that can help me with this particular configuration.
It feels as though the choice is:
1. Tomcat with autoDeploy on (not recommended for production) in which case simply dropping the new WAR to `/my/path/to/myApp/` will cause Tomcat to hot deploy the app. 2. Tomcat with autoDeploy off, but re-deploying requires a Tomcat restart because the deploy API does not seem to be working as advertised.
Has anybody made this work with this configuration?
ADDITIONAL INFORMATION
I turned up the logging on Catalina. When I run the first deploy command without the path, I get this set of log entries:
FINE: Start processing with input [config=file:/my/path/to/tomcat/conf/Catalina/localhost/my-app.xml] Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [OPEN] Oct 13, 2015 10:04:53 AM org.apache.coyote.http11.AbstractHttp11Processor process FINE: Error parsing HTTP request header java.io.EOFException: Unexpected EOF read on the socket at org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:168) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:982) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:611) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:744)
Oct 13, 2015 10:04:53 AM org.apache.coyote.AbstractProtocol$AbstractConnectionHandler process FINE: Socket: [org.apache.tomcat.util.net.SocketWrapper@189651c1:Socket[addr=/0:0:0:0:0:0:0:1,port=45415,localport=8080]], Status in: [OPEN_READ], State out: [CLOSED] Oct 13, 2015 10:04:53 AM org.apache.tomcat.util.threads.LimitLatch countDown FINE: Counting down[http-bio-8080-exec-16] latch=1
SERVER CONFIG
Apache Tomcat 7.0.55 (but confirmed same problem with 7.0.59 and 8.0.12. Tomcat configured to run as a service with tomcat user and group owning the catalina base and subfolders, and the docBase folders outside of the appBase Centos 6.5