Imagine you are testing services registered on an ESB. That ESB allows deployment of services as EJB’s. There’s something important about that fact. By default, different EJB’s run with their own class loader. You can dig into the EJB spec if you’d like, but there’s roughly a hierarchy of 5 class loaders by the time you get to an executing EJB (can be more, could be less).

Why is this important? If two EJB’s make reference to the “same” JAR file, then each could get loaded by the same or a different class loader. If the JAR file is installed high in the class-loader hierarchy, then they will be loaded by the same class loader instance and therefore will be the same classes.

However, let’s assume that each EJB represents ones service. Furthermore, each EJB makes a reference to some JAR file directly, that is, it is not visible to a hierarchically higher class loader. Then that same JAR file will get loaded twice, once by each class loader (this really happens), and those exact same classes will be considered different.

That’s right, the exact same JAR file loaded by 2 different class loaders are treated as unrelated classes.

In reality, each deployed EJB is “complete” in that in includes the JAR’s it needs to execute. So the “same” jar – same in terms of file contents – exists twice in the system and is loaded by two class loaders.

Now, it gets a little worse. Those two EJB’s work off a “common” data model. Common in that the underlying business objects are common across a set of applications. However, the common data model is a moving target (it’s grown as needed). To manage complexity, not all services are forced to update to the latest version of the common data model at the same time (it’s not really a manageable solution – generally).

So now we have 2 (really several) EJB’s that refer to logically the same JAR but different versions. Luckily, this is no problem because each EJB has its own class loader, so it is OK for 2 EJB’s to refer to different versions of the same logical data model.

How does any of this have anything to do with FitNesse? When FitNesse executes a suite, by default all tests are executed in the same VM with one class loader. So if you have a suite of tests that test different services, each of which might be using a different version of the common data model, then the first service executed loads the common data model, which really isn’t exactly common. This causes tests to fail that would not fail if each text executed with its own class loader.

Rather than deal with writing custom class loaders, Bob instead make it possible to name a VM (see the title for the syntax). By doing this, Bob make it possible to effect a similar environment to that experienced by EJB’s by default.