I have a simple hello world java application I deployed, and in the new code I changed the output of the servlet to print some statements in a loop.
It works fine locally.
I uploaded the new .war file, stopped tomcat, deleted the old .war file in /webapps and the exploded folder.
Then I copied the new .war file, and then restarted tomcat.
It exploded the folder, but somehow the code is old.
Could it be caching the .war file somehow?
I did change server.xml and set autodeploy=false but not sure if that is relevant?
delete the work directory and restart tomcat.
Bit too terse sorry.
Tomcat will turn jsp into servlet source before compiling, some caching takes place in the work directory this may be what is causing it to happen.
It has been some time since I used Tomcat but I am fairly sure the structure was something like work/host/engine/context so you will probably find your stuff under work/localhost/Catalina/--web context--
I did change server.xml and set autodeploy=false but not sure if that
is relevant?
oO.
From the docs
This flag value indicates if new web applications, dropped in to the
appBase directory while Tomcat is running, should be automatically
deployed. The flag's value defaults to true. See Automatic Application
Deployment for more information.
I'd start there.
Related
I have an application, that is deployed to Tomcat as war file. I need to be able to update some resources of that application, like files with configurations, maybe classes and stuff.
If I understand correctly, if I replace those files within the directory, to which Tomcat extrcted war, at the next start up they wil be rewritten with contents of my war file. Maybe, I got this wrong?
I thought about deleting war prior to the update, but that seems like a stupid way to go.
Any suggestions are appreciated.
Update
I read here: https://tomcat.apache.org/tomcat-8.0-doc/deployer-howto.html#Deploying_on_a_running_Tomcat_server that the war overwrites the directory when it's "newer". What does that mean? What does Tomcat compare, Date Modified or Date Created or smth else?
For the sake of reproducible and stable builds -- don't. Either re-release your app or store config outside of webapp base.
Tomcat documentation (http://tomcat.apache.org/tomcat-6.0-doc/config/context.html)
Only if a context file does not exist for the application in the
$CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at
/META-INF/context.xml inside the application files. If the web
application is packaged as a WAR then /META-INF/context.xml will be
copied to $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to
match the application's context path. Once this file exists, it will
not be replaced if a new WAR with a newer /META-INF/context.xml is
placed in the host's appBase.
Text in bold is clear. But I notify as not true. (I need exactly this behaviour)
Here are steps:
aaa.war with context.xml included into META-INF
copy to webapps. tomcat deploys. File conf\Catalina\localhost\aaa.xml OK
change aaa.war by changing META-INF/context.xml
copy to webapps
File conf\Catalina\localhost\aaa.xml is changed!!!
What is wrong? Is it a bug or a hidden feature?
Background - the issue I want to resolve:
Configuration independent build and installation. I plant to ship war file. Client per-configures his Tomcat using his own settings. when I ship a new release I just delivery the war without config and when deployed it will use client specific configuration.
By documentation the best place is the context.xml But if it overwritten each time it make no sense to use at all. (why would I use JNDI and such a things if new deliverable has to created? Changing something in build-time is not a big configuration advantage.)
Environment: windows, tomcat 6.0.33
I've run into the same problem and the documentation is at least inadequate, if not directly misleading.
The problem is, that if you copy a new version of an already deployed WAR file to the webapps directory, Tomcat will not redeploy the existing application but undeploy the old application and then deploy the new application. The difference may first seem insignificant, but the problem is that during undeployment of the old application, any context files in conf/Catalina/localhost are deleted as well. Then, the new context file from the current WAR file will be copied to conf/Catalina/localhost during deployment of the new application.
The only feasible solution I've found is not to deploy the new application as a WAR file, but to replace or overwrite the expanded directory, e.g. not to copy aaa.war to webapps/ but to unpack aaa.war directly into webapps/aaa/.
When I put a new war file in the webapps directory and restart tomcat, my war file is exploded but the servlets are not available and their respective log files are not created in the logs directory. When I bounce tomcat again, then the servlets are available and the log files are created. I'm assuming I have setting(s) not correct within tomcat, but I'm not sure where to start.
Does anyone know the cause of my current situation? Or even what parameters to review?
New Additional/Comments: Our setup allows us to have our app 'myApp' be the default application that is seen at root of our URL. On the first starting of tomcat, I can get to myApp by going to /myApp/index.html - whereas on the second start of tomcat I can then just goto and myApp/index.html is displayed.
My welcome file list is the 'myApp/index.html'
I had a similar problem with Tomcat 6.0.26. I worked around it by deleting the exploded webapps before copying the new war file to the webapps directory. Maybe a little kludgy, but it solved my problem.
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
antiJARLocking
If true, the Tomcat classloader will take extra measures to avoid JAR file locking when resources are accessed inside JARs through URLs. This will impact startup time of applications, but could prove to be useful on platforms or configurations where file locking can occur. If not specified, the default value is false.
have you set unpackWars and autoDeploy params to true in your server.xml file?
Try to do unpackwars=false and always make sure tomat is not running when you do deployment try to avoid hot deployment...
I am running several webapps on Jetty 6 through Apache. They are set to hot deploy using .xml files in the contexts/ directory. Those .xml files simply define WebAppContext instances and tell them where to look for a WAR file. `touch'-ing their contexts/.xml files picks up changes to JSPs defined in the relavnt WAR file, which is great.
The problem is that changes to the JARs contained in the WAR file's WEB-INF/lib folder are not picked up. I assume that this is because these JARs are cached somewhere. That assumption is based on the fact that restarting Jetty picks up the changes.
So, the question is: Is it possible to turn off this caching behavior or in some other way get WebAppContext instances to pick up library changes? If so, how?
JBoss hot deploy scanning doesn't check the lib folder:
http://community.jboss.org/wiki/HotDeployLibDirectory
Not sure if Jetty has the same behaviour, but, you could try moving one of your jars into the same folder as one of your jsps to see if this is the case.
If that's not an option then this might help:
http://www.jroller.com/larrywilliams/entry/jetty_hot_deploy
You need to set the scanInterval property to a number larger than zero.
See more here
I downloaded a couple of webapps and placed them in my /webapps folder.
Some of them I could open by going to http://localhost:8080/app1 and it would open.
However, some others I would do the exact same thing and go to http://localhost:8080/app2 and it will display "HTTP Status 404 - /app2/", even though I am sure it is there. I've checked that it contains a WEB-INF folder just like app1, and I've even restarted Tomcat to be sure.
My question is: is there anything (perhaps in the web.xml file) that specifies what the URL has to be to start the webapp? Or is it simply just http://localhost:8080/<folder name> ?
P.S. If you want to know exactly what app1 and app2 I am refering to:
app1 (works) = http://assets.devx.com/sourcecode/11237.zip
app2 (doesn't work) = http://www.laliluna.de/download/eclipse-spring-jdbc-tutorial.zip
I've tried a few others as well, some work, some don't. I'm just wondering if I'm missing something.
I usually debug this by going the the manager page and making sure that all of the contexts are deployed (http://localhost:8080/manager/html).
It sounds like app2 has not been deployed properly or is not starting up because of some other error.
I would look at the logs. There may be a bunch of information in there but usually it explains what is broken.
The second app (the directory named WebRoot) can also be deployed correctly but you get a 404 by going to it because there is not an "index.jsp" or "index.html" file in the root directory.
Try putting a file there with any of those names, and the 404 is gone.
A servlet mapping in the web.xml is not strictly necessary for this to work.
The first zip file you mention has a .war file as part of the zip. The second one is just the source code and it needs to be built into a .war file.
It looks like it is setup to have that done in Eclipse. Try the File>>Export option and select War file as the export type.
The second requires the spring framework. The only runnable things I could find were a client in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\test\de\laliluna\library\TestClient.java and one in eclipse-spring-jdbc-tutorial.zip\SpringJdbc\src\de\laliluna\library\sample\MyApplication.java. If you open it in eclipse (it is an eclipse project), and compile, provided the Spring framework is installed, you should be able to run both.
Are you familiar with log4j? Spring puts a lot of often-useful information into the logs created via log4j. When I have a SpringMVC application that won't startup correctly or otherwise isn't running I check my log4j and potentially turn up the Spring log level to INFO or even DEBUG.
If "/" is not accessible it means that there is no "index.html", "index.jsp" or whatever is defined in the welcome-files list of the web.xml
Also no Servlet-Mapping for the context ROOT directory is present.
Check the web.xml for Servlet-Mappings or try to figure out the name of the jsp/html /... file being in the context root