I am in the process of trying to upload my web app to my hosting company's shared server although there is a lot of difficulty in getting this working correctly.
I have tried uploading all the files separately in the ROOT of the domain, tried generating a .war file and uploading that to the ROOT of the domain although there are lots of issues with how my web app is referencing servlet mappings, css files, images etc as they are all based on "/...." (root).
The suggestion to solve this issue by my hosting company was to change "/...." (root) for "/home/my-user-name/public_html/mywarfile".
This is not a good solution for me since this change now makes my web app server dependent, so if I change / upgrade in the future then this is going to involve a lot of work to switch over.
Has anyone had any experience of how to solve this problem, as the hosting company seem to be struggling a little here.... (and they are a good company!)
I've not tried this out myself because I don't have a shared tomcat installation, but try naming the WAR with the special name "ROOT.war" (rather than mywarfile.war) and deploying it as "/home/username/public_html/ROOT.war". That would make it the root context for the tomcat virtual host associated with your domain, which means that your app should be accessible directly with
http://www.yourdomain.com rather than
Any resource referred using root path like
<link rel="stylesheet" href="/styles.css"/>
would then resolve as http://www.yourdomain.com/styles.css, which is ok because all resources are now in the ROOT context.
Speaking for myself, I always use relative paths - it makes everything from testing to deployment easier.
Thanks for the detailed response Karthik, will give that a go.
Can I just check, does the statement in the JavaServlets "package mypackagetest;" need to be the same name as the .war file? Or am I ok simply renaming the .war file from "mypackage.war" to "ROOT.war" without any consequences?
I will also have a read over those links you posted to get a better background and will direct my hosting company to those too!
Will let you know if this fixes the issues.
In terms of using relative vs absolute paths. The reason why I chose absolute paths was due to various includes files issues. For example I have a "headincludes.jsp" file which then references style sheets which are always in "/css/styles.css". So if I include the "headincludes.jsp" file in "/index.jsp" and "/dir/page1.jsp" then if I were to use "../css/styles.css" within the "headincludes.jsp" file then this would not work on the page "/index.jsp".
Can I just check, does the statement in the Java Servlets "package mypackagetest;" need to be the same name as the .war file? Or am I ok simply renaming the .war file from "mypackage.war" to "ROOT.war" without any consequences?
Java package names have no bearing on name of the WAR. Simple rename of mypackage.war to ROOT.war is enough.
Joined: Sep 30, 2009
Bit of an update on this issue, as this is still not solved after a week of speaking with my web host.
The issue seems to be with the url-mappings where by the server is only allowing url's containing '/servlet/' to actually map to a servlet.
For example here are three URLs that all map to the exact same Servlet (the JSP file is the ultimate View for the Servlet)
Here are the following behaviours of these three different URLs when trying to access them.
The .html URL doesn't work at all - no content displaying at all, no indication of even getting to the first step (ie, no errors when not logged in)
The .jsp URL throws an error and says that it cannot find the '/includes/headincludes.jsp' file
The .do URL works!
How could this be?
I have forwarded the same information onto my web host to look into from their end.
There are no setting within my web app that only allow "/servlet/" URLs to actually map to a servlet, since I have "/secure/page1.html" and "/secure/page2.html" all which are used to map to Servlets (since they look nicer for a user).
I just want to make sure that there is nothing within the web app that could be causing this strange issue?
And if anyone has experienced errors like this before within the settings for Tomcat / Shared hosting?
Any additional help much appreciated since the web host doesn't seem to be very useful at the moment and I am thinking about switching (but would prefer not to due to the hassle).
Joined: Sep 30, 2009
Could this be an issue between different versions of Tomcat installed on my machine vs on my web hosts?
My Machine: v6.0.26
Web Host: v5.5.25 (could switch to v5.5.28 which they have on another server too - which I am just about to try)
Since Tomcat v5.xx & Tomcat v6.xx use different Servlet/JSP Spec, I wondered if this would make any difference. I have had a good look around the web about the differences in these versions. The main difference that would apply to my web app is that the Servlet spec 2.5 (Tomcat 6.xx) allows multiple url-patterns & the wildcard * character in url-patterns.
I don't see anything in this thread which says that you have a local installation of Tomcat where you test this sort of thing before uploading to your host. Do you not have one?
Edit: Sorry, your last post does say that. Yes, I would strongly suggest testing with the same version of Tomcat which you plan to use for your live site.
Joined: Sep 30, 2009
This is my first web-app that I am releasing into the wild, so still on a learning curve here :-) Until today, I didn't realise there were so many big differences between the releases.
I have had a look around for an installation of v5.5.25/28, although none of them seem to work on Windows 7 - which is a big annoying since that is what I have.
I am going to have a look around for another web host tonight where I can test my web-app on Tomcat v6.xx so then it should behave the same as on my machine. If that doesn't fix this issue I am a little stuck then...but will cross that bridge if/when it comes.
Unfortunately my current web host doesn't have Tomcat v6.xx installed on their shared servers and doesn't allow a 'trial' on their dedicated servers - fools. So going to have to shop around.