Home > Git, Maven, Open Lane, Spring, Spring Security, Spring Web Flow > Open Lane – Sunday Housekeeping

Open Lane – Sunday Housekeeping

Up to now I’ve been focused on get Open Lane up and running. Today I went back and made it more manageable. I don’t want to get too far down the road without being able to build it from a shell using Maven. Also I don’t want to keep committing Eclipse specific files to my version code system Git. I want to be able to:

  • Download the latest version from github.
  • Build a war package using Maven.
  • Deploy that package to a Tomcat server and bring up Open Lane in a browser.
  • Generate an Eclipse project using Maven.

There’s plenty of  good Maven and Git documentation on the Internet. So I won’t get into the details on how to much to technologies work. With that in mind, I will highlight a few things.

The Maven pom file that comes with Spring Web Flow’s booking-faces sample was a good place to start. It very vanilla and doesn’t invoke exotic or highly customized commands or dependenicies. It expects the source tree to follow Maven defaults such as src/main/java. The only significant change was to add my application id’s and fix some the version in some Spring dependencies that were sharing the version.

	<groupId>org.bwgz.swim.openlane</groupId>
	<artifactId>open-lane</artifactId>
	<name>Open Lane</name>
	<version>0.0.1.RELEASE</version>

This results in a pom file that can be found here. After modifying my source tree the new pom could generate a war file and Eclipse project.

Command Description
mvn package Creates a war file in the target directory.
mvn eclipse:eclipse Creates an Eclipse project.

When creating the Eclipse project I found that I needed to ensure I didn’t have any old Eclipse directories hanging around. If I did then things didn’t go well when running the project in Eclipse.

The generated Eclipse project also defaults to Java 1.5 and Web 2.5. I’d prefer it to Java 1.6 or event 1.7 and Web 3.0. Those changes will come later.

During all of this I found a bug in home-flow.xml. The problem was with the evaluation expression …

expression="userService.findUser(currentUser.name)" result="viewScope.user"

Spring Web Flow (SWF) sets currentUser only if a user has been authenticated. Starting up the application on a clean install meant that no one was authenticated and in turn currentUser was not initialized (null). That caused my home flow to blow up because I was attempting to access a member of a null object. I fixed this by changing the expression to …

expression="currentUser != null ? userService.findUser(currentUser.name) : null"

This bug still perplexes me a bit because with the old code, if I logged out the user, there wasn’t a problem. I was as if currentUser was an empty (vs. null) object.

Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: