Note: This is a work in progress, please see the index page for more details.
The previous sections demonstrated the basic tools we are starting out with, now we are going to dig into the SpringFramework a little so we can actually see a little action.
First, let’s edit the pom.xml file to add a Spring dependency:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>2.5.1</version>
<type>jar</type>
</dependency>
</dependencies>
This will cause maven to dowload the spring Web MVC artifact and its dependencies (through the wonders of transitive dependencies).
Next we need to configure the Spring dispatcher servlet in the web.xml file. Upon opening the web.xml file you will (probably) find that maven created one for the Servlet 2.3 container; we want a 2.5 compliant container so you will need to replace the contents of the file with:
<web-app 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"
metadata-complete="true"
version="2.5">
</web-app>
and to this we will add our servlet definition and its mapping:
<servlet>
<servlet-name>dispatcher</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>dispatcher</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
This will route all *.do requests through the spring controllers. You can use pretty much any extension you want to use, *.do seems fairly common, while I often like to use *.act, for action, but ultimately it’s pretty much up to you.
Spring beans are defined in a Spring context file, which is an XML file that we will create in the WEB-INF/ctx/ directory as core-context.xml:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
</beans>
By default Spring MVC looks for a specific context file name, which we want to override with our own; this is done using a servlet initialization parameter:
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>WEB-INF/ctx/*-context.xml</param-value>
</init-param>
The wildcard character allows you to put other context files in the same directory and have them be picked up automatically by the dispatcher. This is handy so that you do not have to configure each one directly in the servlet configuration. This “-context.xml” naming style is also useful once you start having a handful of Spring context files, as it makes searching for beans very easy (you can limit your search to files with that name format).
Alight, let’s first focus on actually being able to do something with our spring context. The maven archetype did give us an index.jsp page in the web root directory, but since we want active pages to go through spring controllers we need to configure a Spring MVC view resolver, in our case the InternalResourceViewResolver, which handles JSP views.
In the spring context file add the following bean:
<bean class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="prefix" value="WEB-INF/jsp/" />
<property name="suffix" value=".jsp" />
</bean>
and create a jsp directory under the WEB-INF directory. Move the index.jsp file into this new directory. It is often considered a “best practice” to keep your “template” files under the WEB-INF directory so that they cannot be directly accessed via an external client. At this point we should also configure a built-in spring controller to route requests to the index.jsp page that we already have, as a way to test our configuration.
<bean name="/index.do" class="org.springframework.web.servlet.mvc.UrlFilenameViewController" />
This controller bean will take the file name and use it as the view name, which will be index; this name will be passed to the view resolver which will then search for WEB-INF/jsp/index.jsp which is our jsp file. Here it would be nice to test our web application with a rapid turn-around and little effort, the Jetty Maven Plug-in gives us that ability.
Open your pom.xml file and add the following code between the build tags:
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<contextPath>/${build.finalName}</contextPath>
<scanIntervalSeconds>10</scanIntervalSeconds>
<scanTargetPatterns>
<scanTargetPattern>
<directory>src/main/webapp</directory>
<includes>
<include>**/*.jsp</include>
<include>**/*-context.xml</include>
</includes>
</scanTargetPattern>
</scanTargetPatterns>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>8080</port>
<maxIdleTime>60000</maxIdleTime>
</connector>
</connectors>
</configuration>
</plugin>
</plugins>
This will configure an embedded Jetty instance to check the project for local updates and redeploy and restart as needed, scanning at 10 seconds intervals. I have also configured it to scan for changes in the jsp and context files, along with the default classes directory and web.xml file. Note, that this is one of the configuration areas that can lead to subtle errors as you add new file types, we will need to be aware that when new file types (or directories) are added that they still fit within this scanner configuration; if not, we will need to update the configuration to support the new files.
Okay, let’s do a little testing manual testing at this point. Build out the project and start the maven-embedded server to check your configuration to this point:
mvn package
mvn jetty:run
The package goal builds the project and creates the war file and the jetty:run goal runs the Jetty server. Point your browser to http://localhost:8080/helloworld/index.do (unless you changed the configured port). You should see the static Hello World message that came with our maven-generated jsp template. Don’t get too excited, though, it’s not the “Hello World” we want yet, not by far.
At this point you should submit your project to Subversion… go into some scm best practices as well as how to submit



