I'm a big fan of how Ruby on Rails separates database configuration into (at least) 3 different environments: test, development, and staging. In each case, you specify a different host, database, username, and password. Rails determines which one to use based on an environment variable RAILS_ENV.

I would like to do that with a Hibernate-based app I'm working on, and I'm wondering if anyone has any advice.

I'm planning to deploy my app using Ant. I package everything up into a .jar then scp it to the remote server where it runs (it's actually not a web-app).

Is anyone else doing something similar. There are a few ways I could approach this, but I want to know if there's a standard way that everyone does it.

Thanks,
Micah

Hi,

Ideally you can use JNDI name in hibernate.cfg.xml by giving name to sessionfactory (e.g., <session-factory name="hibernate/MySessionFactory">). Whenever Hibernate loaded, it looks for the database with above JNDI name. And I am sure you use a JNDI name for your database in test, dev and stage environments.

2nd option: When you configure Hibernate from HibernateUtil class, you have to manually load the configuration (hiberbate.cfg.xml) per environment. Then you have to maintain 3 different files like hibernate_dev.cfg.xml, hibernate_test.cfg.xml and hibernate_stage.cfg.xml (I hate this one!!!!)

Other option: Just maintain one configuration file. But in your HibernateUitl class, when load the configuration supply the database properties.



Here you read the dbURL, user, password for your environment. And env is supplied from your ant script or what ever source.

Hope this helps!!!!

Thanks

The last option (single config with values supplied in environment) is pretty much what I'm thinking. The other option, assuming it works, is a single hibernate.cfg.xml, but also a hibernate.properties. That file is not in svn and contains all the host, user, password type stuff. It has to be copied or created manually. That's pretty much how Rails does stuff.

Thanks for the quick reply.

This looks like it will work best for me, based on my needs. However, it will lead to many config files that must be managed and they will be the same (apart from the DB connect data and 1 or 2 props). I hate this too!

Something more maintainable would be a way to overlay properties/config. I.E. Load a general default config file and update a few properties...



This looks interesting. Can I do something like this (assuming valid files, paths, etc.)?



Thanks!