tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Sexton <geor...@mhsoftware.com>
Subject OT: GoDaddy Hosting and Tomcat
Date Mon, 27 Apr 2009 14:44:49 GMT
I thought I'd write up my experiences trying to get a servlet
application running on GoDaddy. Perhaps it will save someone else some pain.

I have a Java Servlet calendar application. It's a stable app and I've
got at least a thousand of running copies. I was attempting to install
it on GoDaddy's shared Linux hosting service which runs Tomcat 5.0.27.

Reading the documentation on their site, it looked like all I had to do
was upload the WAR file and wait until 1:00 AM Arizona time and the
application should be deployed. I did this and waited. The next day, I
found the application had not deployed. A call to technical support
revealed that I had to go to a certain corner of the hosting control
panel and enable Java language support. I did that and waited until the
next day.

This is one of the problems with their shared hosting account. ANY
change takes until the next day to take effect.

The next day, I looked, and the WAR file had been exploded but my App
didn't work. Since my App has a dependency on the database, I uploaded a
simple JSP to test the DB Connection. It worked. Attempts to view the
error logs failed.

I called GoDaddy support. The technician told me I need to enable error
logging. He walked me through the control panel and I enabled error
logging. I waited until the next day.

The application still didn't work. When I tried to view the error logs,
I got nothing. Another call to technical support revealed that the error
logs I had enabled would not actually contain any Tomcat log data.

I had my call escalated to a manager. I explained to him the reason I
knew my application was not working. I told him the login page was not
available. His response was "Yeah, there's no file with that name." I
told him that the URL was a virtual mapping created in the web.xml file.
After literally an hour, they came back on-line and told me that they
were going to open a trouble-ticket and call me back.

Several hours later, I got an Email from support saying. "It doesn't
work because there's no file with that name."

At this point, I had a funny feeling. I created a simple WAR file with
one servlet and a web.xml deployment descriptor. The deployment
descriptor mapped three URLs to the servlet:

/MapTest.xyz
/MapTest.jsp
/MapTest.html

I waited until the next day. Sure enough, I could access MapTest.xyz,
and MapTest.jsp. Attempts to access MapTest.html generated a 404 Not
Found error. This explains why my application was not running. All my
servlets are mapped into URLs with extension of .html. This was a design
decision because customers generally want the maximum visibility to
search engines.

So, what I found is that GoDaddy.com does not pass all requests into the
servlet container. It attempts to service as many requests with Apache
first, and then only passes the non-mapped requests into Tomcat. There
are some 50 file extensions GoDaddy co-opts including .css, .xml, and .js.

This configuration actually causes their deployment of Tomcat to be
non-compliant with the Servlet API version 2.3 specification. Section
SRV.11.2.1 says that explicit mappings in the deployment descriptor must 
take precedence over implicit mappings. Taken as a SYSTEM, their
deployment of Apache Tomcat is non-compliant.

My feeling is that ANY request that maps to a deployed context must be
passed to the servlet container. Clearly, they are not doing that.

So, after all the effort, I get to tell the customer that my application
will not work on their hosting account. Rats.

In general, even if your application isn't using servlet mapping I can't
recommend them. Since it takes until the next day before you can
re-deploy a WAR file, and there are no Tomcat logs available, it would
be a really rotten experience.


-- 
George Sexton
MH Software, Inc.
Voice: +1 303 438 9585
URL:   http://www.mhsoftware.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message