nthread

Are you trying to run Tomcat 6 on Ubuntu.
Are you seeing a stack trace that starts with:

java.lang.NoClassDefFoundError: org/springframework/core/NestedExceptionUtils
        at org.springframework.core.NestedRuntimeException.getMessage(NestedRuntimeException.java:67)
        at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
        at java.lang.Throwable.toString(Throwable.java:343)

Go into your /etc/init.d/tomcat file and change

# Use the Java security manager? (yes/no)
TOMCAT6_SECURITY=yes

to

# Use the Java security manager? (yes/no)
TOMCAT6_SECURITY=no

Don’t leave it like this, but it will fix your problem, you are having a file policy issue and will need to make additions to your security policy to allow web applications to read files.

I just started working with the Google Java App Engine.

• + It’s super easy to deploy to
• -The persistence feels really unatural. You just create JPA objects and use their persister, no DB create scripts
• + No DB create scripts, I think I’m going to like this once I’m used to it
• - I’m not sure how data export and migration works

Pretty neat though, you should try it out if you can still sign up for the beta.

You need a persistent class.

package com.nthread.babelhelp.datamodel;

import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class HelloGDB {
	@PrimaryKey
	@Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
	private Long id;
	@Persistent
	private int count;

	public HelloGDB(int count) {
		this.count = count;
	}

	public Long getId() {
		return id;
	}

	public void setCount(int count) {
		this.count = count;
	}

	public int getCount() {
		return count;
	}
}

You have to use a singleton to keep your static PersistenceManagerFactory - if you try to instantiate it twice, you will find your app pretty unhappy.

package com.nthread.babelhelp.model;

import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManager;
import javax.jdo.PersistenceManagerFactory;

public class Persistor {
	private static PersistenceManagerFactory pmfInstance =
		JDOHelper.getPersistenceManagerFactory("transactions-optional");

	public static PersistenceManager getManager() {
		return pmfInstance.getPersistenceManager();
	}
}

I just use these things from a Servlet, it’s pretty basic.

package com.nthread.babelhelp.control;

import java.io.IOException;
import java.util.List;

import javax.jdo.PersistenceManager;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.nthread.babelhelp.datamodel.HelloGDB;
import com.nthread.babelhelp.model.Persistor;

public class HelloWorldServlet extends HttpServlet {

	protected void doGet(HttpServletRequest req, HttpServletResponse resp) {
		doRequest(req, resp);
	}

	protected void doPost(HttpServletRequest req, HttpServletResponse resp) {
		doRequest(req, resp);
	}

	protected void doRequest(HttpServletRequest req, HttpServletResponse resp) {
		PersistenceManager pm = Persistor.getManager();

		String query = "select from " + HelloGDB.class.getName();
		List hellos = (List) pm.newQuery(query).execute();

		HelloGDB helloGDB = null;
		if (!hellos.isEmpty()) {
			helloGDB = hellos.get(0);
		} else {
			helloGDB = new HelloGDB(0);
		}
		helloGDB.setCount(helloGDB.getCount() + 1);
		try {
			pm.makePersistent(helloGDB);
		} finally {
			pm.close();
		}

		String str = "Current count is " + helloGDB.getCount();
		try {
			resp.getWriter().write("" + str + "");
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
	}
}

Unit testing is a lot easier if you don’t have to run a web container, and the spring framework includes a library of solid mock classes for testing. There are a ton of pages out there talking about how to test Spring MVC controllers with the mock classes so I’m not going to get into that. I will instead walk through testing a Servlet Filter.

The filter is a pretty lame filter called StrangeFilter. All is does is forward requests with a parameter set.

package com.nthread.sandbox;

import java.io.IOException;
import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class StrangeFilter implements Filter {

	private FilterConfig filterConfig;

	public StrangeFilter() {
		// TODO Auto-generated method stub
	}

	public void doFilter(ServletRequest request, ServletResponse response,
			FilterChain chain)
			throws IOException, ServletException {
		if ("okay".equals(request.getParameter(""))) {
			this.filterConfig.getServletContext()
				.getRequestDispatcher("/fail.html")
				.forward(request, response);
		} else {
			chain.doFilter(request, response);
		}
	}

	public void init(FilterConfig filterConfig) throws ServletException {
		this.filterConfig = filterConfig;
	}

	public void destroy() {
		// TODO Auto-generated method stub
	}
}

To test this filter without a web container is really pretty easy. You need to make use of four Mock classes provided by the Spring test framework, but basically, it’s just as easy as any other unit test. I think the code pretty much speaks for itself, so here it is.

package com.nthread.sandbox;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.fail;

import java.io.IOException;

import javax.servlet.ServletException;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import org.springframework.mock.web.MockFilterChain;
import org.springframework.mock.web.MockFilterConfig;
import org.springframework.mock.web.MockHttpServletRequest;
import org.springframework.mock.web.MockHttpServletResponse;

public class StrangeFilterTest {

