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 <geor...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
