you can read a more detailed description here: http://hombisblog.blogspot.com/2009/11/switching-between-stage-production-db.html
with regards Sven Homburg Founder of the Chenille Kit Project http://chenillekit.codehaus.org 2009/11/16 Sven Homburg <hombu...@googlemail.com> > why dont write your own HibernateConfigurer like this > > public class ApplicationHibernateConfigurer implements HibernateConfigurer > { > private final Properties extraProperties; > > public ApplicationHibernateConfigurer(Properties extraProperties) > { > this.extraProperties = extraProperties; > } > > public void configure(Configuration configuration) > { > configuration.addProperties(extraProperties); > configuration.configure(); > } > } > > and let IOC build it like this > > public static HibernateConfigurer > buildApplicationHibernateConfigurer(@Inject @Symbol("appl.config.dir") > String applConfigDir) > { > Resource resource; > Properties properties = new Properties(); > > try > { > String fileName = applConfigDir + "/hibernate.properties"; > File file = new File(fileName); > if (!file.canRead()) > throw new RuntimeException(String.format("can't read file > '%s'", file.toURI())); > > resource = new URIResource(file.toURI()); > properties.load(resource.openStream()); > } > catch (MalformedURLException e) > { > throw new RuntimeException(e); > } > catch (IOException e) > { > throw new RuntimeException(e); > } > > return new ApplicationHibernateConfigurer(properties); > } > > > > with regards > Sven Homburg > Founder of the Chenille Kit Project > http://chenillekit.codehaus.org > > > > > 2009/11/16 Joost Schouten (ml) <joost...@jsportal.com> > > +1 for external conf file. It has made my life much better ;-) >> >> We have implemented this with Spring. The nice thing here being that you >> can provide meaningfull default values on classpath property files and >> override what you need from your external ones. >> >> Cheers, >> Joost >> >> >> Ville Virtanen wrote: >> >>> Hi, >>> >>> we use our custom configuration file that reads everything from single >>> file. >>> The application reads a system property that defines the location of the >>> conf file. This way, the jar and build process is the same for every >>> environment and the deploy procedure is just to copy the war to the >>> server >>> (prod, pilot, internal test, demo etc..) >>> >>> Also, this enables us to run our software in the mode we choose in every >>> environment: if we need to run in debug or development mode in production >>> that we indeed can. Also the log4j conf is read from outside the >>> war/exploded war, so that conf is also out of the build cycle. >>> >>> The only downside is that we have to define the single configuration key >>> to >>> catalina_opts or similar, but this setup has proven to be useful for us: >>> even the new guy can deploy to any environment, as the procedure is >>> always >>> similar and there is no checklist ;) >>> >>> Quick solution is to determine the wished configuration from the >>> production >>> mode flag. >>> >>> - Ville >>> >>> >>> Alessandro Bottoni-4 wrote: >>> >>> >>>> Hi All, >>>> I'm almost completely new to Tapestry and Hibernate so, please, be >>>> patient.. >>>> >>>> In your opinion, what's the best (simplest/most-maintainable) way to >>>> deal with two different databases with T5 and H3? >>>> >>>> I have the classical stage/production environment with the same software >>>> (and the same RDBMS) on the two machines but two different data sets and >>>> I have to switch from the one to the other when deploying the T5 stuff. >>>> >>>> Is it better to rely on the mechanisms provided by Hibernate (loading >>>> different configuration files, for example) or is it better to use some >>>> Tapestry-specific trick? >>>> >>>> How do you do that, usually? >>>> >>>> Thanks in advance for your attention. >>>> >>>> -- >>>> >>>> Alessandro Bottoni >>>> Website: http://www.alessandrobottoni.it/ >>>> >>>> "In mathematics you don't understand things. You just get used to them." >>>> -- John von Neumann >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>>> >>> >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> >
