Bryan Saunders

Bryan Saunders A Tech Blog

Using SSL with Embedded Jetty

Setting up SSL in Java can be a bit tricky. Setting up SSL with a JAX-WS Endpoint is even trickier. I have spent the last few days figuring out how to get all of this to work, and I finally got it working, and wanted to post some working sample code here for future reference.

SSL using Embedded Jetty for a JAX-WS Endpoint

Before you code will run, you will need to properly generate or obtain server certificates. For steps to generate your own self-signed server certificates, read this post.

int port = 8443;
String connectInfo = "/yourServiceUrl";
final Server server = new Server(port);
ContextHandlerCollection collection = new ContextHandlerCollection();
server.setHandler(collection);
SslContextFactory sslContextFactory = new SslContextFactory("server_keystore.jks");
sslContextFactory.setKeyStorePassword("yourPass");
SslSocketConnector connector = new SslSocketConnector(sslContextFactory);
connector.setPort(port);
server.setConnectors(new Connector[] { connector });
this.endpoint = Endpoint.create(service);
JettyHttpServer jettyServer = new JettyHttpServer(server, true);
this.endpoint.publish(jettyServer.createContext(connectInfo));
server.start();

Mutual Authentication

If you need mutual authentication (Two-Way SSL) with your embedded Jetty server, you can use the steps in this post to generate all of your keys. You will also need to modify the above code by adding the following three lines of code, directly below the creation of the SslContextFactory.

sslContextFactory.setNeedClientAuth(true);
sslContextFactory.setTrustStore("server_truststore.jks");
sslContextFactory.setTrustStorePassword("yourPass");

Maven Dependencies

You will also need to add the following two dependencies to your Maven POM file for everything to work.

<dependency>
	<groupid>org.eclipse.jetty</groupid>
	<artifactid>jetty-server</artifactid>
	<version>8.1.5.v20120716</version>
</dependency>
<dependency>
	<groupid>org.eclipse.jetty</groupid>
	<artifactid>jetty-http-spi</artifactid>
	<version>8.1.5.v20120716</version>
</dependency>

References

Read More...

Charleston CodeRetreat & The Game of Life

This past saturday I attended the Charleston CodeRetreat with a few of my colleagues. This was the first official CodeRetreat in Charleston and was sponsored by Jack Russel Software and College of Charleston's School of Sciences and Mathematics. Having never been to a CodeRetreat before, I wasnt sure what to expect, but I can say that I was pleasantly surpirsed. The day was highly informative, lots of fun, and I learned a lot.

What is a CodeRetreat?

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. It provides developers the opportunity to take part in focused practice, away from the pressures of work/school. The CodeRetreat day consists of 5-6 sessions, with each session's learnings building upon previous sessions. The morning focuses on becoming comfortable with the problem domain, breaking old habits and beginning focused self-discovery. The afternoon pushes the envelope by challenging pairs to stretch their skills and understanding of abstractions, modular design and test-driven development.

CodeRetreats were started at the January, 2009, Codemash Conference by Gary Bernhardt, Patrick Welsh, Nayan Hajratwala and Corey Haines. The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development. The first event was held on January 24, 2009, in Ann Arbor, MI. By practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time. In today's world of crappy code and failing projects, this practice and experience is crucial. For more information about CodeRetreat, check out the official website at http://coderetreat.org.

Charleston CodeRetreat

The CodeRetreat on satruday was the first CodeRetreat held in Charleston, I would say it was a great success, with a turn out of around 35-40 people. The people in attendance came from all walks of life, everyone from college students to professionals with decades of experience, people who knew Java, Ruby, Python, C#, JavaScript, and more. With a such a wide range of experience in the room, there was something for everyone to learn. We started off the day with some brief introductions and then immediatley jumped in to the coding sessions. Our agenda for the day was:

  • 08:00 - 08:45 am : Registration, Coffee
  • 08:45 - 09:00 am : Welcome, introductions, explanation of the problem
  • 09:00 - 09:45 am : Session #1
  • 09:45 - 10:00 am : Retrospective & Break
  • 10:00 - 10:45 am : Session #2
  • 10:45 - 11:00 am : Retrospective & Break
  • 11:00 - 11:45 am : Session #3
  • 11:45 - 12:00 pm : Retrospective & Break
  • 12:00 - 01:30 pm : Lunch
  • 01:30 - 02:15 pm : Session #4
  • 02:15 - 02:30 pm : Retrospective & Break
  • 02:30 - 03:15 pm : Session #5
  • 03:15 - 03:30 pm : Retrospective & Break
  • 03:30 - 04:15 pm : Session #6
  • 04:15 - 04:30 pm : Retrospective & Break
  • 04:30 - 05:00 pm : Closing circle

