Earl Douglas

Setting the class path can be quite bothersome when you have many separate JAR files to deal with. An easy way to manage obese class paths is with download extensions. Through a list of JAR files in the MANIFEST.MF file within a given JAR file, you can automatically include an arbitrary number of JAR files on the class path.

Let's imagine we have the following two classes in our project:

JSR-330: Dependency Injection for Java defines a collection of annotations which are used to define dependencies and their providers and scopes within a compliant application or framework. It is immediately recognizable by developers familiar with Google Guice, but is less so to developers familiar with Spring. Nevertheless, Spring's analog to (and influence on) JSR-330 is presented in the similarities between the two (not to mention Rod Johnson's participation as a Specification Lead of the JSR-330 team).

Spring AOP provides a simple framework for wiring crosscutting concerns into applicable functionality without intrusion into the source code.

This example will walk through creating an aspect with a method logging advice, and wiring it to a sample service.

The service interface is Greeter, which defines a simple getGreeting() method. The service implementation, DefaultGreeter, simply returns the ubiquitous "Hello World!".

On a high level, Guice and Spring JavaConfig bring many of the same capabilities to the table. They both provide annotation-based dependency injection, they both boast simple APIs, and they both get you quickly up and running with an IoC container.

Spring JavaConfig mainly brings a new type of ApplicationContext into the picture, namely JavaConfigApplicationContext, along with various support infrastructure including new annotations such as @Bean, @Configuration, etc. Otherwise, it's still the same familiar Spring.

My second venture into Guice Land is an approach at integrating a Spring MVC web tier into a Guice application. My goal was to assume a Guice-only application tier which needed to be exposed via the web. I built on my previous Guice project to remove the limited Servlet and add a Spring MVC layer to achieve the same end.

Recall the service interface, Greeter, and the default implementation, DefaultGreeter.

For my first venture into Guice territory, I wanted to create an absurdly simple web application that both works and demonstrates an aspect of the dependency injection capabilities of Guice. The result is a single-servlet web application which uses a Guice Module to retrieve an implementation of an interface for use within a Servlet.

The interface and implementation, called Greeter and DefaultGreeter, define and realize a simple function called getGreeting() which returns the obligatory "Hello World!".

When building a new Spring MVC application, I often find it useful to start from a barebones Spring MVC application in which I have already gone through the motions of basic configuration and coding.

This simple example realizes a fully functional, albeit limited, Spring MVC application to serve as a springboard for more advanced Spring MVC applications. The goal is to present a simple form, harvest input from the user, process the input on the server, and present it back to the user.

First, the form backing class is defined:

Jetty makes for a very simple servlet container when testing or developing embedded web applications. It is quite capable and often satisfactory over alternatives such as JBoss or Tomcat. My favorite "feature" is that Jetty consists entirely of two JAR files, coming in at just under 700 KB.

The following code will set up a Jetty server with a basic HTTP connector open on port 8080. It prepares a single web application, located under the folder ./mywebapp, and exposes it on the context /mywebapp.

Dependency injection is one of my favorite design patterns, not only for what it is but for how it has turned my own thinking on its head. It has helped me approach engineering problems from a new perspective, modeling problems as discrete systems integration scenarios rather than monolithic or ad hoc bandaging strategies.

On occasion when running a series of tests, it is handy to have data about the average, standard deviation, minimum, and maximum run times of the series. I find this particularly useful when performing extensively parallel thread testing, and need to collect metrics for analysis.

These features would fit well in the org.springframework.util.StopWatch class, and could be implemented as follows: