I have a Java web app that I run on an Azure App Service instance. To deploy it, I use a Bitbucket repo with a .war file inside it. When I commit a new .war file to this repo, it is supposed to be deployed automagically by the service. However, more often than not, I have to either restart, re-deploy, or even upload the .war file via FTP for the deployment to be completed successfully.
I have a single Jetty instance residing in this service, hence my .war file is named ROOT.war. AFAIK, when uploaded to the service (whether via Bitbucket or FTP), this .war file should be unarchived into the same directory, which is /site/wwwroot/webapps. In my case, this doesn't happen. The web app works with the ROOT.war file sitting alone inside /site/wwwroot/webapps. And every once in a while, I get a ROOT folder under /site/wwwroot/webapps, with two default files index.jsp and background.png. I don't have the slightest idea what causes the ROOT folder to appear with these default files. The only clue I have is that it happened a couple of times after I changed an environment variable.
Also after the ROOT folder appears with the empty server files, the only way I can re-deploy the app is to manually delete this ROOT folder via FTP or the console provided in the portal, and only then my re-deploy request succeeds with my web app.
So, if it isn't clear enough, my question is what is going on here? I can't make anything out of the behaviors I'm facing. I feel like I'm using this Azure service blindly, and can't get to fix anything when something goes wrong. Are there any resources that may explain what happens in the background when a web app is deployed?
So, Azure API Apps are a PAAS, not IAAS service. You can access the PaaS platform by coming to yoursite.scm.azurewebsites.net, where you can browse the file system in CMD or Powershell, and you can see the running processes. This may feel like you are on a single VM, but you are not. The data you see here is replicated down into your API App instances. You can control how many instances you have through scaling your API App.
I have commonly seen your issue with deploying, then ROOT being empty(working internally to see this fixed...).
The best method that works every time for me, is to stop your API App, manually UNZIP your ROOT.war. Move the files into /ROOT/, then to start your API App.
You can simply place ROOT.war, and let the system unpack it when you turn it back on, but this can sometimes lead to that empty ROOT directory, then requiring another restart.
All of this has me moving to Spring-Boot instead. No unpacking required. Simply configure your web.config and drop the jar file.
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-java-custom-upload#springboot
I had the same problem. The solution is to call the endpoint after de deploy.
Stop the Azure App Service.
Deploy the ROOT.war artifact in the /webapps folder.
Start the Azure App Service.
Call the URL of the App Service once.
The four-step is very important and start the process that you mentioned before (the automagically deploy).
I lost a lot of time figuring out what was the problem.
Related
Well,I'm working on an Eclipse Dynamic Web Project under Tomcat.
I'm trying to make a web application/site.In a jsp/html page,there is a form where a user can upload a photo.
I handle then this action from a servlet that has to store this image/file somewhere so as to make it possible the image appears whenever I want on the site.
Here is the problem.I started by storing it on my file system,(path in a database) but when I wanted to retrieve it the page didn't appear.
I guess the reason is here:
Why can't I do <img src="C:/localfile.jpg">?
Then,I tried to store the file in the eclipse project folder(WebContent/folder) where I've stored manually some images that do appear.
File folder=new File("/TED/res/img");
File file=new File(folder,fileName);
System.out.println(file.toPath());
Files.copy(fileContent, file.toPath());
But this exception happens:
java.nio.file.NoSuchFileException: /TED/res/img/2017-08-13-123524.jpg
It's one the line of files.copy command which means that
new File(folder,fileName) that I tried failed
What should I do? From what I've read,I understood that also saving file in the IDE's project folder is also wrong but what other choice do I have?
Ultimately, the project will be deployed to a server. As such, there are three distinct issues:
Uploaded user content location: content like images should be uploaded to a folder outside your web app (project). Images inside the web app (project) should be those that are necessary for the application and provided by the developer, not user-generated.
In Eclipse, during development and testing, you will want to serve these images through Tomcat. There are many ways to do this. Tomcat configuration is probably not the best for this - please read the answer and discussion here: Simplest way to serve static data from outside the application server in a Java web application
Once the application is deployed to the server, Tomcat will most likely run behind a Web server like Apache or Nginx. In this case, the external image folder and its contained files can be served directly by the Web server. Even if you implemented a servlet in (2) for local testing with Eclipse and this servlet is part of the code that is deployed, it will not be invoked as the URL will be intercepted by the Web server before it reaches Tomcat. For example, if your uploaded image folder is C:\images on your development environment, it can be served by the servlet using the technique in (2) as /images/*. When deployed to a server, the Web server can be configured to servet /images/* from /srv/content/images and this request will never reach Tomcat.
I am not able to find solution change new war file with existing war file on server, i have simple solution just remove existing war file from server and upload new war file on server but site goes down till the time new war file uploading.
Please suggest me what i can, i don't want site goes down.
Thanks in advance.
Instead of deleting the old war, you can just copy the new war over it (hot deploy). That will at least shorten the downtime since you're not waiting for the war to upload.
If you want it to be even shorter, you'll need 2 servers with a load balancer to make sure that you can direct the traffic to one server while the other one is being updated.
You are looking for Zero-Downtime Deployment
Since Tomcat 7 it is possible to deploy an app more then once, just by naming the war.
webapps/foo##001.war => will be deployed as host/foo
webapps/foo##002.war => will also be deployed as host/foo
old sessions will be served by 001, new sessions will start with 002.
There is a good article here: http://java-monitor.com/forum/showthread.php?t=1288
I export my maven java project in Eclipse to War file.
On the server, I open the manager of tomact and add the war application, but when I run the application it seems the application isn't running (or some problem with the resources).
From the other hand, when I start the tomcat by the startup.bat in the tomcat folder and add the War to the webapps folder, it is working. But if I logoff the server , I cannot connect the application remotly. The server is shut down. Why?
What can be the problems?
Thanks!
Me
Why is your application not running? Well - if there's a specific reason for it (and the manager application works) you will see it in the logfile - e.g. tomcat's log/catalina.out. Check it or give us a snippet of the error messages in there if you don't understand them.
I like to recommend not to use the manager application, rather deploy through the OS or any other maintenance tool (e.g. scripted). This typically results in a better maintainable system. As it already works well for you when you just add your WAR file to the webapps directory, everything seems well. Introducing a manager application in production just provides another means to attack your site - and I frequently see those applications poorly maintained (and the passwords poorly chosen & protected)
When you start tomcat with startup.bat, it will run the server process in a console window. This console process will be shut down when you log out. In order to have tomcat running even when you're not logged in (and in order for it to start automatically), you'll have to install it as a service. There's plenty of information on the internet on how to do this - should be extremely easy to find.
I have a web application build using j2ee and java , where user can upload the jar or delete the existing jar and upload a new one. Since server is running and the jars are locked by it, when user choose to delete the jar I am not able to delete it. Is there any way to achieve this ? When I googled I got information about hot deployment or using class loader to unload the jar and then delete it. Whats the good approach to do it ? Any help or suggestion will be really appreciated.
If the file is in use by the web server, the file system simply won't let you remove the file as it's locked by the web server. You have two options.
You could hot deploy a new copy of the jar, for instance if it's a war, say you have (for arguments sake assuming tomcat)...
ROOT.war, you can copy into the webapps directory ROOT#001.war and all traffic will be moved to this location. This new war could contain your new jars.
I personally only do this sparingly as I trust the web server to free resources better when it's restarted. Other than this, your only real option if you want to deploy jars on the fly safely would be to stop the web server, apply the jar, start again. If you want to have no down time you could look at clustering the environment but it really depends how business critical it is to you.
I have a simple web application which lets the user upload local user data and then they can generate HTML reports from that uploaded data. Once the HTML is generated, I display a link to the report which they can click on to view in their browser or they can share the link with others.
The problem is that I am currently putting the "/Upload" folder in the "WEB-INF" folder because I don't want that folder data accessible to the outside world. I am then putting the "Reports" folder in the root directory of the web application. This work fine in that I can deploy the WAR file to the their server, the user can upload the files, and then request for HTML reports to be generated. The problem is that when I send them software updates in the WAR file it deletes everyone in the /MyWebApp directory including the /Upload and /Reports folder. So then the user has to re-upload the data and they loose any of their existing reports in the "/Reports" folder.
Now I did find an answer for the /Upload folder on StackOverflow with this discussion.
Where can I put an uploading folder so that when I deploy/undeploy the site in Tomcat that folder won't be affected
But I still don't know where to put my "/Reports" folder? I thought I would have to put it in the web application context directory as I am doing now in order for the Tomcat server to serve it up as a link (e.g.: http://example.com/MyWebApp/Reports/report01.html).
The other thing to note is that this application is running on Apache Tomcat only, I don't have the request going through an Apache server. We decided to just have it running on the users local server with Tomcat because it seems easier to deploy then trying to deploy and configure both to work together. Also, there are only 2-3 people using this application per server site and with that load Tomcat seems to be doing a great job handling everything on its own. So maybe that is making the solution more difficult?
Any hep with best practices for this would be greatly appreciated.
There should be no difference between the strategy you used for placing uploaded-files on the disk with placing reports on the disk: both are files that were generated by the webapp during its deployment (forget the fact that a client uploaded the file) and need to be protected in the same way.
If you are willing to upgrade to Tomcat 7, there is a new <Context> attribute, aliases, which will allow your webapp to serve content from that directory but not delete it when the webapp is undeployed.