Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Hibernate DTD URI times out/can't be found
PostPosted: Thu Jun 02, 2005 4:59 pm 
Newbie

Joined: Tue May 24, 2005 6:31 pm
Posts: 7
in the typical hibernate configuration XML we have a doctype specification:

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

i am finding that this URI:

http://hibernate.sourceforge.net/hibern ... on-3.0.dtd

times out quite often, intermittently (but regularly) fails to be found. (it also can take a long time to load, making even a simple editor save an expensive proposition, but that's another rant.) this breaks us at XML edit time, this breaks us at test environment startup time, and etc, and the error generated out of the SAX parser at test environment runtime is extremely cryptic.

our IDE is WSAD 5.1.

i want to retain this validation at edit time, but at runtime i would consider it "optional".

i have tried specifying a SYSTEM doctype id, pointed at the local file system (relative to where we want to version the DTD), and at build time i bundle the DTDs into jars where they could be found as resources on the classpath at test environment runtime. however, while this works at XML edit time, at test environment runtime, the SAX parser doesn't seem to want to use the runtime classpath to find these DTDs for validation, it wants to use the test environment's working directory (i.e. the place WSAD runs out of as an IDE application).

so, i thought: just turn validation off at test environment runtime, rely purely on edit-time validation, using our XML IDE and a local copy of the DTD (i.e. change to a SYSTEM id referencing a copy of the DTD versioned right alongside the configuration file). however, i have examined the interface for class org.hibernate.cfg.Configuration, and i don't see a way to do this (turn off validation).

can anyone suggest any sort of workaround? a way to specify (in a DOCTYPE id) a URI on the classpath might work, and i am assuming a way to disable validation at runtime would definitely work. anyway, we need some way to cache this DTD locally, and deploy it with the application without having to jump through hoops, or ignore it at runtime.

thanks.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 03, 2005 9:33 am 
Newbie

Joined: Fri Jan 23, 2004 3:37 pm
Posts: 14
I'm having the same problem. I need to run the application without an internet connection...
The worst part is that I've checked out the hibernate source code. The XMLHelper.createSAXReader method sets validation to true, always.
I think there is no way of cleanly doing this, except setting that flag to false and recompiling Hibernate. But, on every new version, doing it again sucks!
Another way is to put a physical location for the file, like:
<!DOCTYPE hibernate-mapping SYSTEM "file:///mydir/hibernate-mapping-3.0.dtd">, but it wouldn't be possible for me, because I don't know where the app will be installed...
Does anybody know another workarround?
Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 03, 2005 10:04 am 
Newbie

Joined: Fri Jan 23, 2004 3:37 pm
Posts: 14
After some research, I've realized that Hibernate uses a custom DTD entity resolver that gets the DTD's from hibernate3.jar.
On my case, all was a big confusion, because I've decided to test it shutting down the ethernet interface. But I went too deep, because localhost itself couldn't be resolved. When I just plugged out the network cable, everything worked.
But, the question is, for that custom DTD work, you must use the exact doctype declaration suggested by hibernate. If you use, for example, a SYSTEM doctype, it won't work.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 03, 2005 12:22 pm 
Newbie

Joined: Fri Jun 03, 2005 12:13 pm
Posts: 1
Location: Houston, TX
We had the same problem this morning and was breaking our production servers.

The solution to this problem is simple and elegant, what you need to do is parse and build a Document (DOM) and pass this object to the configure() method on the Configuration class.
Doing it this way, you have the opportunity to set the validating() flag on the SAX reader to true or false.

Sample code:

//Create a method for reading your configuration files that returns a
//Document object.

public static Document parseConfiguration(String resourcePath) throws Exception {
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
//Validate DTD only on development environments
factory.setValidating(false); // Don't validate DTD
DocumentBuilder builder = factory.newDocumentBuilder();
return builder.parse(builder.getClass().getResourceAsStream(resourcePath));
}




Then you can do:
.
.
new Configuration().configure(parseConfiguration("myconfig.cfg.xml")).buildSessionFactory();


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jun 03, 2005 5:43 pm 
Newbie

Joined: Tue May 24, 2005 6:31 pm
Posts: 7
HE SHOOTS! HE SCORES! THANK YOU! THANK YOU! THANK YOU!

heh, did not twig to parsing the thing myself, but you are right, it is simple/elegant.

yes, breaking production servers simply because a DOCTYPE DTD could not be served properly would not be fun.

of course, if hibernate's Configuration.configure() method could come in a form that allowed the caller to disable this validation, etc, at runtime, we wouldn't even need to do the DOM assimilation work. we must go through these gyrations basically solely to pass "false" as the validation control, instead of "true". i suppose the form that accepts a parsed DOM model is sufficient, though.

it all works. i will integrate this into our application at some point over the weekend.

thanks again!


Top
 Profile  
 
 Post subject:
PostPosted: Sun Jan 08, 2006 2:39 pm 
Newbie

Joined: Wed Jan 04, 2006 5:29 am
Posts: 4
Hi there,

After all, this is maybe an old thread, but with a subject description that tells it all, and probably, alot of other users with this problem will come to this thread.
I've also struggled this one, found the solution, so I'm happy to add a post.

In your mapping files, you must have the exactly SAME doctype as found in the mapping DTD's.

Then and only then you'll see that the dtd's found in hibernate3.jar can be found through the classpath, and running behind a firewall, stand-alone, etc. will be no problem at all.
No local dtd's in your projects to solve this issue, no code to intercept. :-)

<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">

The same is ofcourse applicable for the configuration file.

HTH, Johan


Top
 Profile  
 
 Post subject: Re: Hibernate DTD URI times out/can't be found
PostPosted: Tue Mar 19, 2013 9:21 pm 
Newbie

Joined: Tue Mar 19, 2013 9:09 pm
Posts: 3
you can try mapping to dtd inside jar on hibernateXXX.jar with the following lines:


Quote:
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"classpath://org/hibernate/hibernate-mapping-3.0.dtd">



it will depends of jar version, but for 3.0 version this should be the solution.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.