What To Look From A Java Hosting Service Provider

Is it just me ? I see very few Java Hosting Providers compared to the ones with ASP and PHP. Agreed Java is the first choice in upscale environments, however being open and free, I thought I would bump into many cost friendly Java Hosting providers, but in vein. It seems Microsoft still rules in low end market. What should we look for from a Java Hosting Service Provider ? I have listed my priorities in descending order. Please comment. 1) Look at the file storage and band width requirement. 20 MB disk space is decent enough size to start with. Band Widths provided by most of the providers are within adequate level, so it is not a big issue. 2) Decide on the format of your web site URL. Eg. MySite.Provider.Com or Provider.com/MySite or MySite.com . It is infact not a big deal to move from one provider to another once your website traffic increases. Hence decide on the duration for which you sign up with the provider if you choose one of the first two forms of URL. First two forms are normally from Free Service Providers. 3) Free DB - MySQL / MS SQL or Oracle 4) Shared / Dedicated App Servers : Dedicated app server will give you more flexibility in updating the web site. 5) Statistics / Backup facility / Log file access - Statistical report help us to see how a website is improving on its usage. Backup will help us save data built up in the database. 6) File upload options : FTP / Web based 7) Free DNS support - Few Providers offer free domain registration that do not expire until you move away from that provider8) Multiple domain support - Many ASP.NET hosts provide directory mapping to support different web domains. An equilent in Java world will be a big add on for us to cut on $ spending. This will also help us in centralized website management. 9) PHP / Perl coverage - we can use any available modules this way even though integrating Java with these technologies (session management) is a challenge

Is it just me ? I see very few Java Hosting Providers compared to the ones with ASP and PHP. Agreed Java is the first choice in upscale environments, however being open and free, I thought I would bump into many cost friendly Java Hosting providers, but in vein. It seems Microsoft still rules in low end market. What should we look for from a Java Hosting Service Provider ? I have listed my priorities in descending order. Please comment.
<snip>

Having hammered on servlet containers in the test lab, I think the major reason you do not see low-end Java providers is that the footprint of a Java/Servlet (let alone EJB) environment is just too large. You can get into hundreds of MB of memory usage before loading a single site. You do not start to see the benefit of a Java-based system until you get into at least dozens of sites (which amortizes the startup and load cost), but the servlet containers do not necessarily scale that well, especially on the MS platform where occasional reboots are necessary to reset the network layer.

Another really big problem is library usage. If you have several dozen sites all using their own servlets and JSPs, how do you control what libraries are used? I am not talking about security here, that is actually handled quite well. Instead, I am talking about the fact that you cannot load several versions of the same JAR at once. If my servlet wants to use version 1.0.2 of the fancy jizmagizer library and yours wants (requires) 1.0.3 or later, we are out of luck. Whoever loads first wins. This is bad enough in enterprise environments where the entire application/library stack must be upgraded at once, but in a shared environment it is a show stopper. It is sad, because the shared environment is exactly where JSPs and co should shine.

Another advantage of the servlet container environment is that service providers should be able to move whole sites seemlessly from server to server and VM to VM, even across platforms. This should give them a flexibility in load balancing that rivals anythng out there. Some of the issues which make tis difficult are silly design choices, such as the fact that RMI stubs must through a RemoteException, but certain stream operations are not allowed to throw exceptions at all, so streams are not remotely controllable via RMI without very involved stubbing, making many operations which should be transparent anything but.