Read the rules before posting!
http://www.hibernate.org/ForumMailingli ... AskForHelp

Hibernate version:

3.0final

summary

I am using Swing and Hibernate and am extremely happy about it, but there is one small problem. Configuration.addFile(File) opens an InputStream and hands that off to the parser, making it impossible to specify a relative DOCTYPE in the declaration. It's also not possible for our servers to download the dtd, because of classification restrictions these machines are unable to connect to the internet.

Some relevant info:

mapping file

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 1.1//EN"
"./hibernate-mapping-3.0.dtd">

[perfectly legal mapping file]


Configuration code from CVS-HEAD as of 2005-04-18

public Configuration addFile(File xmlFile) throws MappingException {
//log
try {
addInputStream( new FileInputStream( xmlFile ) );
}
catch ( Exception e ) {
//snipped exception handling
}
return this;
}

Because an inputstream is passed into the SAXReader it's impossible for that parser to find the relative dtd that's sitting next to the mapping files.

The addFile(String xmlFile) would work because this is what it does:

org.dom4j.Document doc = xmlHelper.createSAXReader( xmlFile, errors, entityResolver ).read( new File( xmlFile ) );

Problem is that I can't call this method, because Spring uses the addFile(File xmlFile) method (as it should IMO). I also don't really want to drop the DOCTYPE declaration, as it is a very valid check that the parser can do to ensure everything works properly and doesn't break later.

my suggestion would be to change the addFile(File xmlFile) to use the org.dom4j.Document doc = xmlHelper.createSAXReader( xmlFile, errors, entityResolver ).read( xmlFile );

line and make addFile(String xmlFile) use :

addFile(new File(xmlFile) );

That way that are a) consistent and b) able to dereference relative URIs in DOCTYPES

I am unable to provide patches now, because our development machines don't have internet access, but I can do so tonight at home. I can also probably write up a unit test that replicates this issue, if you want to.

Thanks,

Erwin

Dug around some more.. and while the above solution will solve the problem I have found something else. Only the latest mapping dtd (3.0) is included in the release and is resolvable.

XDoclet, which I use to generate the mapping files, outputs 1.1 mapping dtd.. That's where it goes wrong..

When I add an ant replace in my buildfile to substitute 3.0 for 1.1 in my mapping files it works like a charm again, cause the DTDResolver is now able to find the dtd in the hibernate jar.

So another solution would be to add the other dtds to the jarfile, the DTDResolver should be able to find them automatically then.