Develop Reference

Can i place a manually extracted war in tomcat instead of deployOnStartup=true. Is it proper to have already extracted war files in tomcat

I added deployOnStartup="true" in the tomcat server.xml. But it is recommended to have deployOnStartup="false" due to security issue as keeping it true allows malicious or untested applications to be deployed and so it should be disabled.
What is the issue with keeping the extracted war files in the webapps directly, without having to extract each time.

I think you misunderstand what deployOnStartup does. There are 4 ways to add a web application to Tomcat:
Configure a <Context> element inside a <Host> element in conf/server.xml. Any change to the <Context> element will require a server restart,
Add an <application-name>.xml file to the host's configBase directory (conf/Catalina/<host-name>),
Add a WAR file to the host's appBase directory (usually webapps),
Add a directory to the host's appBase directory.
There is no difference between 3 and 4.
If you set deployOnStartup="false" and autoDeploy="false", web applications defined using 2, 3 and 4 will not be deployed. You'll need to manually deploy them through JMX or Tomcat Manager after each server restart. If you leave autoDeploy="true" (default value), web applications from points 2, 3 and 4 will not be deployed at startup, but a few seconds later, when Tomcat scans for changes in the applications.
From a security perspective deployOnStartup="false" is an extreme solution, as it forces you to define everything inside server.xml. You can obtain a similar effect by:
making the entire conf directory writable by the administrator only and readable by the system user running Tomcat,
making the webapps directory writable by the administrator and Tomcat user only. If you make it writable by the administrator only, you'll need to set unpackWARs="false" and you will not be able to deploy new WARs using Tomcat Manager.

change in configuration/setting without restarting Tomcat

Ideally what I want to be able to do is load in a fresh copy of the config if a change is detected so that if it is updated in the DB, it gets fetched and updated in the application without a restart.
I tried to add autodeploy = true inside host, server.xml and reloadable = true inside context.xml.But none of this worked.
Is there any other solution for this. Iam using eclipse IDE and my sever is Tomcat.
I read adding inside context will help for this.
<Context reloadable="true">
<!-- Default set of monitored resources -->
<WatchedResource>Config/Design/configs/globalconfig</WatchedResource>
But this one still din't help me.Am I giving the path in wrong way or something?I got this from the following link https://www.mulesoft.com/tcat/tomcat-reload
Edited Besides I tried with the auto reload on module, disabled and enabled as well. And also noting one more thing here I don't want to use JRebel.

If I go by the heading of the question
change in configuration/setting without restarting Tomcat
I would agree with Jomcy Johny, that the design approach perhaps need to be reviewed. In continuation to the above comment, perhaps you should consider keeping the configuration outside of the container. There are many way of achieving the same, one possible direction is with Apache Zookeeper.
On the side note, the path mentioned in the Mule document is generally of form 'WEB-INF/x/yz' or '/Dir0/config.file'.

It is possible to deploy web applications to a running Tomcat server.
If the Host autoDeploy attribute is "true", the Host will attempt to deploy and update web applications dynamically, as needed, for example if a new .WAR is dropped into the appBase. For this to work, the Host needs to have background processing enabled which is the default configuration.
autoDeploy set to "true" and a running Tomcat allows for:
Deployment of .WAR files copied into the Host appBase.
Deployment of exploded web applications which are copied into the
Host appBase.
Re-deployment of a web application which has already been deployed
from a .WAR when the new .WAR is provided. In this case the exploded
web application is removed, and the .WAR is expanded again. Note that
the explosion will not occur if the Host is configured so that .WARs
are not exploded with a unpackWARs attribute set to "false", in which
case the web application will be simply redeployed as a compressed
archive.
Re-deployment of a web application if the /WEB-INF/web.xml file (or
any other resource defined as a WatchedResource) is updated.
Re-deployment of a web application if the Context Descriptor file
from which the web application has been deployed is updated.
Re-deployment of a web application if a Context Descriptor file (with
a filename corresponding to the Context path of the previously
deployed web application) is added to the
$CATALINA_HOME/conf/[enginename]/[hostname]/ directory.
Undeployment of a web application if its document base (docBase) is
deleted. Note that on Windows, this assumes that anti-locking
features (see Context configuration) are enabled, otherwise it is not
possible to delete the resources of a running web application
Above is a snippet from Apache tomcat And also most of the general idea about hot deployment I gained from hot deploy

