Note: This tutorial is gonna show you how to code Java without any of the traditional B.S., like XML and app server restarts. It’s split into 3 parts so that your brain doesn’t freak out at a 50 meter long webpage. Enjoy!

Part 1 | Part 2 | Part 3

———————————-
Did you realize that Hibernate has been around for more than 10 years? And Spring will begin its second decade next year? There was a time when Spring+Hibernate was widely considered an unofficial industry standard, but today is portrayed as an ancient beast whose XML appetite kills little rainbow scroll wheels. That assessment is not true, however. Both technologies have seen continuous development and are still competitive today.

Doesn’t it make more sense to compare apples to apples? For example, don’t put JEE6 with CDI up against Spring 1.0. Spring and Hibernate don’t require three miles of XML anymore. In fact, it’s possible to set them both up with zero lines of XML.

With servlet 3.0, even web.xml can go the way of the dodo. When all you’re trying to accomplish is a simple helloWorld guestbook, then Java, Spring and Hibernate will require more effort to get there, but can you name any app which is that trivial in real life? Proper applications are expected to satisfy far greater needs, both functional and non-functional, which is the area where Java, supported by wisely-chosen tools & frameworks, really shines.

Why don’t we name some qualities of a modern web application? Let’s think about what we would like to see as the result, and work back from there. The app should:

• Be simple and easy to set up, rivalling pure JEE6, Play! Framework, or ***-on-rails
• Remain simple and easy when complexity gets beyond what is usually shown in tutorials
• Be easy to run and test on a developer machine as well as on remote servers
• Maximize developer productivity
• Be flexible and robust enough to support a wide array of enterprise requirements (which will be completely different after your boss gets back from the lunch break)
• Have a huge community and know-how behind it
• Keep away from magic and be easy to debug

Java apps are never just about pure Java. It takes a combination of Java, frameworks and tools to get the most out of the platform.

The lineup

For this task, my arsenal includes the latest versions of Spring Framework 3.1 and Hibernate 4.1. I’m also using a tiny bit of BeanValidation to make the code sparkling. In addition to the frameworks, I have chosen some tools for developing the beast. One of the biggest benefits to productivity is having a Maven project which can be launched from within your IDE and updated on the fly with JRebel (Disclaimer: I joined ZeroTurnaround to work on the JRebel team in 2010).

Maven 3

I’m creating a maven project which can be built and deployed with one command on the remote server. On the developer side, it removes all the hassle of managing dependencies and troubleshooting errors when some library is missing.

http://maven.apache.org/download.html

Eclipse 3.7

I am personally used to Eclipse and will be using it in the article. Feel free to use IntelliJ IDEA or NetBeans instead. The important part is having the proper plugins that play well with Maven and JRebel. For Eclipse, these plugins are:

• Maven integration (m2e)
• Maven integration for WTP
• JRebel for Eclipse

Maven Integration for WTP is a separate plugin from m2e and is essential for launching a maven project in a container from within Eclipse. You can install all of them from the Eclipse Marketplace.

http://www.eclipse.org/downloads/

JRebel 5.0

JRebel allows you to see all sorts of changes to Java code in your app instantly, and it includes changes to Spring bean definitions and Hibernate mappings. It removes what is perhaps the biggest weakness of Java when compared to Grails, PHP or the like – downtime during the build/compile/restart phases. Plus you get to keep all what’s great about Java.

JRebel Remoting, new to JRebel 5.0, allows you to upload changes to a remote machine and have the changes instantly reflected there too. It works with Jelastic, Rackspace and Amazon EC2 out of the box.

http://zeroturnaround.com/jrebel/current/
http://zeroturnaround.com/software/jrebel/remoting

Tomcat 7

IMHO, the app server you choose is probably the least important decision. Stick to what you feel most comfortable with. However, it should be as lightweight as possible. In the past it meant using only a servlet container instead of a full blown JEE server, but today there are several JEE Web Profile offerings which also start up pretty quickly.

I prefer Tomcat, but this can freely be substituted with alternatives (such as Jetty 8, JBoss 7 or Glassfish 3.1, which are all free and start up reasonably fast). Use any of those if you dislike Tomcat.

http://tomcat.apache.org

Creating the Project

I like to start by creating a blank Dynamic Web Project in Eclipse. I select “None” as a target runtime, “3.0“ as the module version and “minimal” under “Configuration”. That should result in a minimum possible setup for a servlet 3.0 application. Next I add Maven support to it. To do that, right-click on the newly created project and select Configure->Convert to Maven Project. Sometimes that messes up the Eclipse build and source directories. Make sure the src dirs of the project are src/main/java and src/main/resources, creating the folders when needed, and output dir should be target/classes.

