Improve Java site deployments
Deploying a Java application to Azure for the first time is not bad, but incremental updates are very painful. The basic functionality works, but it involved multiple steps that really shouldn't be there.
1. Every time that you want to deploy a WAR file, you have to delete the application's exploded directory (ROOT, for example). In order to do this properly, you have to stop the server first. You should be able to simply replace the WAR file (ROOT.war, for example), and have Tomcat take care of updating the application. If you have an application that is large or has a lot of files this process can take your application out of service for a long time (20+ minutes to delete all the files over FTP in my case).
2. There is no easy way to redeploy/restart Tomcat without taking the service out completely. When updating certain classes that may be loaded in memory, you may need to trigger a Tomcat redeploy.
3. When deploying WAR files over GIT (or any of the other deployment methods), it looks like Azure SOMETIMES attempts to have Tomcat deploy the newly uploaded file before it is finished uploading. This results in a partial application deploy and requires to you to restart the server anyway to get it to load properly.
Deploying exploded WAR files via a repository seems to work OK, but classes don't always get reloaded if they change.
4. The Catalina and other tomcat generated logs seem to be locked by the OS (even for reading), and are unavailable via FTP until the site is stopped. This makes debugging issues very difficult, as errors can't be read while the server is running.
There are a number of bumps with how we enable publishing for Tomcat and Jetty. The system we have is pretty open ended as it allows you to drop in nearly any Java application. Unfortunately the side effect is that the more PaaS like experiences that are reasonably expected with the built in Tomcat/Jetty are subject to the bumps when publishing to Tomcat/Jetty that is configured with the war autoload capability. Long story short, there are work items that we are looking at to make this better when using the built in Tomcat and Jetty.
Frank G. commented
Still buggy WAR-File hot deployment using Kudu. Don´t think about CICD, when you have to unzip all files manually on the WebApp. That´s a showstopper for production.
Alon Klein commented
two years after. any news?
Rob Barrett commented
Bump. No update since Oct 2014.
George Platon commented
Better support for Java, would be really helpful! Had the similar issues so far.
One more addition to the post above - is there any planned feature to have the deployment done by fetching the war archive from an artifactory ? (E.g Nexus or Jfrog)
All the best
Josh B. commented
Any update on this?