I have this folder under Tomcat webapps/mysite which is where all my JSPs and other things are located. To access this folder I go to http://blah.com/mysite and it works just fine. However (because of stylesheets and images statically connected to the root /) I have to make it so that when I go to http://blah.com/ it will load the stuff inside webapps/mysite.
I've tried many different things including contexts and setting the absolute path in server.xml... nothing seems to work, whenever I go to http://blah.com/ it still tries to load the ROOT folder... what's happening here?
The solution I use is to set this in your Tomcat server.xml
Add a <Context> element within the <Host> like below which sets your mysite as the default web app. Note the empty path="" which makes it the default.
<Context docBase="mysite" path="" />
Attributes of Context Container from the Tomcat docs:
docBase You may specify an absolute pathname for this directory or WAR file, or a pathname that is relative to the appBase directory
of the owning Host.
path All of the context paths within a particular Host must be unique. If you specify a context path of an empty string (""), you are
defining the default web application for this Host, which will process
all requests not assigned to other Contexts.
See others who have had similar question and the similar answer here, here and here
See also Apache Tomcat Configuration Reference - Context
There are a number of ways to make an application the root application. The simplest way is to just replace the contents of webapps/ROOT with the contents of your web application.
For other solutions, please see the following website:
http://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application_.3F
https://stackoverflow.com/users/1123501/george-siggouroglou 's awnser works but lacks a step.
delete ROOT and all items
copy the war to webapps as ROOT.war
Without the deletion, it may not work. Tested with docker.
You can rename your war from something.war == to ==> ROOT.war.
So, tomcat will unpack the war and will create the folder ROOT for it.
It is a trick that is working on tomcat 8 also.
Related
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.
So, the inverse of this question has been asked before and answered here: How to set the context path of a web application in Tomcat 7.0. However, my application is deployed as "ROOT" and I need it to be available at "my-path" instead of deploying it at "my-path" and needing it available at "ROOT". I'm trying out Amazon's Elastic Beanstalk offering and a deployed war will always go to ROOT. I don't have any control over this and there is not .war file left behind. I tried to aforementioned topic to solve my problem, but it seems that pointing ROOT to another path doesn't work, while pointing another path to ROOT does work.
I will have to create an AMI so that auto scaling can take place without me touching new instances. The only thing I have been able to do to get this working was to create a symbolic link in the webapps folder that points "my-path" to "ROOT." I have no idea if there are significant repercussions of this setup and would like to hear if there are and what alternative there may be that makes use of Tomcat's settings instead or even another non-Tomcat solution.
Thanks!
Update: Once I created the AWS AMI with a symbolic link in the webapps folder and actually changed the AMI in Elastic Beanstalk, I found that my original solution will not work because Beanstalk wipes out the entire webapps directory.
One way to do this would be to deploy the application as ROOT but configure it so all the resources are under the path /my-app in the ROOT web application.
For an existing application deployed as ROOT this would require:
Add a "my-app" directory to the root of the web application and move all your static resources from the root of the web application in to the "my-app" directory.
Add the path "/my-app" to the beginning of all the URL paths in your web.xml and/or annotations
This question already has answers here:
Deploy war on Tomcat without the war name in the URL
(4 answers)
Closed 9 years ago.
I 've just created war file of my web project (JSP/Servlets).
Project name: TestApp
when I deply it in Tomcat 7, I run itlike that:
localhost:8080/TestApp/ or www.maypage.com/testApp/
ok, everything works, but I need to run it without project name, like that:
localhost:8080 and on hosting www.maypage.com
How can I do that?
thank you.
And I'm fining jsp/servlet hosting, which have that configuration option. do you know hosting like that?
In order to access your application without using the application name, you need to deploy it as the root application. There are multiple ways to achieve it and the related answer describes it pretty well.
Setting default application in tomcat 7
Content copied from the above link:
First Method:
first shutdown your tomcat [from the bin directory (sh shutdown.sh)]
then you must delete all the content of your tomcat webapps folder (rm
-fr *) then rename your WAR file to ROOT.war finally start your tomcat [from the bin directory (sh startup.sh)]
Second Method:
leave your war file in CATALINA_BASE/webapps, under its original name
- turn off autoDeploy and deployOnStartup in your Host element in the server.xml file. explicitly define all application Contexts in
server.xml, specifying both path and docBase. You must do this,
because you have disabled all the Tomcat auto-deploy mechanisms, and
Tomcat will not deploy your applications anymore unless it finds their
Context in the server.xml.
Note:
that this last method also implies that in order to make any change to
any application, you will have to stop and restart Tomcat.
Third Method:
Place your war file outside of CATALINA_BASE/webapps (it must be
outside to prevent double deployment). - Place a context file named
ROOT.xml in CATALINA_BASE/conf//. The single element in this context
file MUST have a docBase attribute pointing to the location of your
war file. The path element should not be set - it is derived from the
name of the .xml file, in this case ROOT.xml. See the Context
Container above for details.
If I deploy a war file to Tomcat, called for example foo-bar-1.1.2.war, how can I deploy it so that it is extracted to webapps/bar and its URL root is /bar/...?
My intention here is to keep the war file in the webapps server with its version information so that I know which version is installed but have it overwrite a previous version of the app.
I could deploy the war file using PSI Probe. This would allow me to specify a target context for the web app. However, it means that I would lose any version information in the war file name.
Tomcat will always extract the contents of a war file, to a folder of the same name (when it's configured to deploy wars - as default etc.).
You can extract it to a folder name of your choice. So if you unzip the contents of foo.war to a folder called bar/ manually, instead of just dropping the war into the web apps folder, it'll still load the web application.
However, this is totally unnecessary as you can specify the URL pattern of the application without messing with the folder / war file name at all by overriding the context root element for your application:
This is often set in the Tomcat server.xml - but that practice is fairly widely discouraged. Instead, I'd suggest you use context.xml in the META-INF folder of your web application / war file:
<Context path="/bar" .../>
When the application is deployed, the context.xml should be copied to /conf/Catalina/localhost but renamed to foo.xml
Note that conext roots must be unique and there are some additional considerations if you're using the autoDeploy or deployOnStartup operations (Source http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).
Other options include:
Clean the web apps folder each deployment and drop your new foo-1.1.0 war in.
Include the version number in a flat file. foo/version1
Or simply include the version in a config / XML file.
You could also use Ant (or an equivalent tool) to automate your deployments (and perform any of the above).
There is an important point to emphasize about the path attribute of the context fragment definition. To cite the documentation on the topic:
When autoDeploy or deployOnStartup operations are performed by a Host, the name and context path of the web application are derived from the name(s) of the file(s) that define(s) the web application.
deployOnStartup is the default behavior of Tomcat hosts.
To follow the documentation, this has a very important consequence:
the context path may not be defined in a META-INF/context.xml
According to the ways of defining a Tomcat context, this lets only two solutions:
In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory
Inside a Host element in the main conf/server.xml, which is a discouraged solution in a production environment as it requires restarting the server
Another solution takes advantage of the unpackWARs attribute.
In my point of view, for these reasons, the general and easy way to implement a subtle path in a production environment is taking advantage of the naming of war files (what could include versions management and be a solution to your problem). A single sharp (e.g. test#path.war) in the war file names implies a segment in the context path (e.g. /test/path). A double sharp introduces the version number (e.g. test#path##112.war). This works whether or not unpacking war files, hot deployment or not, is deployment agnostic (manager or file system) and manages multiples versions of a same archive.
But if there is the need to have a path distinct from the archive name, it seems the only solution is the descriptor in the /conf/[enginename]/[hostname]/ directory or the server.xml file. For these, you need an access to the server filesystem.
The relevant solution is highly related to the way Tomcat is configured and managed in the everyday.
If you just want to include a version info in your war file name, you can name it like: my-app##1.2.3.war. It gets unpacked to the directory my-app##1.2.3 but the context will be just my-app (i.e. http://host/my-app/).
Works at least with Tomcat 7.0.55
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