OT: GoDaddy Hosting and Tomcat

[George Sexton <ge...@mhsoftware.com>]

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

Re: OT: GoDaddy Hosting and Tomcat

[Jonathan Mast <jh...@gmail.com>]

Well, you get what you pay for.  My GoDaddy account costs $6.99 per month
and I quickly found it inadequate for hosting serious Tomcat applications,
just for the reasons you listed: very unintuitive control panels, 1-day lag
in servlet (non)-deployment.

I'm canceling the hosting portion of my GoDaddy account as soon as I get my
old dell dimension 4600 ready for hosting my website :)

But the $0.99 per year .info domain name is a pretty sweet deal i think.

Basically, GoDaddy is a very affordable domain name retailer; their hosting
is a mickey mouse LAMP-shop. My 65 year old father has his website hosted on
GoDaddy, my dad isn't interested in enterprise-level web applications, he
just wants a website.  Thats what Godaddy's hosting is good for.

On Mon, Apr 27, 2009 at 10:44 AM, George Sexton <ge...@mhsoftware.com>wrote:

> 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
>
>