I am a newbie for web hosting. I wanted to host my first website on shared tomcat on windows but always need to append the war file name with my domain name as domain.com/war-file-name.
I want to get my pages only by entering domain.com.
Please let me know how to achieve this.
It's not "domain.com/war-file-name". It's servername/contextName.
The servername is the fully-qualified domain name (FQDN) of the server or something that can be converted into a FQDN. For example, "coderanch.com" will be attempted as "www.coderanch.com", where "www" is the actual name of the server within the coderanch.com domain. Alternatively, you could simply supply the IP address of that server, as the first thing that your web client is going to do is look up www.coderanch.com to get the IP address. That's how TCP/IP knows where to send the request.
The contextName is the logical name that distinguishes one webapp within a Tomcat instance from all the other webapps that it is running so that when the server receives the request, Tomcat will know which app to route the request to. If you just dump a WAR into the TOMCAT_HOME/webapps directory, a context will be created automatically and given the name of the WAR, but there are other options.
Bear is referring to replacing the root context - "/" with your webapp. I'm not a big fan of that, actually.
One thing I didn't mention is that "servername/contextName" is not sufficient for the web to talk to Tomcat. Tomcat runs (as distributed) listening on TCP/IP port 8080. DNS, however, only looks up IP addresses. If you send a web request and don't include the port number (":8080"), then the web client will target the server's port 80. Most OS's require elevated security privileges to listen on port 80. Thus, if you re-configure Tomcat to listen on port 80, you have to make it run as a privileged user, and that's a security risk. Most industrial-grade web server systems will incorporate a proxy such as Apache or IIS to listen on port 80 and forward the requests to Tomcat in order to avoid that risk. The proxying mechanism can also add in the context name, eliminating the need to deploy the webapp under the root context.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.