Reloading Context elements when they are within the server.xml is not likely to work as "...server.xml file cannot be reloaded without restarting Tomcat"[1].
What you can try, is creating a file at "/META-INF/context.xml"[1], and adding the context in there.
Then you can replace the war file if with the new context files without a server restart.
Or you program a server restart in if needed. See [2]
source:
[1] https://tomcat.apache.org/tomcat-8.5-doc/config/context#Defining_a_context
[2] Java - Tomcat: Reload context.xml without restarting server

You can write a script and run it as a service outside your application to keep a track of your config file's last modified time, in case of a change you switch to your Tomcat container and run the following command (considering OS is Linux):
source ~/.bashrc
(In case of windows, its done as soon as you change environment variables and save.)
Hope that this helps.

tomcat context setting and URL issue

I have a web app run in tomcat 8. I want to change the access URL.
I use the tomcat default manager app for example.
With the default config, the manager app locates on webapps folder. The manager means the app name. But if I don't want to expose the app name and want the app to be accessed by localhost:8080/tomcat-manager, what should I do?
According the official documents, I modified the context.xml in manager/META-INF folder. My context.xml is as below:
<Context path="/tomcat-manager" docBase="manager"> </Context>
Then I think I can access the manager app by localhost:8080/tomcat-manager, but it doesn't work.
So I want to know how can I do this?