The two main practices we focused on learning at the CodeRetreat were Test Driven Development and Pair Programming. In the agile world, these practices are extremly common, and have proven to be highly effective. During each session of the day, the goal was to use pair programming and TDD to complete as much of the problem as possible, while writting the best code possible. In the afternoon, the sessions got a little more difficult by introducing new challenges. Some of the challegens were things like not using any loops, no if statements, and no primitives. Other challenges were too use various pair pgramming techniques, such as navigator-driver and ping pong.

Conway's Game of Life

The problem domain for the Charleston CodeRetreat was Conway's Game of Life. The problem is small enough so that a significant amount of it can be completed in a single 45 minute session, but complex enough to allow for significant thought and abstraction. The Game of Life is a cellular automaton devised by the British mathematician John Horton Conway in 1970. The "game" is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves.

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

One Solution

After the CodeRetreat was over, none of the pairs that I had worked with had fully completed the problem. When I got home that evening, while the problem was still fresh in my mind, I sat down at my computer, and continued working on the problem. Using TDD, I was able to develop a solution to the problem that is based around a single Grid object that contains a list of Cells. If you want to see my implementation, it can be viewed on GitHub here.

Read More...

Java SSL/TLS Resources

Collection of resources about SSL/TLS and its use in Java.

SSL/TLS References

Java API References

Implementation References

Read More...

Static Code Analysis in Maven 3, Eclipse, & Sonar

When implementing coding conventions and best practices in a Java project, especially one with an automated build or in an agile environment, there are several static analysis code tools that are generally used. These tools automatically scan your code to looked for things like potential bugs, security risks, code smells, best practices, proper styling, etc... These tools when used in conjunction with a solid code review and check-in process can help to maintain a high level of code quality across your project. So what are these tools?

FindBugs

>FindBugs is an open source program created by Bill Pugh and David Hovemeyer which looks for bugs in Java code. It uses static analysis to identify hundreds of different potential types of errors in Java programs. FindBugs operates on Java bytecode, rather than source code.[/blockquote]In short FindBugs finds bugs in your Java code. It has several categories of bugs that it can detect and classifies each bug into a priority level based on its severity. FindBugs is generally distributed as a standalone GUI tool, however it can be integrated into Ant, Maven, Eclipse, and almost all other IDE's & build tools with one of several plugins.

PMD

>PMD is a static ruleset based Java source code analyzer that identifies potential problems like: Possible bugs, Dead code, Suboptimal code, Duplicate code, Etc... While PMD doesn't officially stand for anything, it has several unofficial names, the most appropriate probably being Programming Mistake Detector.[/blockquote]In a way PMD is very similar to FindBugs. Both tools can be used to find potential bugs and bad practices. However where FindBugs focuses on finding bugs, PMD focuses on finding sub-optimal and inefficient code. Typically, PMD errors are not true errors, but rather inefficient code, i.e. the application could still function properly even if they were not corrected. One other difference between the two is that PMD scans your source code, not the byte code, to find its errors. Like FindBugs, it will also prioritize the errors that it finds based on severity.

Checkstyle

>Checkstyle is a static code analysis tool used in software development for checking if Java source code complies with coding rules. Checkstyle defines a set of available modules, each of which provides rules checking with a configurable level of strictness (mandatory, optional...). Each rule can raise notifications, warnings, and errors.[/blockquote]Checkstyle is completly different from the previous two tools. Where FindBugs and PMD work to find bugs and poor code, Checkstyle enforces style conventions. By default it enforces the Standard Java Coding Standards as published by Oracle, however you can customize it to your specific style standards.

Sonar

Sonar is an open source software quality platform. Sonar uses various static code analysis tools such as Checkstyle, PMD, FindBugs to extract software metrics, which then can be used to improve software quality. Sonar offers reports on duplicated code, coding standards, unit tests, code coverage, complex code, potential bugs, comments and design and architecture. Typically Sonar is used in conjunction with the other tools and run each night with the nightly build. Since Sonar includes the three previously mentioned tools, it provides a web-based UI that can be used to configure the rule files for PMD, FindBugs, and CheckStyle with ease. These configuration files can then be downloaded or linked to directly and used inside automated build scripts and IDE plugins.

Pulling it all together

Maven & Plugin Configurations

When using Maven for your build tool and Eclipse as your IDE, you can very easily configure the PMD, FindBugs, and CheckStyle plugins to utilize the same configuration files that maven uses. This will allow your developers to run CheckStyle & PMD live, and FindBugs at will, without the need to do maven builds when they need to run the static analysis tools. The big advantage to the IDE plugins comes from the CheckStyle and PMD plugins. Since these tools scan your source code, not the byte code, they can run "live" in the background, and highlight errors and potential problems as they are created, so they can be resolved immediately. The CheckStyle formatter will also generate Eclipse formatter and organizer profiles based on your rules, so that the Format and Organize shortcuts will automatically match your style conventions.

