-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Hibernate O/R XML files
PostPosted: Fri Mar 02, 2007 12:40 pm 
Newbie

Joined: Tue Feb 06, 2007 2:50 pm
Posts: 4
Hi
Can the hibernate O/R XML files that define the relationship between POJOs and schema be outside the application war file?. This is to required to allow the end user to change the mapping to some different schema, without the need to rebuild the war file? Pls describe where should those files be kept, any other tweaking needed to accomplish this?

thanks
RK


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 05, 2007 3:56 am 
Expert
Expert

Joined: Tue Dec 28, 2004 7:02 am
Posts: 573
Location: Toulouse, France
Just remember what you need as a foundation to your hibernate use: build a SessionFactory object. From this one, you then will be able to create the session objects that you need to execute queries and so on.

You're going to need to create the Configuration programmatically:
Code:
cfg = new Configuration();
cfg.addDirectory(yourFile));
...
cfg.setProperty("hibernate.dialect", "org.hibernate.dialect.YourDialect");

Then, create a SessionFactory:
Code:
SessionFactory sessionFactory= cfg.buildSessionFactory();

And you're done :-)

_________________
Baptiste
PS : please don't forget to give credits below if you found this answer useful :)


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 05, 2007 5:15 pm 
Newbie

Joined: Tue Feb 06, 2007 2:50 pm
Posts: 4
batmat wrote:
Just remember what you need as a foundation to your hibernate use: build a SessionFactory object. From this one, you then will be able to create the session objects that you need to execute queries and so on.

You're going to need to create the Configuration programmatically:
Code:
cfg = new Configuration();
cfg.addDirectory(yourFile));
...
cfg.setProperty("hibernate.dialect", "org.hibernate.dialect.YourDialect");

Then, create a SessionFactory:
Code:
SessionFactory sessionFactory= cfg.buildSessionFactory();

And you're done :-)



Thanks for the response. I read the following in the documentation
An alternative (sometimes better) way is to let Hibernate load a mapping file using getResourceAsStream():

Configuration cfg = new Configuration()
.addClass(org.hibernate.auction.Item.class)
.addClass(org.hibernate.auction.Bid.class);
Then Hibernate will look for mapping files named /org/hibernate/autcion/Item.hbm.xml and /org/hibernate/autcion/Bid.hbm.xml in the classpath. This approach eliminates any hardcoded filenames.

A Configuration also specifies various optional properties:

Properties props = new Properties();
...
Configuration cfg = new Configuration()
.addClass(org.hibernate.auction.Item.class)
.addClass(org.hibernate.auction.Bid.class)
.setProperties(props);


So going with that, I can get ensure that the user puts hbm.xml mapping files in the classpath. The user can thus change the mappings if it decides to use another database. But what about the hibernate.cfg.xml. Your solution above is putting the dialect etc directly in the source code which the end user wont have access to. Remember, the problem that we are trying to solve is the following :-

Today, the end user uses mySQL database but tomorrow he may switch to Sybase. I dont want to recreate the war file then. The hibernate XML files have to be outside the war file so that the user can simply change the db information and the O/R mappings.

thanks
RK


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 05, 2007 5:30 pm 
Newbie

Joined: Mon Mar 05, 2007 4:58 pm
Posts: 4
The WAR file is your application, where else would you ever put files? If you need them outside of your WAR then you'll probably need to access files that are not within the container which is not suggested. You could always put them in a JAR file that is in WEB-INF/lib and just rebuild the JAR file instead of having to rebuild the WAR.

You're going to have to rebuild the SessionFactory when a change is made to a mapping file, so you'll probably want some elegant way to do that aside from restarting the App Server.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 05, 2007 5:37 pm 
Newbie

Joined: Tue Feb 06, 2007 2:50 pm
Posts: 4
ironclay wrote:
The WAR file is your application, where else would you ever put files? If you need them outside of your WAR then you'll probably need to access files that are not within the container which is not suggested. You could always put them in a JAR file that is in WEB-INF/lib and just rebuild the JAR file instead of having to rebuild the WAR.

You're going to have to rebuild the SessionFactory when a change is made to a mapping file, so you'll probably want some elegant way to do that aside from restarting the App Server.


Are you saying that after the war file is deployed, just change the XML files and jar them and put the new jar file under WEB-INF/lib location under the deployed war file location?

I dont quite understand how hibernate could be useful at runtime. I understand that one could change the XML files and rebuilt the war file but if we have to do it at runtime or deploy time without rebuilding the war, whats the best way. The reason for this question is that I create an application that is using mySQL but the customer maynot want to use mySQL and may have Oracle schema already in place and they would like to simply use it with my applicaiton. Is this a weird requirement?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 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.