Re-name the folder called manager to tomcat-manager and you are done.
Read the documentation for more information.
UPDATE
You should never specify path in your META-INF/context.xml file: the path will be determined from the name of the WAR file. Also, never specify the docBase in META-INF/context.xml, because the docBase is already known (the META-INF/context.xml is already relative to something: the docBase).
That said, if you use an external context.xml file (e.g. in $CATALINA_BASE/conf/[engine]/[host]/[appname].xml then you must specify a docBase pointing to your WAR file (or exploded WAR directory). You will still never use path in that file.

Access Tomcat root application under different path (on AWS/Elastic Beanstalk)

We are deploying a webapp (.war file) from a legacy system where we have full control over our Tomcat instances to Amazon's Elastic Beanstalk instances.
On our own systems, we access the web app as a path (e.g. http://server-name/my-app if we deploy my-app.war), but Elastic Beanstalk renames our war-file to ROOT.war and hence makes the web app available under http://server-name, which breaks our existing applications.
As per the AWS documentation, we have added a config file under WEB-INF/.ebextensions that copies the following custom context.xml-file to /etc/tomcat7/Catalina/localhost/ROOT.xml:
<?xml version='1.0' encoding='utf-8'?>
<Context displayName="localhost" docBase="" path="/my-app">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
</Context>
We have tried different versions of this file, e.g. omitting docBase, specifying docBase="ROOT", using the aliases parameter etc., providing the full path to the ROOT directory etc., but none has made our WAR-file accessible under the /my-app path.
Finally, we also tried putting this <Context />-definition under the <Host /> section in server.xml, but to no avail. Any suggestions?
Update: when adding the following to server.xml under the <Host/>-definition, I'm able to access my-app under the correct path, but it seems that Tomcat on EB is deploying my application twice now:
<Context path="/my-app" docBase="ROOT/"></Context>

Although we can now access our app under the desired path, the application is still deployed twice by Tomcat. While this is a minor nuisance for us, I can imagine this being a problem on more resource-tight machines. On the plus side, we can now start migrating our apps to no longer use the resource path when accessing the API, which leads to cleaner and shorter API URLs.

I know it's two years late. But seems like disabling deployOnStartup will do the work.
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="false" deployOnStartup="false">

Tomcat 5.5 doesn't recognize DataSource at startup (Null component Catalina:type=DataSource)

I have set up a Postgres 9.0.1 SQL server and a Tomcat 5.5.28 both at my local PC. Both are running fine. But I have not been able to configure Tomcat to make the DataSource available via JNDI. I think I have followed the JNDI HOW-TO from the Tomcat pages to the letter (as well as having tried some other how-to's from other pages, too). But everytime Tomcat starts he displays the error message:
SEVERE: Null component Catalina:type=DataSource,path=/MyApp,host=localhost,class=javax.sql.DataSource,name="jdbc/postgres"
Tomcat does start nonetheless, but my database code won't work, because my InitialContext.lookup ends up with nothing.
The postgres driver "postgresql-8.4-701.jdbc4.jar" is copied into the following folders:
I:\Apache Software Foundation\Tomcat 5.5\common\lib
I:\Apache Software Foundation\Tomcat 5.5\webapps\MyApp\WEB-INF\lib
Here is my MyApp/META-INF/context.xml:
<Context path="/MyApp" docBase="MyApp" crossContext="true" reloadable="true" debug="1">
<Resource name="jdbc/postgres"
auth="Container"
type="javax.sql.DataSource"
username="postgres"
password="xxx"
driverClassName="org.postgresql.Driver"
url="jdbc:postgresql://localhost/MyDatabase"
maxWait="1000"
maxActive="20"
maxIdle="10">
</Resource>
</Context>
Here is an excerpt from my MyApp/WEB-INF/web.xml:
<web-app>
…
<resource-ref>
<description>
Postgres resource reference to a factory
</description>
<res-ref-name>
jdbc/postgres
</res-ref-name>
<res-type>
javax.sql.DataSource
</res-type>
<res-auth>
Container
</res-auth>
</resource-ref>
</web-app>
My project is deployed as a WAR by Eclipse and Tomcat explodes the WAR at startup as a folder. Now the strange thing: If I doesn't start Tomcat by hand, but by Eclipse, everything works!!! Tomcat doesn't come up with the error message above.
I have discovered Eclipse uses its own server.xml, context.xml etc. when it starts Tomcat itself, but even after comparing those files with Tomcat's regular config files the only difference I have spotted so far is the following additional line in Eclipse's server.xml before the closing "host" tag:
<Context docBase="MyApp" path="/MyApp" reloadable="true" source="org.eclipse.jst.j2ee.server:MyApp"/>
But even when I copy this line into Tomcat's own server.xml (without the "source"-attribute), it doesn't work without Eclipse. So Eclipse must do something "extra" which makes finding the DataSource possible, while the "normal" Tomcat configuration fails. Since I have to deploy the WAR on a different server (without Eclipse) I need help to make this run without Eclipse. I think my code is ok, since it works fine with Eclipse's Tomcat, but my configuration of Tomcat 5.5 must be faulty. Any ideas?

After spending some more hours on the problem I have found a way to avoid Tomcat's error message. It seems my Eclipse configuration was faulty, because it was configured to add some of Tomcat's own jars into the folder "I:\Apache Software Foundation\Tomcat 5.5\webapps\MyApp\WEB-INF\lib". After I changed Eclipse's setting to not include them but to use those libraries as referenced ones, they weren't included in the WAR file anymore and Tomcat started without error. To be more precise, the following three jars being duplicated in the lib of my webapp had to be removed to avoid the message: "naming-factory.jar", "naming-factory-dbcp.jar" and "naming-resources.jar".
Interestingly, although Tomcat was starting fine now, the result remained the same: If started from within Eclipse, my webapp would succeed with the JNDI lookup for the datasource, but when I started Tomcat without using Eclipse, the webapp still would fail when trying to access the database with the error message below:
Cannot create JDBC driver of class '' for connect URL 'null'
It took me some more time to get this working, too. I had to give up on the preferred method of defining an app-specific datasource, but defined a global one instead. I still don't know WHY Tomcat refuses to understand my app-specific settings, but at least one can circumvent the problem. Following are the steps that solved all my problems and allowed me the JNDI lookup:
Modifying the server.xml file in %CATALINA_HOME%/conf/server.xml inside the tag "GlobalNamingResources": Here I added the complete "Resource" tag section that was already in my context.xml (see above).
Modifying the context.xml file in %CATALINA_HOME%/conf/context.xml inside the "Context" tag: Here I added the line: <ResourceLink global="jdbc/postgres" name="jdbc/postgres" type="javax.sql.DataSource"/>
I left the webapp-specific web.xml and context.xml unchanged (as seen above). Everything is working now. I post the solution to my problem I found myself in the hope others with a similar problem may benefit.