This may not be a difficult question, but I probably do not have the right terminology and am not finding the answer.
When I deploy a war file in Tomcat (7), say, myapp-1.0.war, a new directory, myapp-1.0, is created under webapps. Is there a way to change the name of the new directory? e.g. When I deploy myapp-1.0.war, the new directory is named myapp? Is this configurable inside the war file somehow?
I have implemented this by adding a symlink to the webapps directory and placing my war file in a directory outside of the appBase. This way I was able to standardize the docBase in the server.xml. Now all I have to do is update the symlink when new versions are posted (and maybe restart the server). My configuration is posted at another question:
Tomcat 7 symbolic link to war file
Related
My customer told what is path of
'tomcat/work/Catalina/localhost/_/org/apache/jsp'
but i don`t know well what is it.
I saw these folder fist time. and maybe the path is created just in operation environment that in my environment of development, these path isn't created.
what is that path and is that must necessity on tomcat?
work directory is where your compiled JSPs and other static resources will go.
if you have Deployed archive file as ROOT.war folder with name _ will be created in tomcat/work/Catalina/localhost/ otherwise the folder name will be same as that of your web archieve file.
Note: It is advised to clear work directory before every deployment.
Clarifications on Tomcat's "temp" and "work" directories
https://tomcat.apache.org/tomcat-7.0-doc/config/host.html
I previously used the following to get my context path on Tomcat-5.0.28 and earlier:
String context_path = context.getRealPath("/WEB-INF/");
This worked to return the path to that folder.
But on OpenShift (Tomcat 6 - JBoss EWS 1.0) this returns
/var/lib/openshift/53.*context_id_here*..18/jbossews/null
The null should be:
work/Catalina/localhost/_/WEB-INF
How can I get the path to the WEB-INF folder on OpenShift using JBOSS/Tomcat?
A little background information: When I ran this struts webapp on my own Tomcat server, I deployed a appname.war file in the webapps directory and waited for it to expand (since I had set that option in the server.xml file). Then I move a folder to webapps/appname/ folder with xml files I need to read and write to for my app to work. On OpenShift I used jar xvf appname.war to extract the war file by hand (because that's the default and I don't know how to change it), and then moved the files folder (from the same directory as the war file in my folder after a git add and push) to work/Catalina/localhost/_/WEB-INF/
This is causing a NullPointerException for me when trying to use that path as shown above.
I think you should be using something like getServletContext or getRealPath, and reading it from the web root instead of trying to find the file on the physical disk. That way your war file can run anywhere without issue. Try looking up both of those and see if one fits your use case.
I'm trying to deploy a war on Tomcat 7.0, and in the server.xml file, I've set unpackWARs = true and autoDeploy = true.
Since I want this war file to be the default web application, I have deleted the ROOT folder inside ...Tomcat7.0/webapps. Then on, when I try to start the Tomcat service, I see a behavior that I have yet failed to identify a pattern in:
Sometimes, the war is unpacked to a newly created folder named
'ROOT'.
Some other times, it is unpacked to a folder that is named
the same as the name of the war file. E.g. if the war file is
'MyWebApp.war', it's unpacked to a folder named 'MyWebApp'.
It seems to be completely erratic and random, but I am sure there is method behind this apparent madness. As a rule, I am not sure if there is anything that dictates the creation of a ROOT folder. I have tried to edit the server.xml file and add context to my web application in it, but it doesn't seem to make a difference.
What am I missing? Thanks in advance!
Name your war file ROOT.war. It will unpack to ../webapps/ROOT and map to / context
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/.
The tomcat 6.0 document at http://tomcat.apache.org/tomcat-6.0-doc/config/context.html says:
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.
However I noticed that if you put new war file in webapp directory, the context.xml in META-INF directory replaces context.xml in $CATALINA_BASE/conf/[enginename]/[hostname].
Is there any configuration which makes sure that context.xml in $CATALINA_BASE/conf/[enginename]/[hostname]/ is not overwritten whenever new war file is deployed.
Edit: I am using autodeploy="true" From the comment of JoseK, I understand when tomcat sees new war file, it undeploys old application (leading to deletion of context file) and deploys the the new war file (leading to creation of new war file). In that case the above information from tomcat document is not relavant. The new question can there be any situation where the above thing can happen?
I agree that the documentation is misleading. Normally, this behaviour is actually welcomed since when you deploy a new version of your application, you want to have your updated context.xml file deployed as well. If you plan on editing your context.xml file manually on your production server, I suggest skip it altogether and copy its content to conf/server.xml file.
A quick patch/solution to your problem (wouldn't do it myself) is to mark the context.xml file as readonly after it has been deployed and updated the first time. This way Tomcat cannot delete/update it.
If you want to avoid overwriting of 'context.xml', you could go to Tomcat Manager url
and then uninstall the previous app and install the new war/ear.
This way you have more control on the installation process.