Morris "Mojo" Jones » Software and Systems

Finding the test that corrupts the suite

Morris Jones — Tue, 27 Apr 2010 16:59:03 +0000

(Finally a tech blog post …)

Stop me if you’ve heard this one before!

The web application has excellent coverage in unit tests and integration tests that run continuously, but some time ago (weeks actually) some number of tests began failing with strange state errors. In our case, out of 138 test classes and 1176 tests, 82 would error out.

The errors were all strange platform related things, like:

org.springframework.transaction.IllegalTransactionStateException: Pre-bound JDBC Connection found! JpaTransactionManager does not support running within DataSourceTransactionManager ...

Or:

java.lang.NoSuchMethodError: org.hibernate.cache.CacheException.

Naturally the failing tests all work when they’re run individually. Heard that one before?

I started out trying different combinations of tests. I could make a list of all the running test classes by grepping for “^Running ” in the test output log. I started out using the maven option “-Dtest=TestClassOne,TestClassTwo,…” to try tests in different combinations. Most of the time, the erroring tests would work perfectly. When they didn’t, the errors would occur in different tests or be different errors.

The failure now was non-deterministic! One of the difficulties is that Maven/Surefire would run the tests in whatever order it wanted to. That approach wasn’t going to work at all.

From studying the Spring references a little, I understood that Spring would cache the application contexts created for unit tests in order to improve the run time of tests. Wiring up a large application is slow when it’s done once — multiply that by 138 test classes and a slow test suite becomes glacial.

Clearly some test class being run prior to the error tests was corrupting the cached Spring context, and ruining the downstream environment. Spring provides a @DirtiesContext annotation specifically to label tests that require Spring to reload the application context. The problem is finding the test doing the dirty work!

I needed to make the test runs deterministic — run the test classes in the same order, and start eliminating classes one at a time from the top of the order. Surefire doesn’t have a property to exclude a test on the command line, so it required editing the POM file to exclude each test class in order from the top.

It was a tedious task, as many hidden software problems can be. I had to keep careful track of the list of test classes, and change the TestClassExample element for each test run. Fortunately each test run only required about two and a half minutes. After each test with one class excluded, I would examine the final result line for any change.

I was pretty confident that the culprit had to be an early test in the sequence, so I should only have to go about halfway through the successful test classes. Finally thirty-four classes into the list, I had my culprit.

Ironically enough, the test class causing all the problems was named TestSpringConfigurations. It had two tests that would simply verify that all of our wiring would successfully produce an application context. Marking the tests with the @DirtiesContext annotation made all of the following error tests run successfully.

Actually the @DirtiesContext annotation wasn’t necessary: The tests themselves included one fatal line: context.close(). By not closing the contexts after the test load, the cached application context was just fine for all the following tests.

One might argue that this class is pointless when run as part of a large test suite, since earlier tests have already loaded the application context. When Surefire arrives at TestSpringConfigurations, it is only using the already-cached context rather than loading a new one. Good point. But having the test in the suite also gives us a quick way to verify changes made to the application context configuration without running the whole set.

And finally the punch line: When the Spring configuration errors were finally vanquished, four test failures were revealed that were legitimately testing application code. Those test failures were completely masked by the Spring context corruption error.

Oh yes, that TestSpringConfigurations class has been in the suite for many months. Why did we only recently find it causing this corruption? No one here is quite positive, but the only major platform change we can point to is a switch from Java 5 to a Java 6 runtime. Maybe that triggered the original problem, and maybe sometime I’ll be interested enough to test that proposition.

Perfect wallpaper from digital photos using Linux and Netpbm

Morris Jones — Wed, 07 Oct 2009 04:13:15 +0000

The world is full of wallpaper managers for every operating system out there. I enjoy wallpapers taken from some of my digital photography, such as this trip to Yosemite last year.

On nice modern monitors, you can really enjoy the full resolution of your pictures. Jane and I just replaced our old Viewsonic CRT monitors with some nice Dell 23-inch LCD models.

