Here is how my hibernate.cfg.xml looks like
--------------------------------------------------

<!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">
<hibernate-configuration>
<session-factory>
..............
</session-factory>
<hibernate-configuration>

And here is the error eclipse reports to me:
--------------------------------------------------
Referenced file contains errors (http://hibernate.sourceforge.net/hibern ... on-3.0.dtd)
For more information, right click on the message and select "Show Details"

And here is what i get after "Show Details"
------------------------------------------------

The errors below were detected when validating the file "hibernate-configuration-3.0.dtd" via the file "hibernate.cfg.xml".
In most cases these errors can be detected by validating "hibernate-configuration-3.0.dtd" directly.
However it is possible that errors will only occur when hibernate-configuration-3.0.dtd is validated in the context of hibernate.cfg.xml.

The markup declarations contained or pointed to by the documet type declaration must be well formed
------------------------------------------------

Despite the error, my application works fine. This is one of the first times I use Hibernate. If you have any suggestions please let me know.
Wating for your answer I thank you in advance everyone.

I am also getting the same issue. Can anyone answer?

I am getting the same thing - gets triggered any time I modify any of our xml files that reference this dtd. Was working fine yesterday if that helps narrow down the problem.

I had the same issue.
Found a solution and registered to post it

replace all


and


the files are still accesible from either domain but eclipse seems to have problems with the domain redirection

This works, as far as Eclipse is concerned, but what I find when I made the change is that the opposite is the case on the server. The sourceforge dtd urls are accepted there, the hibernate.org ones are not!

Caused by: org.hibernate.HibernateException: Could not parse configuration: /hibernate.cfg.xml
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1542)
at org.hibernate.cfg.Configuration.configure(Configuration.java:1476)
at com.att.relay.db.HibernateSessionBroker.initialize(HibernateSessionBroker.java:171)
... 9 more
Caused by: org.dom4j.DocumentException: Connection refused Nested exception: Connection refused
at org.dom4j.io.SAXReader.read(SAXReader.java:484)
at org.hibernate.cfg.Configuration.doConfigure(Configuration.java:1532)
... 11 more


Aaarrggggghhhh! What the #$%%^^&* is Hibernate doing and why isn't there a simple fix for this?

Yep - we just ran into this as well - I had noticed that it was taking a really long time within my test standalone application running in Eclipse to intialize Hibernate from its cfg file. It would eventually succeed there - but took a MUCH longer time - so it appears there were network io issues even from a standalone app in Eclipse debugger.

Then when we went to try and run with the ears build from this same code and run it on our server, we got timeouts within the parser when the configuration was being loaded.

So apparently the connections being attempted are getting refused.

Need a fix to this - for now I guess I will have to revert all of the config and mapping files back to the url that causes Eclipse to complain. But at least it will run!

All of this started for me when they had their major site outage last week.

Well, I reverted my config files back to the old DOCTYPE reference and now they work in both places, my server and from Eclipse. Evidently, this may now have been mostly fixed.

I say mostly fixed because here is what still does not work: one used to be able to paste http://hibernate.sourceforge.net/hibern ... on-3.0.dtd into a browser and view the DTD as text. That still doesn't work. One can only download it and then view it with some other program.

This incident does point out an outrageous single point of failure in the whole Hibernate system. This should just not be happening. Tested configuration files do not need to be validated every time they are run. Is there a way to disable Hibernate's use of a validating parser?

Furthermore, I would criticize Hibernate's lack of communication to its user base during this outage. There should have been a prominent notice on the main Hibernate.org website about this outage for its entire duration. The user base should not have been forced to Google for solutions and pass non-authoritative suggestions around this forum. This response was not worthy of Hibernate's mostly well-deserved reputation for reliability.

I recognize the possibility that I may have been doing something wrong, though I have no idea what, if anything that might be. Such information, if it does exist, should have been posted on the outage response page that should have existed but didn't.

Hopefully, hibernate.org will learn something from this.

Yes - I could not agree more. If you are going to have this sort of dependency baked into the code - then you had better communicate clearly when there are going to be outages or better yet have enough redundancy in place to eliminate the outage altogether.

Like you I would love to know if there is a way to turn off the validation. The other way around this I think is to change the reference in the xml files to point to a dtd on your local file system. I was able to get that to work when running a test application in Eclipse but I have not actually built and deployed an ear file using that technique - so I am not sure how well that would work on the server.

I just tried to do validation against the dtd in Eclipse and it still gives the same error as before using the sourceforge url. I don't think anything has really been fixed there.

In addition, I see this statement in the Hibernate docs - which is clearly not correct:

'Hibernate DTD is sophisticated. You can use it for auto-completion of XML mapping elements and attributes in your editor or IDE. Opening up the DTD file in your text editor is the easiest way to get an overview of all elements and attributes, and to view the defaults, as well as some comments. Hibernate will not load the DTD file from the web, but first look it up from the classpath of the application. '

The statement above would lead you to believe that as long as the hibernate jar is on the application's classpath - that the dtd will be loaded from there. But there must be a bug in that because it is clearly NOT loading the dtd from the classpath.

This is running Hibernate 3.3.1 GA

Hmm. It still works for me. Apparently everything depends upon some obscure proxying settings that are nowhere explained.

I would agree with you about the classpath.

BTW, I am using 3.3.2.GA of Hibernate.

OK - I think I have figured out the issue. Since we are at 3.3.1 - the correct url that is being used for the classpath lookup is based on the documented url at the time 3.3.1 was built - which is the sourceforge url. So when we changed the path in our dtd - that caused the classpath lookup being done to fail - and caused the Hibernate code to have to look it up via the http url. Because our servers are behind a firewall dmz zone which blocks those flows - the lookup failed. When I was running it on my local test server - the lookup worked because port 80 out to that site is not blocked on my machine. However it was excruciatingly slow - taking several minutes to instantiate a configuration from our cfg file because we have a significant number of separate mapping xml files.

So bottom line - until we upgrade our Hibernate to a later version where the url is changed to the www.hibernate.org domain - we need to keep our mapping files as they are.

That still does not explain why Eclipse is having issues. The funny thing is - I edited one of the files on my system and Eclipse did not have a problem validating it - the red x went away. But others that I edit - that does not happen. So looks like it is not 100% predictable failure - but for me it still looks like a failure most of the time. Again - just a validation issue within Eclipse and not a runtime issue that I can tell.

This problem seems to be caused by the network resource cache of Eclipse. So as a workaround, simply delete the entry "hibernate.org" in the cache (Windows / preference / General / Network Connections / Cache)