	private StrangeFilter filter;
	private MockHttpServletRequest request;
	private MockHttpServletResponse response;
	private MockFilterChain chain;

	@Before
	public void setUp() throws Exception {
		filter = new StrangeFilter();
		filter.init(new MockFilterConfig());
		request = new MockHttpServletRequest();
		response = new MockHttpServletResponse();
		chain = new MockFilterChain();
	}

	@Test
	public void testDoFilterWithFail() throws IOException, ServletException {
		request.addParameter("failThis", "okay");
		filter.doFilter(request, response, chain);
		assertEquals("/fail.html", response.getForwardedUrl());
	}

	@Test
	public void testDoFilterWithoutFail() throws IOException, ServletException {
		filter.doFilter(request, response, chain);
		assertNull(response.getForwardedUrl());
	}

}

In my continued efforts to provide an opinionated view on Java architecture, I’m going to talk about scheduling frameworks and to that end, I’m only going to talk about one.

Quartz

Quartz is really the only framework that is widely supported in Java:

• It has great Spring support, outlined at http://static.springframework.org/spring/docs/2.5.x/reference/scheduling.html. This is definitely the best way to use Quartz in most cases.
• Quartz can be run programatically, but you have to write a tiny bit of code to do it. There is a quick start guide on the quartz site - basically, you need a properties file and a main class, so not that bad. Still a little harder than the spring way, so not desirable.
• It is very easy to run Quartz as a servlet - the documentation is actually contained in the Javadoc. It’s similar to the programatic method in that you need to write a properties file, but you don’t have to write a main method, and that’s a good thing.

Quartz is solid, use it if you need scheduled tasks. The Canuck’s just scored, and I’m going to watch the game now.

Basic Java testing is really not that interesting, you use Junit (did I really need to include a link?), and hopefully version 4 with annotations. Once you have started writing unit tests, you may notice that there are more things you want to test, and you should probably find out how good your tests are.

Code Coverage

Code coverage reports are a great way to tell if your have written enough unit tests for your code. Generally, your tests should cover at least 90% of your code, and once you have code coverage tools, you will probably feel compelled to reach high %s of coverage. I looked around at a bunch of tools and tried out what I could. There were three tools that stood out (for good reasons, coverlipse killed my eclipse install, and I don’t really recommed trying it).

Cobertura

Cobertura

Cobertura was very easy to get running with Maven, but was a little more challenging with Ant. Generally a really good tool but not that easy to integrate into eclipse, the UIs are the most visually appealing.

CodeCover

CodeCover Screenshot

CodeCover was really well integrated with Eclipse and works pretty well out of the box. Definite a plus. I didn’t really like the mechanism for adding classes, but if I used a normal Maven project setup, that would probably be fine. This is a good tool for local development, but the team tools are not that extensive.

Clover

Just for completeness, I should give the atlassian product mention. While a good product, Atlassian (the makers of Jira) at starting to be a little too expensive.

Overall, I like these tools a lot and hopefully this will help you get started with them.

I’ve always been a big fan of the joelonsoftware blog, and in the area of software architecture, Don’t Let Architecture Astronauts Scare You and Things You Should Never Do. Generally, if you have not read Joel’s blog or books, go through the best of in the right nav and read most of it.

97 Things Every Software Architect Should Know has a very good list of gotcha’s and rules of thumbs for software architects.

The thing that got me thinking about this was Agile Architecture, a good blog today about keeping architecture moving along during a project, always a good idea.

All of these are good reads, and it makes me think about the useless courses in software engineering I took in university where professors spent hours excitedly talking about the capability maturity model. I guess it didn’t matter, I really didn’t know how to work through a big project in school.

• A key thing with any project is that the development and design be broken up into phases that are small enough to think through and get done.
• If the tools and frameworks that you are trying to develop with are hard to use or seem like a pain to develop with, they just aren’t the right ones. There are easy to use tools for everything out there.
• In general, do a project the easiest way possible. Sometimes people try to do things because they feel like they are the “right” way to do things, even though they aren’t the easiest. These are not the right way to do things.

Keep it simple.

So I just spent a good chunk of time looking around at web service libraries for Java. My criteria were not long:

• JSON support, really SOAP wasn’t that much of a requirement, but all of the mature libraries support it.
• Simple to setup and develop with
• Easy to maintain services

First, I tried my old standby Apache Axis.

• I found it fairly difficult to find documentation on running Axis services in a web container. Whatever, I got through that, it’s actually pretty easy once you find the right page.
• Running JSON services is not that easy. Axis default to adding namespaces to everything, but the out of the two JSON types:
  • Badgerfish - the formatting is just wierd, and not that great for typical Javascript development
  • Mapped - this was normal, but then really didn’t work well with namespaces
• All of this really lead to having to hand edit the WSDL files to get a good result with JSON services. This really isn’t that great for maintaining.
• Also, it just seemed like too many jars were brought in by the Axis pom file

So I moved on to trying out JAX-WS from Sun.

• Setting up a SOAP based web service using these libraries was a little bit tough in terms of finding good documentation, but turned out to not be that bad.
• Building JSON with the JAX-WS was a disaster. Neither of the libraries I could find really worked at all.
  • JAX-WS Commons JSON was the first library I tried. The basic setup was pretty easy, but it just doesn’t work well with object return types. So a no go.
  • http://code.google.com/p/jsonwebservice/ was the second library I tried out - again, it just didn’t do it.

At this point, I was still developing on Axis and kind of resolving myself to having to maintain a WSDL file but I stumbled across Jersey. Jersey is Sun’s REST library, and while I wasn’t necessarily looking for a resty library:

• Jersey works! This page has a good outline of what you need to do from maven to web container.
• It’s so easy, JSON, SOAP, both super easy. Not much config, just point your web.xml at the packages with your services.
• The test framework is very well thought out too, and works well with JUnit.

And that’s it. Use Jersey, and hope that Oracle likes it (so they don’t make it disapear).

I started working with JavaScriptTemplates today after finding that jtemplates really let me down on performance on a long template (it was taking about 2.5s to load, JST topped at 200ms).

Just to give you a flavor for how it works, I’ll outline how I used it. To start, I created a JSON data file - typically this would be fed by a web service, but for getting up and running, a file is easy.

userdata.json:
{ users : [
{ name: "John Doe", email: "john.doe@nthread.com"},
{ name: "Jane Doe", email: "jane.doe@nthread.com"}
] }

Then I created a really basic web page. The page had a div where the templated HTML would be placed:

<div id=’userlist’ ></div>

And imported the jQuery & JST scripts in the header:

<script src=”scripts/jquery.min.js” type=”text/javascript”></script>
<script src=”scripts/trimpath-template.js” type=”text/javascript”></script>

Next, I created the template, which needs to be placed in a textarea. All of the templating libraries I have seen use a textarea for this, probably because it is the only place on a web page where you can avoid the browser parsing the HTML into DOM elements (which leads to escaping):

<textarea id='userlist_template' style='display:none' >
 <ul>
 {for user in users}
 <li><a href='mailto:${user.email}' >${user.name}</a></li>
 {/for}
</ul>
</textarea>

Finally, a small piece of JST & jQuery is used to load the JSON file in process it through the template:

<script type="text/javascript" >
 $(document).ready(function() {
  var data = $.getJSON("users.json", null, showData);
 });
 function showData(data) {
     var userlistTemplate = TrimPath.parseDOMTemplate("userlist_template");
     $("#userlist").html(userlistTemplate.process(data));
 }
</script>

That’s really all there is to it. This prints out the fairly unexciting:

User List

• John Doe
• Jane Doe

It really is pretty cool though, try it out.