Steve Ebersole let me try to put each thing into context.

The issue here was that targetEntity class were not being loaded correctly due to bad ClassPool setup. The enhancer needs to load the class in order to validate the association, or else javassist will throw an exception when compiling.

It is assumed that entities that have a bi-directional association are both being enhanced, and therefore both are in the class path. If that is not the case, then the association management feature has to be disabled.

Now, regarding your comment, the enhancer takes targetEntity into account. The class to load is found in the same way that it's use on the Metamodel construction. It does not reuse the code just because the enhancer works on javassist CtClasses instead of JVM's Classes, but the logic is exactly the same.

Having to build the entire Metamodel before enhancing may be overkill IMO. There are a few bits that are needed here and there, like the ones added in this case, but generally the enhancer would have only to deal with a tiny fraction of the data in the model, and doesn't care much if it is valid or not. The way I see it both have separate concerns, but that is certainly open to discussion.