For security reasons, I wanted to remove docs and examples application. So, at first, I deleted both of them from the webapps directory. However, the remaining applications were not responding in browser, although the tomcat service is running in the server. I got blank screens.
Then I put back docs and examples in webapps directory, and things were back again. Then, I tried to undeploy them using tomcat manager. The undeployment works, but again I got blank screens.
I even tried restricting access to apps using valve and filters. And unfortunately, again I get blank screens.
Permission is not an issue, all contents belong to the tomcat user.
I am using Tomcat 8.5.37.
Update: I started with a clean installation. However, I get same result after undeploying docs and examples.
Update: I think it should be mentioned that we are using aws environment, and there is a load balancer. Also, in front of Tomcat we are using Apache (ajp_proxy).
Related
I have 3 application running on Apache server.
When restart server all application get restarted.
Anyone can explain how to restart single application without affecting other applications in linux.
Thanks in advance!
You can't restart Apache for a single website.
Runnin /sbin/service httpd restart for example will restart Apache as whole, there's no way to restart a single application.
When you say Apache Server, you mean Apache Tomcat? In Tomcat, you can go to the manager page. It's usually in localhost:8080/manager/html. On this page you can start, stop, deploy, undeploy, etc. a single web application. See the Tomcat Manager App How To documentation for more details. Then do a tail -f catalina.out, it should say what app has been started/stopped/deployed/etc.
Simple workaround is to touch specific web.xml file using command touch web.xml.
Tomcat reloads application every time when it notices change in web.xml file, here we are not modifying web.xml file but just touching it.
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.
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 am not sure what I am asking is correct approach or not. So, let me first clarify my requirement.
Till date I was using each app as a root app and was deploying them in separate tomcat instance, but my app number are now growing and I can not keep on deploying a separate instance of tomcat for each app.
There are two things which make me deploy every app as root:
For updating an app you have to shutdown tomcat instance which will also stops other app running in same instance. And I do not want this to happen (as some users are live on one web app or some job is running on some app, so I can not stop all apps at any given time).
For writing urls, if I deploy a web app as root, then in web-app I can simply write "/students/list" , but if I deploy them in same instance with some different context name, then I have to write context name before the urls, like "ctxt1/students/list"
And for developers sake I don't want them to write context name before every url in web-app and also I don't want context names to appear to a user.
Is there any approach with which I can solve these 2 problems. I am thinking of migrating to Glassfish for some apps. If glassfish offer solution to these problems then I can migrate all apps to glassfish as well
Secondly I am running tomcat behind IIS, using ISAPI. If IIS can be of any help here?
You should not use one tomcat per App. The amount of tomcats should increase only when needed (really needed).
It is not true that you have to kill the whole tomcat, for one App update, you should only restart the specific context (going to http://your.tomcat:8080/manager/html).
About the URLs you can use an apache in front with mod_proxy_ajp configured to talk with tomcat (see this: http://httpd.apache.org/docs/2.2/mod/mod_proxy_ajp.html)
We're experiencing slightly strange webapp deployment behaviour under Tomcat 5.5.27 on Linux (both on CentOS in production and Ubuntu 10.04 for development).
App A and app B are almost identical (exactly the same libraries, a copied Maven project), App B differs only in that its JPA entities are annotated to access a different table within the same schema (the JNDI database references are identical).
When the apps are deployed into either environment, app B will not start. However:
Manually starting the stalled app, from the Tomcat admin console, works fine (???).
After any attempt to restart Tomcat, the alphabetically later app fails to start. Point #1 still remains valid (???)
Logging is configured (log4j), however, we get nothing from [the yet-to-start] app B's logging, nor errors from Tomcat's 'catalina.out' log file (NB. logging is working once the apps are up and running).
I've done a reasonably thorough search for information (Apache/Tomcat bugzilla, Google) but I've found nothing of real use. Other posts have sighted the use of the antijarlocking and antiresourcelocking attributes on the server's 'context.xml' 'Context' node, but there is also a suggestion that this is unecessary/inaffective under Linux (hasn't appeared to work here, either).
Any ideas?
Cheers
Rich
P.S. Upgrading from Tomcat 5.5.x isn't an option, currently (IT support etc.).
There is a similar behavior to spring applications on tomcat. -- They require that the webAppRootKey is unique for each application. -- If not the applications behave like you described, so in case of Spring apps, make sure that App-A has an other webAppRootKey then App-B.
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>myRootKey</param-value>
</context-param>
#See http://groups.google.com/group/riotfamily/browse_thread/thread/9a0edf69575d3ab6?pli=1