Hibernate version:
HibernateEntityManager 3.3.1-GA, 3.3.2-GA, & 3.4.0.CR1

Apologies if this is the incorrect forum to e-mail about potential issues with hibernate code. I've been looking at the PersistenceXmlLoader class in src\org\hibernate\ejb\packaging\ and there may be a memory leak whereby an InputStream is instantiated and never closed.

As "docBuilder.parse( source )" may throw an IOException or SAXException, I propose that the end of the method be wrapped in a try/finally block where the InputStream will be closed like so to ensure that the stream is closed.

try{
InputSource source = new InputSource( is );
DocumentBuilder docBuilder = docBuilderFactory.newDocumentBuilder();
docBuilder.setEntityResolver( resolver );
docBuilder.setErrorHandler( new ErrorLogger( "XML InputStream", errors, resolver ) );
Document doc = docBuilder.parse( source );
}
finally{
is.close();
}
if ( errors.size() != 0 ) {
throw new PersistenceException( "invalid persistence.xml", (Throwable) errors.get( 0 ) );
}
return doc;
//end of method

}

Is this a problem and should I report this to the hibernate JIRA?

Updated: Changed title to "resource leak" instead of "memory leak", added reference to 3.4.0.CR1.

Here's some more background on this, as part of my job I have to do code reviews of Open Source components that my group supplies for internal use at my place of work. With Hibernate we found a few potential issues, most of which we able to determine were non-issues, the only one outstanding is the one I reported above.

Following the procedure at http://www.hibernate.org/217.html about opening JIRA's it stated that one should first ask here on the hibernate-users forum.

I'd be interested in getting feedback from the hibernate devs about this, and if the code changes I'm suggesting are warranted or not. If I don't get any feedback in the next couple of days I'll open a JIRA on this.

Many thanks
Mick

Indeed, classloaders can cause the most annoying of problems. Without putting the file on the classpath of the classloader for the object reading the file, you're in trouble.

Managing classloaders in a complex enviornment isn't easy. This doesn't sound like an easy bug to fix. There's no way that you could manage the file so that it's in multiple places at once, is there? As such, the classloader in question would be able to find it. Not a great fix, but rather a shot in the dark suggestion.

I've been digging through the code some more and reading lots of hibernate documentation, and I'm thinking that this is a very small issue, in that the code is only used to read in the persistance.xml file.

Would I be right in saying that this would happen only once per application or per JAR file containing entity beans that need to be persisted? Which means that there would a very limited number of InputStreams created?

Cameron thanks for your response.

This turned up as a potential issue in a Fortify scan we did of the hibernate components and it got flagged as a (potential) issue. It there any more detail I can provide, and should I open a JIRA on this?