I'm using Hibernate 3.2.0 and HSQLDB. I have a lot (>50) of classes that need persisting, and there is quite some inheritance involved. The classes reside in many different packages, and I think that the packages are part of the problem.

The exception trace I get on when Hibernate loads its configuration is the following:



When I add the package="my.pack.path" attribute for each mapping file to the hibernate-mapping tag, the various nulls in the error descriptors are prefixed with various package paths like null[my.pack.path]. Each mapping file corresponds to exactly one class. I have mapping files for my abstract classes (with abstract="true") and for my leaf classes. I tried with both union-subclass and join-subclass, it has no effect on the error. I use fully qualified names when referring to classes.

Here's a trimmed example of a mapping file for an abstract class:


And for a concrete class:



I've googled for this exception, but all I find are references to the source code of the Configuration class. I've examined the source code but couldn't get any wiser. Just to be sure, I've ordered my mapping files in my configuration file so that superclasses always precede subclasses.

submit a runnable testcase to jira

I looked into the problem myself, and it appears the null originate from org.hibernate.cfg.HbmBinder, on line 2984 (in my version of the source):

final String extendsName = element.attributeValue( "extends" );

It is not checked here that the document contains an extends attribute. Ignoring that possibility will lead to nulls leaking into the metamodel and later propagating themselves into errors.

I suggest placing checks for such possibilities, such as

if (extendsName == null)
{
throw new MappingException("Extends attribute should be defined for subclass, joined-subclass or union-subclass elements.");
}

This class of problems can be prevented by applying "Design by Contract": the extendsName variable is passed on later to another class' constructor, and if that constructor would have checked for null it would have been much easier to track down the problem.

still need a failing test to verify it actually fixes it.

would be great if you could supply that + the suggested patch to our jira