my favourite:
define a java propery in the startup line of the server

java -Dconfig.dir=c:/config [server-specific-startup]

- if there is no config.dir, use senseful defaults
- the directory differs for development / production
- put all external configuration files for your apps in there
- not so nice: read the values on startup using e.g. context listener
- better: inject the config file values in your services with hivemind

the configuration possibilities of j2ee are, in my opinion, 
bullshit and are not related in any way to real life...

Best regards
Peter


> --- Ursprüngliche Nachricht ---
> Von: Johan Maasing <[EMAIL PROTECTED]>
> An: Tapestry users <tapestry-user@jakarta.apache.org>
> Betreff: Re: [~OT] configuration management in tapestry (aka testing
> vs    production)
> Datum: Tue, 04 Oct 2005 20:40:02 +0200
> 
> Dan Adams wrote:
> > I was wondering what people ways people have found with tapestry to make
> > launching a .war easier? For instance in my app I test locally using
> > jetty but then have a server that releases get put on at the end of
> > every iteration. Here is an example of what would need to change:
> > 
> > - email address of support staff. right now they go to me and are stored
> > in the main property file but it would nice to have another property
> > file of the real values that gets swapped in
> > - the database connection info
> > - enabling/disabling certain features in the system based on whether it
> > is development or production
> > 
> > I'm just curious about some of the ways that people have done this.
> > Thanks. :)
> 
> Check out the servlet specification and look for env-entry (for example 
> chapter 13 of servlet 2.4). Most J2EE servlet containers lets you 
> override the values provided in web.xml in the war-file. How this is 
> done is different between the containers (tomcat can have configuration 
> in the conf/Catalina/localhost directory, weblogic have weblogic.xml et
> c.).
> Why implement your own configuration framework when the servlet 
> specification already provides it :-)
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to