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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to