Maven & Sonar Configurations

If you are using Sonar with your nightly builds and are generating your PMD, FindBugs, and CheckStyle configuration files in Sonar, then you can easily configure the Maven PMD & CheckStyle plugins to use your remote configurations. You simply need to point them to the correct permalinks for your Sonar profile. The Maven FindBugs plugin however does not yet support remote configurations. In order to use your Sonar configuration file with the Maven Findbugs plugin, you will need to first download the file locally.

You can however still automate this process by using the Maven Wagon plugin. The Wagon plugin will allow you to download the Findbugs configuration file from Sonar and place it in a local directory, prior to the Findbugs plugin running. You then just need to configure the Findbugs plugin to point to your local Findbugs configuration file.

Note: The Sonar Findbugs configuration file is an Include Filter, it is not an Exclude Filter.

Eclipse & Sonar Sharing Configurations?

Maven & Sonar together provide a very nice way to automatically scan your code for possible bugs using industry standard tools, as well as provide an extremely convenient way to manage all of the configurations. Now that your code is getting scanned nightly, and your Maven build is properly configured, you want to setup your Eclipse IDE to use the same configurations that are hosted on Sonar and that your Maven build is using. With the CheckStyle eclipse plugin this is a breeze. You can simply add a new Remote Configuration File that points to Sonar's permalink and then tell your project to use that configuration.

The PMD and FindBugs Eclipse plugins however do not support remote configuration files, so you have to have the configuration files locally. Just as we discussed earlier the Maven Wagon plugin can be setup to download the configuration files to a local directory. You could set it up to download the files for all 3 tools, and then configure both Maven and your IDE plugins to use the local files, but this causes issues when you do not have internet access. It also requires that you run the Maven script prior to setting up your IDE, but maybe this isn't an issue for your project. There are other ways to get it to work, however, none of them are as simple or straightforward as the CheckStyle plugin.

Configuring Maven

Now that you have sorted out what tools you are going to use, and how to get the configuration files locally, how do you setup Maven to run them? Well, Here is how:

Findbugs

This FindBugs configuration will run FindBugs in the verify phase of the build process. It will run with Max effort and a threshold of Experimental, this means that any errors it finds will cause the build to fail.

<plugin>
	<groupid>org.codehaus.mojo</groupid>
	<artifactid>findbugs-maven-plugin</artifactid>
	<version>2.4.0</version>
	<configuration>
		<xmloutput>true</xmloutput>
		<threshold>Exp</threshold>
		<effort>Max</effort>
		<includefilterfile>configs/findbugs.xml</includefilterfile>
	</configuration>
	<executions>
		<execution>
		<phase>verify</phase>
			<goals>
				<goal>check</goal>
			</goals>
		</execution>
	</executions>
</plugin>

PMD

This PMD configuration will cause PMD to run during the verify phase of the build process. PMD will by default fail the build if any errors are detected.

<plugin>
	<groupid>org.apache.maven.plugins</groupid>
	<artifactid>maven-pmd-plugin</artifactid>
	<version>2.7</version>
	<configuration>
		<minimumtokens>100</minimumtokens>
		<verbose>true</verbose>
		<rulesets>
			<ruleset>configs/pmd.xml</ruleset>
		</rulesets>
	</configuration>
	<executions>
		<execution>
			<phase>verify</phase>
			<goals>
				<goal>check</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Checkstyle

This CheckStyle configuration will cause CheckStyle to run during the verify phase of the build process. It is configured to ignore the test source directory, and fail the build if it finds any errors with a severity level of info or higher. This will result in a build failure on any error.

<plugin>
	<groupid>org.apache.maven.plugins</groupid>
	<artifactid>maven-checkstyle-plugin</artifactid>
	<version>2.8</version>
	<configuration>
		<consoleoutput>true</consoleoutput>
		<configlocation>configs/checkstyle.xml</configlocation>
		<propertyexpansion>basedir=${project.basedir}</propertyexpansion>
		<violationseverity>info</violationseverity>
		<includetestsourcedirectory>false</includetestsourcedirectory>
	</configuration>
	<executions>
		<execution>
			<phase>verify</phase>
			<goals>
				<goal>check</goal>
			</goals>
		</execution>
	</executions>
</plugin>

Read More...

Running Tests in Maven

To run a single tests class and all of its methods in Maven, you need to use the command:
mvn test -Dtest=TestCircle
Where TestCircle is the test class name.

To run a single test method in Maven, you need to provide the command as:
mvn test -Dtest=TestCircle#xyz
Where TestCircle is the test class name and xyz is the test method.

Note: You can also use wild card characters in the method name and class name.

Read More...