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

1 Answer 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .