So, I've deployed a Java web application (myapp.war) to a Tomcat 7 server that happens to be running on Amazon EC2. I noticed that, when I do this, it overwrites a similarly-named directory called myapp when I deploy. I further realized that the app is actually being served from that myapp directory and, when I directly make a change to a file in that directory, the changes are served to the client as expected.
My question is does Tomcat do anything to this directory between redeployments? If I make a small change in a file in that directory, will it ever be overwritten before I redeploy again?
It depends.
Changes to class files will probably be ignored.
Changes to JSPs may take effect depending on if the JSP has already been accessed and if the JSP Servlet is configured to check for changes.
Changes to static files will probably take effect but may be delayed by the effects of the static file cache. Normally that delay is only a few seconds but it can be configured to be longer.
Editing web.xml will probably trigger a reload (again this can be disabled with config)
Editing contex.xml will probably trigger a redeploy.
A reload pauses the app, re-reads web.xml and unpauses the app so the user might see a short pause but no 404s. A redploy completely removes the old app and creates a new one. A user may see a 404 in they try accessing it at the wrong time.
As soon as a new WAR file is deployed, all local changes will be lost.
Related
I have a tomcat application which I deploy by placing the new my-project.war file into the /var/lib/tomcat8/webapps/ directory on my server (via scp).
Every time I do this, the new copy is live a few seconds later. The only problem is that it drops all the sessions.
All the documentation I can find tells me that Tomcat should restore the sessions by default. This does seem to be the case when I restart the Tomcat service, but not when I redeploy...
Can anyone tell me whats going on here? I don't fully understand why it works to deploy this way in the first place.
The default session manager - StandardManager saves the sessions in <tomcat-home>/work/<app-name>/SESSIONS.ser. When you stop tomcat, the sessions are serialized into that file. When you start it - they are loaded from it.
But when you re-deploy your applications two things happen:
Tomcat un-deploys the old app and deletes the <tomcat-home>/work/<app-name>/ folder, thus removes the saved sessions
Tomcat deploys the new app and creates a new folder
Or in two words - tomcat deletes the saved sessions on un-deploy. I guess this is because:
the re-deploy is implemented as undeploy -> deploy. I.e. the 'undeploy' step does not know if a new version of the app will be deployed, so it makes sure to properly clean up after itself.
it's better from security perspective
I have deployed applications in Websphere 8.5, and I want to modify web.xml, but it seems not working. What I am supposed to do?
While there are documented ways of updating enterprise application files, those were conceived for multi-server deployments and partly are legacy of the previous decade of monster application servers. They are inconvenient for making changes to local development server and it wastes a lot of time.
Upon application deployment, WAS creates (copies/updates) deployment descriptors in the config directory. Then web.xml is used from that location.
You are probably changing web.xml in the location where original application files are kept, thus no effect. You should change the one in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF.
WebSphere writes a second file named web_merged.xml. If you only update the web.xml and replace it you will not update the runtime file used by the container.
Best result I had was using the single file upload function provided within the Admin console or to use the wsadmin or jacl cmd.
The proper way is to update application via console/script.
But I'm assuming you are editing file directly (very hard to guess from your description, I've asked you to describe your procedure).
You need to restart the application to pick up changes in web.xml. See the Hot deploy in WAR files
Two ways:
Update web.xml with WebSphere Web Console
Update web_merged.xml at the same time, and also update the two files in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF
I am adding some things in an existing Android app, which connects to a Apache Tomcat server to get information from a database, but some of the changes required that I also make minor changes on the webapp (changing some database fields).
I had never used tomcat, but managed to do the simple changes here and there.
But when I deployed it, I noticed some errors(see the photo).
How can I fix them ?
The app works regardless of them, but the server takes a few more seconds to start up.
P.S.I read somewhere that this means that the server already has these libs, and doesnt need to use the ones from the lib folder of the app ?
I have multiple applications that share common jars, so I decided to put them in the shared library and add a reference to all the applications.
Now the problem is that when I make a change in one of the jars and put them back I have to re start the server.
The weird thing is that I have to do that on my local system and not on the shared server, i was trying to find the setting that will allow me to upload the jar and see the effect with out restarting the server.
One of the blogs says it it not possible but on the shared server it happens so I am sure it is definitely possible.
Please advice what can be done here.
thanks
It sounds like you've configured the shared library to be a part of the server's classpath. Any JARs on the server classpath are only loaded once on server startup. Changes to these JARs require a full server restart.
Libraries that are added to the application's classpath can be reloaded dynamically. The application will still need to restart when the JAR gets changed but that's a much lighter operation and WAS will often automatically detect a file system change and restart the affected applications.
Check how you've configured your shared library to make sure it's being loaded on the application classpath.
I recently implemented Capistrano for the first time with a new cloud production environment. When I run cap deploy, everything seems to work fine. I can visit my live application in the browser, but my static files seem to load very slowly (like 5.0-12.0s).
See answer for clarity on config.assets.compile.
Static files load slowly because they possibly are not static, but are being served by Sprockets.
Check in production.rb and see if config.assets.compile = true or it is not set. That would mean that Sprockets is doing the work. You would also see far-future headers being used.
Have a look in /home/my_user/my_app/current/public and see if assets exists; I suspect it does not.
That means that mkdir -p is not working. The most likely cause is that the deploy user does not have sufficient permissions to create the directory.
Fix that, and also check (if this is an upgraded app from 3.0 or before) that your config setting match those in the last section of the pipeline guide.