Update Mar.04 Thanks to @ewolff some of the points described below are now official feature requests. One (SPR-6928) is actually scheduled in Spring 3.1 (cool!). I’ve updated the post and added all open tickets. Please vote!

This post is somewhat a response to InfoQ’s Comparison of Spring MVC and JAX-RS.
Recently I have completed a migration from a JAX-RS implementation of a web service to Spring 3.0 MVC annotation-based @Controllers. The aforementioned post on InfoQ was published a few days after my migration so I’m dumping below the list of problems I had, along with solutions.

Full list of issues:

• Same relative paths in multiple controllers not supported
• @ExceptionHandler is controller-centric
• Standard content negotiation can’t respond with a fixed response type
• JSR 303 bean validation not applied in @Controllers
• Formatting responses (i.e. Date) not working when using Spring formatter annotations

Same relative paths in multiple @Controllers not supported
Consider two Controllers where I use a versioned URL and a web.xml file that uses two URL mappings:

@Controller
public class AdminController {
   @RequestMapping("/v1/{userId}")
   public SomeResponse showUserDetails(String userId) {
      ...
   }
}

@Controller
public class UserController {
   @RequestMapping("/v1/{userId}")
   public SomeOtherResponse showUserStreamtring userId) {
      ...
   }
}
In web.xml:
	<servlet-mapping>
	  <servlet-name>public-api</servlet-name>
	  <url-pattern>/public</url-pattern>
	</servlet-mapping>
	<servlet-mapping>
	  <servlet-name>admin-api</servlet-name>
	  <url-pattern>/admin</url-pattern>
	</servlet-mapping>