Immediately I saw that I needed to regenerate our collection of wallpaper photos to match the aspect ratio and higher resolution of our new monitors. I admit to being a stickler for my wallpaper photo albums. I have these requirements:

I want to scale and crop the photos to fill the screen exactly, no tiling or stretching.
I want no black bars, letterboxing, or distorted aspect ratios
I want to dim the maximum brightness of the photos so my desktop icons are still discernable

My Canon 20D full-resolution pictures have more than enough pixels to fill the biggest screen, so I cobbled together a shell script some time ago using the PBM (Portable Bitmap) tools that have been around since probably the 80′s for manipulating images. I don’t think many of the Linux distros install the toolset by default, but they’re easily available. On Ubuntu or Debian you can install them with “apt-get install netpbm”.

I start by making a work directory (“wallpaper” in this instance) and a subdirectory to hold the full-resolution original images, named “full”. I collect copies of my full-resolution pictures there in ~/wallpaper/full.

Next I need to work out the transform. My original resolution images are 3504 pixels wide by 2336 pixels vertically. My monitor is 2048 pixels by 1152 pixels.

Rather than work out the math, I just scaled an original picture to the monitor width to see how tall it would be. This command pipeline would scale a picture to 2048 pixels wide:

jpegtopnm full/IMG_1234.jpg | pnmscale -width 2048 | pnmtojpeg >IMG_1234.jpg

Opening that scaled image in Gimp told me that it was 2048 x 1365. That tells me that I need to crop some lines from the top and bottom of the image to fit them exactly to my monitor field. 1365 – 1152 leaves 213 lines to cut from the image. With the pbmtool “pamcut” I plan to cut 107 lines from the top of the image and give it a total height of 1152.

So I made this shell script to process all of the photos. The plan is to read all of the files from the “full” directory, and write perfectly scaled images to a subdirectory named “2048″. I’m also going to use the “ppmdim” utility to reduce the overall brightness of the images just a little. Here is the final script, called “mkwall2048″:

for i in `ls -1 full`
do
echo $i
jpegtopnm full/$i \
 | pnmscale -width 2048 \
 | pamcut -top=107 -height=1152 \
 | ppmdim 0.8 \
 | pnmtojpeg >2048/$i
done

This loops through every file in the “full” directory, putting the filename in variable $i. The rest of the script is a pipeline that feeds the image through five different tools from the Portable Bitmap collection, as follows:

jpegtopnm converts the input file to a portable “any” map, then feeds it to stdout
pnmscale scales the image to a width of 2048 pixels, preserving the aspect ratio
pamcut slices off the top 107 lines, and preserves the next 1152 lines of the image
ppmdim reduces the brightness of the image by 20% (80% of the existing brightness)
pnmtojpeg converts the portable bitmap image back to a JPEG file

I’ve adjusted this script using the same process to make perfect wallpapers for my laptop monitors and desktops at work. It’s a real treat having a slideshow of my favorite photography available behind my work.

“Bean Validation” Emmanuel Bernard

Morris Jones — Fri, 20 Mar 2009 22:39:15 +0000

Registration lobby at Caesar's Palace

Notes from TheServerSide Java Symposium March 2009

What’s the point of a bean validation framework? I’ve been wondering that for a while now. Emmanuel points out that it’s mostly to keep from repeating yourself in code.

Validation itself is obvious … keep crap out of the database, apply constraints to data fields, give feedback to users.

Where do we apply validation constraints? Take a typical application stack:

client -> presentation layer -> business layer -> data access layer -> database

He begins by giving several examples of how constraints are applied to day, down to the DDL in the database which might specify a column length and a “not null” constraint. These constraints are typically duplicated all the way up the application chain, and really bad when the constraints don’t agree!

He proposes a uniform way to express a constraint, a standard way to validate constraints, and a bridge for constraints out of Java land, exposing constraints to the outside world.

Annotations are the key, extending the type system, right next to the class definition. Hence JSR 303 for bean validation. Example field annotations for validation:

@NotNull
@Size(max=30, message="longer than {max} characters")

The spec also calls for validating subsets of data fields by specifying groups, or partial validation. The spec defines groups by using interfaces. Clumsy, but workable.

