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
>
>