Here I want to implement handling for /admin/v1/{userId} as well as /user/v1/{userId}. Each controller serves a different purpose (admin and public) and I want to keep the servlet application contexts separate for each servlet mapping (for instance add authentication and different view resolvers to all /admin/* URLs).
Deploying this configuration barfs the following exception:

java.lang.IllegalStateException: Cannot map handler [UserController] to URL path
[/v1/{userId}]: There is already handler [com.test.controller. UserController@6b177115]
mapped.

I would like Spring MVC to account for web.xml servlet mappings before deciding that two identical @RequestMappings in different controllers refer to the same URI. My solution was to have all @RequestMappings specifying the full path and resorting to a custom view to work around this issue).

@ExceptionHandler is controller-centric
RESTful web services respond with the usual HTTP responses (200s, 400s, 500s, etc.). These responses are being mapped from application exceptions and it only makes sense to specify the same @ExceptionHandler for all @Controllers since most (if not all) exceptions handled by them are for the same business domain. Currently SpringMVC only supports declaring and @ExceptionHander per controller and not globally per webapp. This forces the implementors to extend their @Controller classes from a common one where the @ExceptionHandler is specified or, to use composition and delegate exception handling to one service which leads to duplication. Both are ugly. There are several ways to deal with exceptions (check SPR-5622; please guys, add this to the main Spring documentation) but ideally I’d like to see a global scoped handler like @ExceptionHandler(scope=APPLICATION) where I can remap once framework exceptions to more suitable ones that translate into proper error codes (like working around SPR-5622 like issues).

Standard content negotiation can’t respond with a fixed response type (SPR-6937)
Here’s a simple requirement: Implement an RSS feed that serves a user’s activity stream.
Here’s another requirement (make that best practice):

Service methods should have as arguments primitives, wrappers or other POJOs and
 respond with void, primitives, wrappers or other POJOs.

I want testability, readability and portability for service classes and using framework objects for arguments/return objects adds unacceptable clutter.
As such, no framework objects are allowed as arguments or return types in a @Controller and in this case I don’t want to work with ModelAndViews just to be able to select the desired View.
Since this new requirement (add RSS view) belongs to the user domain, I want to add a method in the UserController class that returns a POJO which should be always unmarshalled into RSS regardless of request content type (there goes ContentNegotiationViewResolver). The same controller has other methods returning POJO view objects that I want marshalled into JSON or plain text response body and an HTTP response status. This is already available in RESTEasy via the elegant Produces annotation. The same RESTful controller should respond with different response types for different requests since I want to keep its domain centered around the user (and not response types).

...
public class UserController {
...
   @RequestHandler("/rss/{userId}")
   public SomePOJO getRssFeed(String userId) {
      ...
      //returns a POJO that should always be resolved by an RSS view
   }

   @RequestMapping("/activity/{userId}")
   public SomeOtherPOJO showUserStream(String userId) {
      ...
      //return POJO that should always be resolved by a JSON view
   }
...
}

It turns out this is not immediately possible. To my knowledge none of the included view resolvers provide a straight mapping between URLs and views so I had to write one that configures like this:

<bean class="UrlToViewViewResolver">
   <map name="urlToViewMap">
      <property key="/user/rss/*" value="rssView"/>
      <property key="/user/activity/*" value="jsonView"/>
      ...
   </map>
</bean>

The implementation (not included) is trivial and based on AntPathMatcher, a utility class readily available in Spring.

JSR 303 bean validation not applied in @Controllers (SPR-6928, scheduled for 3.1)
On Springsource’s weblog there’s a nice tutorial on how to get validation and type conversion in Spring 3.0 here. When it comes to validation though, Spring only supports it “after binding user input to it”. It is not possible to validate arguments and return types for a RESTful controller (no web forms or user input of any kind there). This means this won’t work out of the box:

   @RequestHandler("/admin/", method = RequestMethod.PUT )
   public void updateUser(@Valid User user) {
      ...
      //returns a POJO that should always be resolved by an RSS view
   }

since in a RESTful scenario the User object won’t be bound from a form but unmarshalled from XML/JSON/CSV or any other wire format.
To enable validation for a RESTful controller I chose to use @Valid at the method level and add an around advice that intercepts all methods annotated as such then use a Validator to validate arguments and return objects.

<aop:config proxy-target-class="true">
	<aop:pointcut id="validatableMethodExecution"
        expression="execution(* com.mycorp..*.*(..)) and @annotation(javax.validation.Valid)"/>

	<aop:aspect id="validateArgumentsAndReturnObject" ref="validatorAspect">
		<aop:around pointcut-ref="validatableMethodExecution" method="validate"/>
	</aop:aspect>
</aop:config>

public class ModelValidatorAspect {
	@Autowired
	private Validator validator;

    public Object validate(ProceedingJoinPoint pjp) throws Throwable {
        Set<ConstraintViolation> violations =new HashSet<ConstraintViolation>();
        for(Object obj : pjp.getArgs()) {
            if(obj != null) {
                violations.addAll(validator.validate(obj));
            }
        }
        if(!violations.isEmpty()) {
            throw new BadRequestException(composeErrorMessage(violations));
        }

        Object ret = pjp.proceed();

        //validate return object and throw exception if the validation fails.
        if(ret != null) {
            violations = validator.validate(ret);
        }
        if(!violations.isEmpty()) {
            throw new BusinessValidationException(violationsStr);
        }
   }
}

This could get more complex if you have deal with collections of validatable objects but it’s not hard to enhance the code to handle that.

Formatting responses (i.e. Date) not working using Spring formatter annotations
Spring comes with some niceties like @DateTimeFormat and @NumberFormat and naturally I want to rely on them by annotating the class attributes of return types used by @Controllers.
That’s not quite working since the formatters work with form-backed model objects. However, if you use a MappingJacksonJsonView there is a way of formatting using Jackson’s own @JsonSerialize.

Although at times it felt that the switch to SpringMVC was too much, the features that come with it (like abstracting web-related properties as annotations) will turn your RESTful controllers into annotated POJOs focused on the business domain which ultimately means maintainable code.

Update Mar.04 I left out several points about JSON marshalling that didn’t work as expected (Jackson marshaller is a handful).
- One enhancement I suggested to ease the pain of configuring JSON marshalling is creating a namespace similar to oxm (SPR-6943)
- The second was to add Jetisson support (SPR-6938) as an alternative to Jackson JSON marshaller.

I’m keen on your feedback regarding these issues so if you have better solutions please comment.

I want to write testable code and occasionally I bump into frameworks that make it challenging to unit test. Ideally I want to inject a service stub into my code then control the stub’s behavior based on my testing needs.
Commons Http Client from Jakarta facilitates integration with HTTP services but how to easily unit test code that depends on the HttpClient library? Turns out it’s not that hard.
I’ll cover both 1.3 and the newer 1.4 versions of the library since the older v1.3 is still widely used.
Here’s some typical service (HttpClient v1.3) we want to test. It returns the remote HTML page title:

public class RemoteHttpService {
   private HttpClient client;

   public String getPageTitle(String uri)  throws IOException {
     String contentHtml = fetchContent(uri);
     Pattern p = Pattern.compile("<title>(.*)</title>");
     Matcher m = p.matcher(contentHtml);
     if(m.find()) {
        return m.group(1);
     }
     return null;
   }

   private String fetchContent(String uri)  throws IOException {
      HttpMethod method = new GetMethod("http://blog.newsplore.com/" + uri);
      int responseStatus = client.executeMethod(method);
      if(responseStatus != 200) {
        throw new IllegalStateException("Expected HTTP response status 200 " +
"but instead got [" + responseStatus + "]");
      }
      byte[] responseBody = method.getResponseBody();
      return new String(responseBody, "UTF-8");
   }

   public void setHttpClient(HttpClient client) {
      this.client = client;
   }
}

with the HttpClient is injected at runtime (via some IoC container or explicitly).
To be able to unit-test this code we have to come-up with a stubbed version of the HttpClient and emulate the GET method.

What we really want is to be able to control the byte array returned by method.getResponseBody() and although we can inject a mocked HttpClient, the actual class that is responsible for producing the response body is GetMethod which is instantiated (and completely encapsulated) in the method body so we can’t inject a stubbed GetMethod version directly.
The solution is to create a simple HttpClient mock that is able to control the response status and response body. Here it is:

package org.apache.commons.httpclient;

import org.apache.commons.httpclient.*;

public class HttpClientMock extends HttpClient {
   private int expectedResponseStatus;
   private String expectedResponseBody;
   public HttpClientMock (int responseStatus, String responseBody) {
      this.expectedResponseStatus = responseStatus;
      this.expectedResponseBody = responseBody;
   }
   @Override
   public int executeMethod(HttpMethod method) {
      ((HttpMethodBase)method).setResponseStream(
new ByteArrayInputStream(expectedResponseBody.getBytes("UTF-8")));
      return expectedResponseStatus;
   }
}

There are two things to notice: Firstly, I placed HttpClientMock in the org.apache.commons.httpclient package to be able to have access to the protected member HttpMethodBase:setResponseStream. Secondly, I downcasted HttpMethod to HttpMethodBase to get access to setResponseStream (it’s safe since all concrete HttpMethods (GetMethod, PostMethod, etc) inherit from it).

Now I can unit test RemoteHttpService like this:

public class RemoteHttpServiceTest {
   private RemoteHttpService remoteHttpService = new RemoteHttpService();

   @Test
   public void extractTitleResponseOK()  throws IOException {
      String pageTitle = "A Title";
      String responseBody = "<title>" + pageTitle + "</title>";
      HttpClientMock mockHttpClient = new HttpClientMock(200, responseBody);
      remoteHttpService.setHttpClient(mockHttpClient);
      String resultedPageTitle = remoteHttpService.getPageTitle(""); //home page
      Assert.assertTrue(pageTitle.equals(resultedPageTitle));
   }
}

I can also add a negative test:

   @Test(expected = IllegalStateException.class)
   public void respondsWithInternalServerError()  throws IOException {
      HttpClientMock mockHttpClient = new HttpClientMock(500, "");
      remoteHttpService.setHttpClient(mockHttpClient);
      remoteHttpService.getPageTitle("");
   }

For HttpClient version 4.x here’s the refactored service code :

   private String fetchContent(String uri) {
        HttpGet httpget = new HttpGet("http://blog.newsplore.com/" + uri);
        HttpResponse response = client.execute(httpget);
        int responseStatus = response.getStatusLine().getStatusCode();
        if(responseStatus != 200) {
           throw new IllegalStateException("Expected HTTP response status 200 " +
"but instead got [" + responseStatus + "]");
        }
        InputStream responseStream = response.getEntity().getContent();
        byte[] responseBytes = IOUtils.toByteArray(responseStream);
        return new String(responseBytes, "UTF-8");
   }

Turns out that implementing a HttpClient mock by extending the DefaultHttpClient (the provided implementation of HttpClient) is not easy. The method I want to override is public HttpResponse execute(HttpUriRequest request) which is marked ‘final’ and the code in DefaultHttpClient looks just too complex to inject stubbed behavior.
What we actually want is to be able to control the return of the aforementioned ‘execute’ method since it encapsulates the response status and body (better encapsulation than HttpClient 1.3 if you noticed).
Luckily in this case we can use a readily available mocking framework, Mockito that can stub this entire method and return an HttpResponse that we instantiate with the needed status and response body. Here’s how to rewrite the tests using it:

@Test
public void extractTitleResponseOK() throws IOException {
	String pageTitle = "A Title";
	String responseBody = "";
	HttpResponse response = prepareResponse(200, responseBody);
	HttpClient mockHttpClient = Mockito.mock(HttpClient.class);
	Mockito.when(mockHttpClient.execute(Mockito.any(HttpUriRequest.class)))
			.thenReturn(response);

	remoteHttpService.setHttpClient(mockHttpClient);
	String resultedPageTitle = remoteHttpService.getPageTitle(""); // home page
	Assert.assertTrue(pageTitle.equals(resultedPageTitle));
}

@Test(expected = IllegalStateException.class)
public void respondsWithInternalServerError() throws IOException {
	HttpClient mockHttpClient = Mockito.mock(HttpClient.class);
	HttpResponse response = prepareResponse(500, "");
	Mockito.when(mockHttpClient.execute(Mockito.any(HttpUriRequest.class)))
			.thenReturn(response);
	remoteHttpService.setHttpClient(mockHttpClient);
	remoteHttpService.getPageTitle("");
}

private HttpResponse prepareResponse(int expectedResponseStatus,
               String expectedResponseBody) {
      HttpResponse response = new BasicHttpResponse(new BasicStatusLine(
    		  new ProtocolVersion("HTTP", 1, 1), expectedResponseStatus, ""));
      response.setStatusCode(expectedResponseStatus);
      try {
		response.setEntity(new StringEntity(expectedResponseBody));
	} catch (UnsupportedEncodingException e) {
		throw new IllegalArgumentException(e);
	}
	return response;
}

The meat of the above code is

HttpClient mockHttpClient = Mockito.mock(HttpClient.class);
HttpResponse response = prepareResponse(...);
Mockito.when(mockHttpClient.execute(Mockito.any(HttpUriRequest.class)))
	.thenReturn(response);

that instructs the mocked HttpClient to return a HttpResponse that is instantiated in the test context (seeded if you like) when ‘execute’ is called (check Mockito documentation for more details on the syntax).

That’s it. Happy testing.

Level 2 cache is one of the most powerful features of the JPA spec. It’s a transparent layer that manages out-of-session data access and cranks-up the performance of the data access tier. To my knowledge it has been first seen in Hibernate and was later adopted by the then-emerging JPA spec (driven mostly by the Hibernate guys back in the day).
As annotations gained strength and adoption, L2 caching that was initially configured through XML or properties files, was brought closer to the source code, alas in different forms and shapes. This becomes apparent if you ever have to deploy your webapp across a multitude of containers as you have to painfully recode the cache configuration (or worse, hand-coded cache access). Why not standardizing the cache control in JPA? This seems to be simple enough to achieve and yet it isn’t there. Now that JPA 2.0 is standardizing on Level 2 cache access (See JSR 317 section 6.10) it is the natural thing to do.
Every JPA provider has its own way of specifying cache access (both Entity and query cache).
To grasp the extent of the various ways cache is configured, here are some examples:

Hibernate:
Cache control for entities

@Entity
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Employee {...

Cache control for named queries:

@javax.persistence.NamedQuery(name="findEmployeesInDept",
query="select emp from Employee emp where emp.department = ?1",
hints={@QueryHint(name="org.hibernate.cacheable",value="true")})

or

@org.hibernate.annotations.NamedQuery(cacheable=true, cacheRegion="employeeRegion")

OpenJPA
Cache control for entities

@Entity
@org.apache.openjpa.persistence.DataCache(timeout=10000)
public class Employee {...

Query cache requires hand coded cache access:

OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf);
QueryResultCache qcache = oemf.getQueryResultCache();

EclipseLink
Cache control for entities

@Entity
@org.eclipse.persistence.annotations.Cache(expiry=10000,
    type=org.eclipse.persistence.annotations.CacheType.FULL)
public class Employee {...

Query cache is hand coded (example from here):

ReadObjectQuery query = new ReadObjectQuery(Employee.class);

// Instruct the ReadQuery to cache its query results
query.cacheQueryResults();

// The first time you invoke it, the ReadQuery reads from the database, session
// cache, or both and stores the result set in its internal query cache
Employee employeeFirst = (Employee) session.executeQuery(query);

Another JPA provider, DataNucleus is used by Google AppEngine for Java and they have thir own way of defining the cache access.
Entity cache control in DataNucleus:

@javax.jdo.annotations.Extension(vendorName="datanucleus", key="cacheable", value="false")
@Entity
public class Employee {...

Query caching is again manual:

query.setHint("datanucleus.query.resultCacheType", "weak");

Looking at the above examples it looks to me that caching was an afterthought for most of the JPA providers. Let’s remember that the cache should be transparent and pluggable and the value that a cache provider delivers stays in performance and not in configuration.
JPA cache configuration is in need of standardization and in my opinion the closest to a standard is (again) Hibernate.

A great addition to the JPA2 spec is the introduction of @Cacheable that controls entity caching but there’s still no standard on how to control query caching.
Here are some enhancements that I’m proposing:

1. An enhancement to @NamedQuery and @NamedNativeQuery to allow explicit cache enablement through a boolean attribute called cacheable, the same way @org.hibernate.annotations.NamedQuery is defined.

@NamedQuery(name="findEmployeesInDept", query="...", cacheable=true)
...
@Entity
public class Employee {...

2. Both @javax.persistence.Cacheable and @NamedQuery to support optional attributes: timeout (in sec.) and a cacheRegion attribute that in turn, will point to a cache policy where a more complex configuration can be used (to add the cache concurrency strategy and eviction policy for instance).

@NamedQuery(name="findEmployeesInDepartment", query="...",
   cacheRegion="DepartmentEmployeesCacheRegion")
@Entity
@javax.persistence.Cacheable(cacheRegion="EmployeeCacheRegion")
public class Employee {...

Cache regions can be configured through a new annotation, @java.persistence.annotation.CacheRegion.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Cacheable {
    boolean value() default true;
    int timeout();
    String cacheRegion();  //takes precedence if used
}

package java.persistence.annotation;
@Target({TYPE, PACKAGE}) @Retention(RUNTIME)
public @interface CacheRegion {
    int timeout();   //i.e. 300 s
    javax.cache.EvictionStrategy evictionStrategy(); //EvictionPolicy.LRU, FIFO, etc
    String name();  //region name
    ConcurrencyStrategy concurrencyStrategy();
    String hints();  //vendor extensions
}

If specified, a @CacheRegion exists either in-place along with the entity definition or separately through a new annotation @java.persistence.annotation.CacheRegions:

package java.persistence.annotation;
@Target({TYPE, PACKAGE}) @Retention(RUNTIME)
public @interface CacheRegions {
	CacheRegion[] value();
}

example:
@CacheRegions ({
  CacheRegion(name="EmployeeCacheRegion", timeout=300, evictionPolicy=
EvictionStrategy.LRU, ConcurrencyStrategy.TRANSACTIONAL),
  CacheRegion(name="OfficeLocationsCacheRegion", timeout=-1, evictionPolicy=
EvictionStrategy.LRU, ConcurrencyStrategy.READ_ONLY),
})
public class OrganizationStructureDAO {...

4. Sensible and well-defined defaults if some of the values are nor specified: default timeout, default eviction policy and default concurrency.

Vendor extensions of cache configurations will still be able to be deployed through the hints attribute both for @NamedQuery and @CacheRegion.

In the end, configuring the cache should be executed the same way across containers given that the cache providers that will be used will likely be the same. At least that’s what I’m hoping to see in JPA 2.0.

Selecting a web hosting provider is a tough job for any web developer that wants to put a Java/JEE web application online. The choice is much simpler when it comes to publishing a PHP web site and there are a load of cheap (and sometimes quite reliable) PHP hosting providers to choose from with LAMP being the de facto standard in the web hosting world. But when it comes to Java hosting providers the picture becomes blurrier. The common thing that all these environments need is a Java container. The most popular choice is Tomcat but there are providers that use Resin, Weblogic or Websphere (the latter two are full fledged JEE containers).
With the raise of lightweight J2EE servers started by the Spring folks, a little revolution began in the Java world: running enterprise-grade JEE webapps without the need for an EJB container; a servlet container is enough. Tomcat should fill the bill for just about any Java web application that doesn’t use EJBs. The advantage that comes from running a servlet container is the smaller footprint compared with an EJB container. This is critical when it comes to selecting hosting environments since you’re paying for resources (especially RAM) that have to be sized to accommodate the memory requirements of the web application.

Self hosting: Home-based dedicated server (near $0)

You can use your home internet connection and a PC where the web container runs and deploys your web application. There is an obvious advantage since the server is physically located close to the development team: complete control and physical access to the machine. The other big plus is the price: you’re already paying for the internet connection and chances are you already have a PC that can be transformed into a server. And chances are that you already have a development environment that can be the basis of the production deployment. Here are the shortcomings: - Bandwidth limitations: the webserver where the webapp lives will upload content to the web browsers that access the application. The upload bandwidth is smaller than the download bandwidth and will result in longer load times for web clients. - Some internet providers cap the internet traffic so you may run beyond the limit.

- You may violate contractual obligations you agreed with your Internet provider by running your own web server.
- The internet connection is not reliable: provider’s downtime directly translates in downtime for your webapp.

Managed hosting ($6 and up)
This is the cheapest solution but it poses the most restrictions. The main limitation is the inability to deploy webapps that depend on Java bytecode manipulation at runtime, mainly Hibernate and Spring. This is due to classloading security constraints that prevent the bytecode manipulation libraries (CGLIB or javassist) to perform runtime code enhancements.
Working with managed hosting environments poses more limitations:
- Deployment: some popular hosting providers deploy once a day: you drop the war file or the exploded war in a specific folder on the hosted environment and it will be deployed at a specific time picked by the provider (more here). If it fails, you have to wait another day till the app will be redeployed or pick a provider that supports instant drop&deploy.
- Debugging a failed deployment: I couldn’t make log4j write the log into a location on my hosted file space so I had to resort to a JDBC appender to actually see what causes a failed deployment. This required two deployments (one to try a location on the hosted folder and a second one to use the JDBC appender; that’s two days due to the deployment constraint detailed above) and the issue turned out to be the classloader security issue preventing CGLIB to change the bytecode. I have only tried to deploy a war file with Hibernate and Spring dependencies in Godaddy’s Java hosting environment (their Linux Deluxe plan) before I gave up on managed Java hosting.
- Sharing the environment with other webapps. Your app will be deployed along with other applications and compete for the same resources.
- Access to server logs and traffic stats is very limited. You can only use Google Analytics (or similar) but not Awstats (at least not for free).
- Outgoing traffic may be restricted or blocked.

Unmanaged hosting solutions
Unmanaged doesn’t necessarily mean that the hosting company doesn’t manage anything, they just leave the actual OS administration in your hands so you’ll have a physical server under your complete control, everything else from network management to hardware maintenance is done by the hosting company. You/your team has to have solid server administration knowledge: Linux, Apache, Java AppServers, software firewall (iptables), backup/restore, monitoring, security, patching, DNS and more. A web administrator inside your team usually takes care of all these details. After the machine is up and running you are free to install and run any Java container and deploy your application.
Below are the options when choosing to run a dedicated server.

Colocated server ($70 and up)

You can colocate the server which means that you buy then ship your own rack-mountable server to a data centre where it will be installed by on-site technicians. The monthly fee you’ll pay starts at around $70 (prices are per one unit which is a slot in the rack) and includes the rack space rental, network connectivity, location security, 24/7 power (not counting mishaps), etc. Denial of Service prevention services are usually provided as part of the package. There is complete freedom in terms of the deployment environment since you own it. However, there are two problems that come with this solution:

- Initial cost associated with buying rack-mountable servers that usually start from $1.5k (check SuperMicro, they’re good). These machines contain redundant components to cope with failures.
- Maintenance: When components break you have to manage their replacement. If the whole machine crashes then your website will be offline until the machine is replaced.

Rent a dedicated server ($100 and up)

Instead of buying your own server, you can choose to rent a dedicated server from the hosting provider. Kevin Rose unveils how digg.com was initially hosted on dedicated servers rented from Ev1Servers.net (see full article). The benefit of this solution is the lower initial cost compared to colocation, beginning at around $100/month and of course the complete control over the environment. The drawbacks are the same as colocation except for servicing the box that falls under the hosting provider’s responsibility.

Virtual Private Server ($20 and up)

A VPS ” is a method of partitioning a physical server computer into multiple servers”. Each of these partitions behaves like a full fledged server, has an IP address and can be reachable from the internet. The computers that are VPS partitioned, sit on the hosting provider’s infrastructure. The provider is responsible for network connectivity, bandwidth and continuity of service in case of physical server failure. There are two main VPS software providers: Virtuozzo and Xen. Of the two, I recommend Xen-based VPS providers since the virtualized machines cannot be oversold and thus you’ll get consistent performance for the money (a detailed explanation here). The main benefit of the VPS is the excellent price/performance ratio starting as low as $20/month. Another big advantage is the ability to “resize” the virtual partition on demand in a matter of minutes (you’ll pay more of course), add more virtual machines to your deployment () as well as “relocating” it to a different data center

if the provider has multiple locations (West Coast and East Coast for instance). Root access is also provided. The drawbacks are:
- the operating systems that you can run are controlled by the hosting provider and usually are Linux distributions (here’s an example). However, the choices are very popular Linux distros.
- you have to have server administration expertise.
I run this blog, spincloud.com and the rest of my web properties on a VPS. I use the excellent Linode after I had switched from Slicehost, having performance issues. I am quite happy with Linode, their service rocks and they’ve been delivering consistent performance since day one.

Cloud services (EC2: $100 and up)

Cloud computing is today’s trend. The company that kick-started the trend was Amazon with their Elastic Computing Cloud. EC2 is actually an advanced form of VPS: you can run your own virtual machine image (or AMI) or pick one from the existing stock. After the AMI is booted and configured, you have the liberty of installing any Java environment. You get root access too. From the high profile websites, Smugmug uses EC2 and S3 and they save money doing so. In fact Smugmug was one of the early adopters of Amazon’s cloud services.

Drawbacks:
- If you reboot the machine or if it simply crashes then all data is lost, including any database records you happen to have. This was a real problem for developers until Amazon added the possibility to mount a persistent S3 volume in an EC2 instance. S3 stands for Simple Storage Service and is Amazon’s offering for cloud-based storage.
- You have to learn new terminology and set of skills that are applicable to Amazon’s problem-set only. You’ll also tie the solution to a single vendor.
The cost for an EC2+S3 starts at close to $100/month.
If you’re thinking of using the dirt-cheap (starts free) Google AppEngine for deploying a Java application you’re out of luck, they only support Python. Update: Google has added Java support to Appengine. at the begining of April. I have a dev account and I’ll evaluate it in a separate post.

Common concerns when selecting a hosting provider
Price
Don’t pick a service just because it’s cheap. Perform some due diligence on the company, where their data centers are located and how good their service is. You don’t want your website hosted on the wrong side of the world. Monitor WebHostingTalk forums; hosting providers often run promotions there.
Look for monthly plans and don’t commit to yearly plans since you may end-up being unhappy with the provider and with no choice to get out of the contract.
Be suspicious when you see associated setup fees coming with setting-up an account. They are not refundable and good hosting providers simply don’t have them.

Uptime
You want no interruption in service for your web servers so uptime is a must. You can’t afford to have downtime since it translates directly into lost customers and ultimately lost business. Look for hosting providers that offer SLAs (Service level agreements) and have proven reliability. Netcraft is a neat tool that measures the reliability of hosting providers on a monthly basis. Look for the providers that guarantee five nines (99.999%) uptime, that is five minutes a year.

Technical support
My personal experience is that I used the tech support while I was using a shared web hosting. I haven’t used any after moving to the VPS.

Transfer volume
Perform some basic calculations for the required traffic based on the expected traffic and data volume sent out. Providers bundle 200GB/month or more in their offerings these days. This should be enough for most of the cases. Make sure your website doesn’t get cut-off if your traffic spikes and/or you’re not paying a ridiculous amount of money per GB if you go beyond your quota.

Security
All hosting providers offer a form of protection against DDOS but you are responsible for the software that runs on the server. I got the online forum I was running for Newsplorer hacked a couple of years ago because I didn’t upgrade the forum software to patch a security vulnerability that was promptly exploited.

Backup
Hosting providers offer backups or you can do it yourself with a bit of effort and some cron knowledge. Save the backed-up files on a different location (I use S3 for my backup needs but there are free solutions too).

I’ve considered myself a Java guy (that’s before I recently started with Ruby). I’ve stumbled upon Java in 1998 and fell in love with it at first sight. I remember quite crisply my first encounter of the third kind with Hello World. But I confess, I only learned about java.lang.Void yesterday. I was digging through the SwingWorker concepts and as I went through the tutorial I was intrigued by a mention about the Void type in the Simple Background Tasks section.

I already experimented with the SwingWorker before reading the tutorial and liked it except for the annoying return and interim results types as I’m migrating an ancient Java 1.1.8 GUI to JDK 6 at work and those Runnable classes I’m thinking of converting to don’t have any return types.

In short, java.lang.Void is a class representing the void type (non-instantiable, mind you). I should have known, all primitives have class.<primitive> representations and the reflection mechanism should have a representation of void too. Well, I didn’t.

The nice thing about this little-known-to-me class is that it fits like the proverbial Cinderellian shoe straight into the generics of SwingWorker (and elsewhere now that I know about it). From the example:

SwingWorker worker = new SwingWorker<ImageIcon[], Void>();

In other words, if you don’t have a return type for your SwingWorker::done() method just slap a java.lang.Void and you’re saved.
[Copyrighted image courtesy of toulcophoto]