Custom constraints can be built out by creating a custom annotation with an expressive name, extending the @Constraint type. You can compose a group of existing validators from the library into a new annotation.

(So far I’ve only been a consumer of annotations. Maybe soon it will be time for me to start creating them as well. I usually try to avoid meta-programming, even though it can be fun.)

“Building Next-Generation Web Applications with the Spring 3.0 Web Stack” Jeremy Grelle

Morris Jones — Fri, 20 Mar 2009 21:54:07 +0000

Notes from TheServerSide Java Symposium March 2009

Jeremy is going to help us battle complexity in web applications. (It’s hard to find a web framework that isn’t its own layers of complexity.) He’s the lead for Spring Faces, Spring JavaScript, and a JSF 2.0 expert group member, and he’s a former “rock star.”

The Spring Web stack is a collection of open source projects that provide infrastructure for developing and running Java web applications. You can pick and choose the pieces you need, and it works on any server platform.

Spring Framework and Spring MVC are the common foundation. On top are Spring Web Flow, Spring JavaScript(!), Spring Security (formerly Acegi), and on top of that, Spring Faces (JSF integration support) and Spring BlazeDS Integration (brand new, integrates Flex clients with the back end).

Here are some new features being introduced with Spring 3.0.

Spring Framework and Spring MVC

The new support that I really like is a URL paradigm that acts more like RESTful web services. URLs become meaningful, and identify a heirarchy right into your domain model.

URL examples:

/hotels would render a list of al hotels
/hotels/westindiplomat would give hotel details
/hotels/westindiplomat/bookings a list of bookings
/hotels/westindiplomat/bookings/4325324 a specific booking.

Query variables become less significant, and primarily input for algorithms. They tend to get ignored by proxies, and often abused.

The key to these RESTful URLs are URI Templates containing variable names, for example /hotels/{hotelId}. Supported in Spring 3.0 with the @PathVariable annotation, which allows you to use URI templates in MVC.

This is really nice! Controlling URLs nicely is a frequent complaint of mine in typical Java servlet frameworks. Adopting RESTful URL patterns is friendly, readable, and makes a lot of sense. Cut down the use of parameter variables, and put the domain IDs right into the URL path.

He also showed new view features for content negotiation, new views like and RssFeedView, and ways to support all four standard HTTP verbs from the client (PUT and DELETE as well as GET and POST). (Now you can use for instance.)

Spring JavaScript

Spring’s Ajax integration library, builds upon the Dojo toolkit. The “key value proposition” builds in usage best practice, makes Dojo easy to use for common Ajax scenarios. (I thought Dojo was already pretty easy to use. Do we need another layer of abstraction?)

Spring Web Flow

Web flow is primarily a framework for implementing user dialogs, guiding a user through a business process. Things that are session-related and stateful. Key feature is a high-level flow definition language using XML and EL. Plugs into Spring MVC. (Not sure I see the value here yet.)

Spring BlazeDS Integration

Newest project being introduced with 3.0. Connects Flex client to Spring-managed services using BlazeDS transports. They claim it makes Flex natural in a Spring environment. Integrates Spring Security to secure Flex apps. Provides support for real-time data push using Spring Integration.

Examples

He started walking through a new-style @Controller object with the @RequestMapping annotation marking one of their flexible controller methods. The

“Building Server Platforms with OSGi and Equinox” Rob Harrop

Morris Jones — Fri, 20 Mar 2009 18:23:51 +0000

BIRTExchange at TheServerSide (not related to the talk)

Notes from TheServerSide Java Symposium March 2009

Rob wrote his talk for EclipseCon which is next week, so we get an early peek. He’s the lead developer from dm Server at SpringSource.

I’m a complete noob to OSGi, so I’m not familiar enough to see what’s really important or significant in the talk.

Benefits of OSGi: System Partitioning, Dependency Management, Dynamism

He starts by taking his first simple partitioning of modules, and later breaking, extracting, and rearranging modules as required. Or it’s possible and desirable to fold modules back together.