Next you need to add a bunch of dependencies, like Spring and Hibernate, as well as Servlet API and a few more. Configuring the POM is the most boilerplate’ish part of the whole process, but it can actually be accomplished via GUI in Eclipse. Adding dependencies is easy. The biggest problem of Maven is that it’s nontrivial to make adjustments to the build process (such as changing the default Java version). In the end, I end up with the following POM. I have annotated the file with comments as to why one or the other bit of configuration is necessary.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <!--replace with your namespace and version -->
  <groupId>com.zt</groupId>
  <artifactId>helloWeb</artifactId>
  <version>0.0.1-SNAPSHOT</version>

  <!--should not be changed -->
  <packaging>war</packaging>

  <!--some custom options are necessary. Perhaps they make their way to a convention in the future -->
  <build>
    <plugins>

      <!--source level should be 1.6 (which is not Maven default) for java EE 6 projects, so let's change it -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>

      <!-- When using xml-less approach, you need to disable Maven's warning about missing web.xml -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <failOnMissingWebXml>false</failOnMissingWebXml>
        </configuration>
      </plugin>

    </plugins>
  </build>

  <dependencies>

    <!--We need servlet API for compiling the classes. Not needed in runtime -->
    <dependency>
      <groupId>javax.servlet</groupId>
      <artifactId>javax.servlet-api</artifactId>
      <version>3.0.1</version>
      <scope>provided</scope>
    </dependency>

    <!--adding spring mvc is easy -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-webmvc</artifactId>
      <version>3.1.1.RELEASE</version>
    </dependency>

    <!-- Required for xml-less configuration of Spring via @Configuration annotations -->
    <dependency>
      <groupId>cglib</groupId>
      <artifactId>cglib-nodep</artifactId>
      <version>2.2.2</version>
    </dependency>

    <!-- required for getting spring working with Hibernate -->
    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-orm</artifactId>
      <version>3.1.1.RELEASE</version>
    </dependency>

    <!-- Adding Hibernate -->
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-core</artifactId>
      <version>4.1.2</version>
    </dependency>

    <!-- Only needed when using JPA instead of "pure Hibernate" -->
    <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate-entitymanager</artifactId>
      <version>4.1.2</version>
    </dependency>

    <!-- DB connection pooling for production applications -->
    <dependency>
      <groupId>commons-dbcp</groupId>
      <artifactId>commons-dbcp</artifactId>
      <version>1.4</version>
    </dependency>

    <!-- replace with concrete JDBC driver depending on your DB -->
    <dependency>
      <groupId>mysql</groupId>
      <artifactId>mysql-connector-java</artifactId>
      <version>5.1.19</version>
    </dependency>

    <!-- Add Taglib support -->
    <dependency>
      <groupId>jstl</groupId>
      <artifactId>jstl</artifactId>
      <version>1.2</version>
      <!-- Use Provided when using JBoss or Glassfish, since they already bundle it. I'm using Tomcat so it has to go in -->
      <!-- <scope>provided</scope> -->
    </dependency>

  </dependencies>

</project>

All that’s left to do is changing the src directory to src/main/java and output folder to target/classes in Eclipse. You could also check whether paths are mapped correctly under Deployment Assembly. Note that you may have to refresh the project configuration after modifying the pom.xml. To do that, right click on the project and Maven->Update Dependencies.

Hello World, goodbye XML!

Servlet 3.0 introduces a ServletContainerInitializer interface whose implementing classes are notified by the container about webapp startup events. Spring 3.1 uses this in its WebApplicationInitializer interface, which is the hook through which you can set up ApplicationContext without using the web.xml. Combine that with Spring’s Java-based configuration, and you can successfully ditch XML files entirely.

First, you need to create a class that implements that Spring’s WebApplicationInitializer interface. Then create the application context programmatically and finally add the servlet to the ServletContext (again, programmatically). The resulting initializer class looks like this:

public class Initializer implements WebApplicationInitializer {
 
  // gets invoked automatically when application starts up
  public void onStartup(ServletContext servletContext) throws ServletException {
 
    // Create ApplicationContext. I'm using the
    // AnnotationConfigWebApplicationContext to avoid using beans xml files.
    AnnotationConfigWebApplicationContext ctx =
        new AnnotationConfigWebApplicationContext();
    ctx.register(WebappConfig.class);
 
    // Add the servlet mapping manually and make it initialize automatically
    Dynamic servlet =
        servletContext.addServlet("dispatcher", new DispatcherServlet(ctx));
    servlet.addMapping("/");
    servlet.setLoadOnStartup(1);
  }
 
}

