1

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?

EDIT:

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/apth/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
0

The issue is a common one. With binary portable war files, context configuration (environment) is in the context where it should be - not in the war file. On re-deployment, e.g. when applying a software patch, the container (Tomcat) should re-deploy without deleting the context.

This issue is being addressed at Re-deploy from war without deleting context. Apparently the assumption is that this is already possible with the text interface, so a case where this is not possible could be considered a bug.

The suggested solution is to watch this Tomcat issue until it is resolved, because this serverfault issue becomes a duplicate of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.