I think the cool point of his talk is this osgi namespace in the Spring application-context files to import OSGi references and dependencies. The MANIFEST.MF file contains classpath dependencies, which I assume is a standard OSGi practice. But how should the MANIFEST.MF file be maintained?

The dependencies go into the Maven POM file, and the classpath dependencies for the MANIFEST.MF can be maintained automatically by an Eclipse plug-in. This makes the Maven POM file the single canonical source for dependency information.

“The Keys to Agile Software Development” Jon Kern

Morris Jones — Fri, 20 Mar 2009 17:09:26 +0000

The tech crew enjoys some breakfast before the morning keynote.

Notes from TheServerSide Java Symposium March 2009

Jon’s a fine fellow, but his talked (to me) seemed mostly to be stating the obvious. I’ll just provide his “Rules to Code By:”

It’s the Business, Stupid
Not all shiny new toys should be fondled
A fool with a tool is still a fool
Don’t mistake activity for progress
Hard to get work done when you are always in meetings
Your team should hit a stride
Development should feel cyclical and rhythmic
Be impatient
Don’t tolerate waiting (for long)
Be lazy
Don’t do tedious, mediocre chores over and over
Have fun — or take a break

“The Amazing Groovy Weight-Loss Plan” Scott Davis

Morris Jones — Thu, 19 Mar 2009 21:26:57 +0000

Notes from TheServerSide Java Symposium March 2009

Scott Davis was the perfect presenter for the deadly “after lunch” session period. Interesting that his Groovy introduction is in a breakout room rather than the main ballroom, and there is not an empty seat in the house. Everyone is fascinated by these new powerful JVM languages, including me.

Scott started by asking who was a Java programmer in the house, a silly question at a Java symposium. He followed by asking who were Groovy programmers, and two or three hands went up. Followed by “Aha! Just by adding one JAR file to your classpath, you’re all Groovy programmers too.”

He immediately quit using slides, and went directly to live coding. Fabulous for a software talk! He started with a one-line “Hello, World” and then moved on to show off Groovy’s object and dynamic type features.

He’s using javap to explore groovy-created class files and show how the underpinnings relate directly to the Java infrastructure.

Admittedly, these powerful JVM languages are very seductive. They call them scripting languages, and yes, they’re great for scripting. But full powerful languages like Groovy, Scala, JRuby, Jython, and even JavaFX have enormous potential. I’m being torn in about five directions for new projects.

“Spring for the Advanced Java Developer” Rod Johnson

Morris Jones — Thu, 19 Mar 2009 19:41:20 +0000

Notes from a session at TheServerSide Java Symposium March 2009

Rod addressed some emerging best practices based around annotation-based application configuration using Spring 2.5 and later.

The emerging best practice is to use the @Autowired annotation rather than @Resource. He demonstrated how to disambiguate bean references with @Qualifier. He also showed how to create your own custom annotations and use them to disambiguate similar types:

@Autowired public void setOrderServices(@Emea OrderService emea, @Apac OrderService apac) { ... }

@Emea public class EmeaOrderService implements OrderService { ... }

@Apac public class ApacOrderService implements OrderService { ... }

(What was unclear to me at the time is whether or not these custom annotations required some definition elsewhere, but I’m not entirely conversant on how annotations work.)

He also spent some time on the @Component meta-annotation, and the concept of stereotypes. Spring comes with several pre-configured stereotypes:

@Service
@Repository
@Aspect
@Controller

It’s a powerful concept.

So here’s the big question for me. Why are we configuring with annotations now? It doesn’t do away with the need for context XML files. He indeed mentioned the pros and cons for using Spring 2.5 annotations:

Component scanning pros:

No need for XML (potentially)
Changes picked up automatically
Works great with annotation driven injection
Highly configurable (whatever that means)

Component scanning cons:

Not a 100% solution (can’t do everything with annotations)
Requires classes to be maintained
Need to take care not to scan an excessive number of classes (use filtering)
Don’t get valuable application blueprints documented in application XML

He makes a decent case for mixing and matching XML configuration with annotation configuration.

The emerging best practices (he says) include:

Use XML for classes that you can’t or won’t annotate, such as third party components (data sources, message queues)
Use annotations and classpath scanning for application objects
Jump into XML for complex injection behavior and per-instance configuration (like injecting lists and maps)

He suggests the Spring Web Flow example application for examples.

He recommends moving away from the old Spring MVC inheritance model in favor of the @Controller stereotype. (Need to go back to his slides for other recommendations.)

The rest of the presentation covered features coming up in Spring 3.0. One nice feature is the ability to embed property value injection with a @Value annotation and a new expression language. Example:

@Value("#{systemProperties.favoriteColr}") private String favoriteColor;

@Autowired public void init(@Value("{systemProperties.databaseName") String dbName)

I was happy to see this presentation, because I’ve really been resistant to using annotation based configuration and component scanning. I do like the XML blueprint for an application, and I like having one place to look for how my application is configured. (I even try to avoid using multiple application context XML files, which avoids having to hunt through several files to find my bean configuration.)

Things that happen by magic like autowiring make me a little uncomfortable. He pointed out that the Spring IDE is a good practical solution for actually browsing through your app configuration.

“How Spring Fits into the Java Landscape” Rod Johnson

Morris Jones — Thu, 19 Mar 2009 18:28:59 +0000

Notes from TheServerSide Java Symposium March 2009

At a keynote talk, you expect sweeping generalizations and “big picture” insights.

Rod pointed out some things that I have watched happening over the past two decades, namely the rise and fall of complex monolithic software systems as an expensive luxury that falls in favor of simplicity along with economic cycles.

“Enterprise Java” has a reputation for complexity, based on the early (failed) J2EE platform, and giant enterprise software systems like those from IBM and BEA. “Complexity is the single biggest killer of projects,” he says. I concur.

“Economic downturns reduce software complexity. Truly bad ideas need a booming economy to survive.” I never thought of it like that, but it should have been obvious.

Service Oriented Architecture (SOA) is one of those complex frameworks that he claims is doomed at this point.

So the movement now is to “lean software,” simpler modular systems that don’t try to solve every problem but focus on doing one or two things well.

His examples, past giants of complexity: IBM, BEA, Sun. Today’s leaders: Spring, Hibernate, Ruby on Rails, Django, Grails, Eclipse ecosystem.

In terms of business management, this means that companies move away from the large portfolio software solutions that require huge quantities of support and complexity. The movement is toward point solutions that are smaller and more targeted. This is a pendulum that directly follows the economic cycle.

Nicely done.

“Leveraging Groovy for building Java applications” Hans Dockter

Morris Jones — Thu, 19 Mar 2009 18:12:50 +0000

Notes from a talk at TheServerSide Java Symposium March 2009

Hans is the project lead for a build system called Gradle. He presents it as a step beyond Ant and Maven.

I think he has a point. His system uses Groovy scripts as build scripts instead of XML. The advantages of having a full language available in build scripts is pretty clear. (Try writing a conditional clause in Ant XML. Ewww!)

Gradle is a build toolkit and collection of small frameworks, rather than one monolithic build framework. It seems to me like this is a step back toward customization and away from “convention over configuration.” But the truth is that one build convention can not serve all build situations, and there’s probably nothing more customized in individual companies than their build, test, production, and deployment environments.

(At MyAds we built a custom version of the Maven Release plug-in just to support our version numbering system. One size does not fit all, especially in building applications.)

Hans says it’s easier to write and use Ant tasks in Gradle than in Maven. Gradle is using dependency management based on Apache Ivy, which I’m not familiar with. He recognizes the value of dependency management as introduced by Maven, so I have a feeling Apache Ivy won’t disappoint. I crave good dependency management, even though it can lead to Maven dependency hell at times. Ivy appears to be leveraging the Maven dependency infrastructure, as well as supporting SVN dependencies.

So I like the concept of using a full dynamic OO language for writing build scripts, especially if the API toolkit is sufficiently intuitive that it doesn’t have a large learning curve. Gradle is worth investigating.

Link to presentation here.

Gradle roadmap here.