The trick that helps us get rid of applicationContext.xml files is achieved by using AnnotationConfigWebApplicationContext instead of XmlWebApplicationContext. I put the configuration in the WebappConfig class, which is annotated with @Configuration. All that is available in XML files can be done here programmatically. For example, adding @ComponentScan("com.zt.helloWeb") turns on Spring’s scanning for annotated beans, akin to the previous <context:component-scan> directive. WebMVC is enabled via @EnableWebMvc and PropertyPlaceholderConfigurer is replaced with @PropertySource("classpath:filename.properties"). Beans are declared via adding @Bean annotation to a method that produces the object. The name of the method is not important. I’m using this to configure a ViewResolver (see below). The whole simple configuration class looks like this:

@Configuration
@ComponentScan("com.zt.helloWeb")
@EnableWebMvc
public class WebappConfig {
 
  @Bean
  public InternalResourceViewResolver setupViewResolver() {
    InternalResourceViewResolver resolver = new InternalResourceViewResolver();
    resolver.setPrefix("/WEB-INF/views/");
    resolver.setSuffix(".jsp");
 
    return resolver;
  }
 
}

All that’s left to do is adding a simple controller class, which maps to /hello and renders hello.jsp …

@Controller
public class FooController {
 
  @RequestMapping("/hello")
  public String helloWorld(Model model) {
    //let’s pass some variables to the view script
    model.addAttribute("wisdom", "Goodbye XML");
 
    return "hello"; // renders /WEB-INF/views/hello.jsp
  }
 
}

..and even smaller jsp file:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1"%>
<html>
    <head>
        <title>This goes to top</title>
    </head>
    <body>
        <h1>Hello World, ${wisdom}!</h1>
    </body>
</html>

The final application source contains just 4 files + pom.xml:

-- pom.xml
-- src
   -- main
      |-- java
      |   -- com
      |      -- zt
      |         -- helloWeb
      |            -- controllers
      |         	   -- FooController.java
      |         	-- init
      |         	   -- Initializer.java
      |         	   -- WebappConfig.java
      |-- webapp
          -- WEB-INF
       	  -- views
       		 -- hello.jsp

This app can be easily launched from Eclipse and also built on a remote server using Maven. Try it, it’s a fully functional HelloWorld webapp!

Even though it is possible to set up the webapp without any XML files, I leave it up to you decide how big of an improvement this actually is. It’s certainly not a silver bullet. Also, app containers’ support for the new options is still buggy. For example, the webxml-less approach does not work on JBoss correctly. It is buggy on the 7.1.1 version and fails completely on 7.0.2. You might also not be always able to use servlet 3.0 capable servers in production.

For me, the most offensive part of XML is having to include a crapload of namespaces in Spring’s applicationContext.xml. For example, I never create that file from scratch and copy-paste it instead:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:context="http://www.springframework.org/schema/context"
  xmlns:mvc="http://www.springframework.org/schema/mvc"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
    http://www.springframework.org/schema/mvc http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd" >

Web.xml is far less verbose however and works even on JBoss. In the above setup, the class Initializer can be replaced by the following web.xml (we’ll still be using Spring’s javaconfig, and for compatibility’s sake I reduced the servlet version to 2.5):

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

  <servlet>
    <servlet-name>mvc</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <!-- we'll use AnnotationConfigWebApplicationContext instead of the default XmlWebApplicationContext... -->
    <init-param>
      <param-name>contextClass</param-name>
      <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </init-param>

    <!-- ... and tell it which class contains the configuration -->
    <init-param>
      <param-name>contextConfigLocation</param-name>
      <param-value>com.zt.helloWeb.init.WebappConfig</param-value>
    </init-param>

    <load-on-startup>1</load-on-startup>

  </servlet>

  <servlet-mapping>
    <servlet-name>mvc</servlet-name>
    <url-pattern>/</url-pattern>
  </servlet-mapping>

  <welcome-file-list>
    <welcome-file>/</welcome-file>
  </welcome-file-list>

</web-app>

DefaultServletHandler

The caveat of mapping DispatcherServlet to “/” is that by default it breaks the ability to serve static resources like images and CSS files. To remedy this, I need to configure Spring MVC to enable defaultServletHandling.

To do that, my WebappConfig needs to extend WebMvcConfigurerAdapter and override the following method:

 @Override
  public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
    configurer.enable();
  }

Continue to Part 2

Arnel Pällo

Arnel Pällo is a Java engineer at ZeroTurnaround. He works on adding support for web-service frameworks into JRebel and is a major fanboy of pretty code. He plays Bioware games and hacks his Android phone on weekends. He also likes salsa dancing and can make a great Mojito. You can connect with Arnel on Facebook.

More Posts

• developers development hibernate JRebel Maven spring XML