I would like hibernate to accept a hibernate.cfg.xml file WITHOUT any <mapping ...> elements. My understand of its DTD spec states at least one such element must exist inside the <session-factory>.

I would be happy to configure hibernate completely programatically, or disable the DTD checking of the SAX parser from a property value ?

The reason for this is because I am using the addCachableFile() API call to add my mappings. Therefore mappings do existing within the Configuration object of hibernate, I just want to boot it up without having to put a dummy one in the hibernate.cfg.xml to shut up the DTD syntax error.


I would also be interested to know (if a developer reads this) if it would be possible to completely serialize the internal state of every hibernate runtime object, such that it would be possible to call a "freeze" function to save the serialized form and a later "thaw" function to reload upon re-redeployment of the application.

Maybe a new configuration constructor class could be developed (i'll volunter if someone can put me on the rails) that understood the whole process step by step and would do it in such a way to be able to freeze and thaw a configuration.

I'm sure this one feature would save thousands of developers many hours a week.

Maybe a new forum poll should be started, how many minute a week do you spend waiting for Hibernate to build a session factory ?

1) more than 2 hours ?
2) more than 30 minutes ?
3) more than 10 minutes ?
4) less than a minute ?
5) I never wait for it, I use the time to start hacking on another project.
6) I love waiting for it, the boss thinks I'm still working!
7) Euh! session factory ?

eh - the requirement of mappings in cfg.xml has changed waaay back - please check with later versions of hibernate before writing looong requests ;)

Serialization of SessionFactory we have tried to do a couple of times - but it always comes down to us waiting on classloading and impossibility of serialization of stuff without introducing extra synchronization stuff (which would mean slower performance at runtime and more complex code)

/max

btw. the whole Configuration can be saved if you want to ...its "just" the SessionFactory that gives the impact.

Ah ha.. thanks for that pointer I was using 3.0.5 with http://hibernate.sourceforge.net/hibern ... on-2.0.dtd not http://hibernate.sourceforge.net/hibern ... on-3.0.dtd. I must have upgraded all my files twice before and still an old one turns up.

A suggestion for consideration, a single warning emitted once if an inferior DTD spec is found to be used. Nothing alarming (as there is no problem), something to encourage investigation into the matter with a view to get the developer make a decision to upgrade or ignore.

"Found older DTD hibernate-configuration-2.0.dtd in use in file xyz.xml"





Can you point of off in the general direction of the previous attempts ? I'm not looking to change the production code path in any (big) way, the production version keep nice fast and optimized for usage (not SessionFactory building).

But I am interested in the possibility of an alternative implementation of the SessionFactory what would allow runtime state freeze/thaw.

I'm happy with a really slow construction speed of this new class on the basis that I will get a much bigger speed boost from the fact it does not need to do all the work at every deployment, this new class would only benifit the development process and optimized for SesisonFactory building over performance.

Obviously I dont really understand the issues you point out at this time, so would like to experiment starting with getting a better understanding those issues please.

Where do I look.

Darryl

The log already prints when you use a DTD that is not in the hibernate.jar - and beaware that using hibernate-configuraiton-2.0.DTD will definitly also slow down your startup since it needs to download it from the net!

Pointers to existing attempts ? Try searching the devel list for "serialization" and "sessionfactory".

It is not about writing a new SessionFactory, it is about updating all the classes it contains to be able to be serialized - so good luck ;)

You simply just start by marking SessionFActory serializable and then try and save an instance of it ... then you will get an exception stating something about what is not serializable, make that serializable - and then repeat the exercise until you dont get any exceptions ;)

I think I have standard logging level enabled with 3.0.5 installed. Maybe I have stupidly disabled something but I can't see any log entry. Which source file/line would be responsible and I'll trace its execution on my setup and report back.






I've just picked up on your devel-list threads...

Is there any millage with allowing me to do away completely with a hibernate.cfg.xml to exist if I were to somehow tell Hibernate that I know what I'm doing, I've configured my JDBC programatically and added my mappings programatically, so my hibernate.cfg.xml would be emtpy anyway, so please skip looking for it ?

ah sorry - the DTD warning in the current releases are at DEBUG level - in cvs there have been added an additonal ERROR log if your DTD contains a "2.0"

Regarding making hibernate ignore hibernate.cfg.xml (dont understand why, since it can just contain properties) call configure(document) with an empty document

I'm just clutching at this being a performance hit, maybe the DTD loading and checking is adding an overhead. Thinking that just trying to work with XML in any way is a hit.
I've tried configure(new Document()) but the answer doesn't seem as trivial as that.

no the document should at least contain a valid hibernate.cfg.xml document - which can be empty.