Deciphering EclipseLink Error Messages

Suppose you get this:

Descriptor Exceptions: 
Exception [EclipseLink-108] (Eclipse Persistence Services - 2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: Cannot find value in class indicator mapping in parent descriptor [null].
Descriptor: RelationalDescriptor(com.foobar.Foobar --> [DatabaseTable(FOOBAR)])
Exception [EclipseLink-41] (Eclipse Persistence Services - 2.6.2.v20151217-774c696): org.eclipse.persistence.exceptions.DescriptorException
Exception Description: A non-read-only mapping must be defined for the sequence number field.
Descriptor: RelationalDescriptor(com.foobar.Foobar --> [DatabaseTable(FOOBAR)])

That means, believe it or not, only that you have an abstract entity without any concrete entity specializing it.  That’s all it means.  It doesn’t have anything to do with sequence numbers, or (otherwise) badly mapped entities, or

The Slow Code Movement

I think I want to start a movement.

Actually, I’d be resuscitating the good parts of a movement that happened a long time ago.

I would call the movement the Slow Code Movement.

Or perhaps the Artisanal Code Movement.

Its fundamental principle would be that no one has ever really valued any product that was mass-produced quickly.

Yet that’s what we’re asked to do in software circles every day.

Think about it. Everything that you value or love intrinsically was made carefully or thoughtfully. This goes for cars, coffee mugs, clothing, beer, paper, your Grandmother’s spaghetti sauce, tools, kids’ artwork, campfires, flight plans and babies. These valuable things were created only after a fair amount of thought and vision was put into them.

Now think about the software that you were asked to write most recently—or perhaps better yet, a couple of years back. Do you even remember what it was supposed to do? Do you recall what the urgency was for? Did it matter that you released it during the last week in July instead of the first week in February the following year?

Or perhaps you run a VC-funded startup, and you’ve bought into the culture that says you must rush to market, and that a moment spent thinking is a moment you could have been pivoting, or crushing it, or other very important things. But what has that bought you? It sure bought your VC firm a lot!

Obviously there are some industries where there is no wiggle room. But there are vast numbers of industries where there is plenty of wiggle room. And there is open source, where there’s all the wiggle room in the world.

And yet we, as an industry and as a practice, flail around, flinging code about us as we hurtle down hill and around corners without brakes, in the name of agility and nimbleness. (I do not think those words have come to mean what you think they mean.)

That doesn’t mean always designing big up front. Novelists frequently write books without plotting the whole thing. Nor does it mean anticipating the impossible. But perhaps it does mean metaphorically laying a dropcloth, taking a couple of deep breaths, pausing to think, infusing calm into your department, crafting words and ideas as much as code and taking that extra moment to create something worth making.

Concurrent Testing

Finally had some time at JavaOne to sit down and whack away at something that I have never had the time to explore thoroughly: parallel JUnit testing using the Maven Surefire plugin.

The executive overview is that you can run your JUnit tests in parallel in a number of different ways, and it’s worth understanding them all thoroughly so you don’t inadvertently structure your tests in such a way that parallelism is impossible.

To start with, let’s look at the general architecture of a normal, non-exotic JUnit test as run by Surefire.

Unless you’ve done something unusual, you likely have a class or two lying around in your src/test/java tree named And in that test class you likely have various methods annotated with @Test.

If you run this with Surefire 2.16 out of the box, you’ll note that the following things happen in order:

  1. The Maven JVM forks exactly one additional JVM. Its settings are taken from the maven-surefire-plugin:test goal’s argLine property (or defaulted).
  2. The Surefire JVM just forked loads your test class and instructs JUnit to run it.
  3. JUnit runs any @BeforeClass-annotated methods in your class.
  4. For each test method:
    1. JUnit creates a new instance of your test class.
    2. JUnit runs any @Rule-annotated public fields in your test class.
    3. JUnit runs any @Before-annotated methods in your test class.
    4. JUnit executes your test method.
    5. JUnit runs any @After-annotated methods in your test class.
  5. JUnit runs any @AfterClass-annotated methods in your class.

…and that’s it.

It’s important to note that a new instance of your test class is created for each test method that is run. File that away for a moment.

Now, as regards parallelism, we can control the number of threads that are dedicated to running JUnit test methods, and we can control the number of processes that can run these threads.

First, let’s look at the processes. We can control these in Surefire using the forkCount and reuseForks properties.

I don’t know about you, but these terms were somewhat confusing. forkCount is the maximum number of forked JVMs that can be running in parallel at any time. It says nothing about the total number of these forked JVMs that might exist over time. reuseForks makes it so that the number of total operating system processes spawned over time is either governed (and equal to the forkCount) or ungoverned. So if you want to ensure that only two processes, period, are created by Surefire, then you want <forkCount>2</forkCount> and <reuseForks>true</reuseForks>. If, on the other hand, you don’t really care how many processes Surefire ends up spawning and killing, but you want to make sure that no more than two are running at the same time, then you want <forkCount>2</forkCount> and <reuseForks>false</reuseForks>.

Normally you want to reuse forks. The only time I could think of where you wouldn’t want that is if your tests exercise some kind of static singleton or something that has state inside it that you can’t reset. If that’s true, then if you reuse forks it is possible that the state of this singleton could pollute subsequent tests.

Next, let’s look at methods.

You can parallelize test methods at the thread level, but not at the process level.

A JUnit test method, as we’ve seen, is conceptually equivalent to a constructor invocation, some setup work, the method invocation and some teardown work. There’s no way to instruct Surefire to somehow create a new JVM process as well for this; process parallelism stops at the class level. (Creating a separate process for each test method invocation would be a little nuts; if you really need that you can create JUnit test classes that take great care to have only one test method in them. You could probably do something else too with JUnit suites.)

So we’re looking at threads when we’re looking at parallelizing JUnit test methods. You can indicate that you want Surefire to run your test methods in parallel by using the aptly-named parallel property. Together with the threadCount, perCoreThreadCount and useUnlimitedThreads properties, you can control how many threads are spawned to run test methods.

Note that if you have more than one thread rummaging around in your test case, the static information (if any) your test might have needs to be thread safe. It is best of course if you can avoid it to not have any such static information that can change.

Recall as well that a test method invocation is also semantically a constructor invocation, so oddly enough while your static information must be thread safe, your instance information does not have to be thread safe.

Regarding things like database connections and whatnot, you want to make sure that your test methods are as isolated as humanly possible—or at least that (if they are not) they take great care to lock on shared resources.

Use @Singleton, not @Stateless

Something I’ve been musing over in the background for some time. This is not revolutionary.

In almost any circumstance that I can think of, you probably want to be using @Singleton EJBs, not @Stateless EJBs.

In this day and age with these JVMs and these JITs, the object pooling mechanisms which seemed so necessary back in the EJB 1.x days seem laughable now.

In addition, if you’re careful, you can use concurrent utilities in your @Singleton as well, whereas the specification prevents you from doing so in any other bean type.

Inconsistent Module State

Another note for posterity.

GlassFish has trouble gracefully recovering from attempting to deploy applications that are badly formed.

Sometimes you get this error:

[#|2013-09-04T12:11:32.903-0400|SEVERE|glassfish3.1.2||_ThreadID=21;_ThreadName=Thread-2;|Exception while loading the app : Error in linking security policy for yourapp -- Inconsistent Module State|#]

This results from GlassFish happily plowing along and generating a security policy in your domain’s generated directory, and then encountering an error, and not cleaning up the partially generated security policy file. That file sticks around for the next deployment, and until you blow it away you will find no peace.

A StackOverflow article covers it, but apparently believes that it is magic. No amount of restarting or otherwise chanting spells over your GlassFish will fix the problem; you have to delete the contents of your domain’s generated directory.