Aquí hay algunas prácticas posibles que he usado o encontrado. La combinación de estos generalmente se necesita en la práctica.
Sustituyendo los valores de las variables en conffiles en la construcción de
Aquí hay un ejemplo de cómo se puede hacer esto con Apache Ant. las propiedades de Ant (${var.name}) se pueden controlar con los archivos de configuración de construcción:
<filterset id="variables.to.replace">
<filter token="APPNAME" value="${app.name}"/>
<filter token="WEBAPP-PATH" value="${webapp.path}"/>
<filter token="ENCRYPT-ALGORITHM" value="${encrypt.algorithm}"/>
<filter token="ERROR-MAILTO" value="${error.mailTo}"/>
<!--...-->
</filterset>
<!-- Then, when building & copying the conf, replace the variables: -->
<copy todir="${properties.target.dir}">
<!-- env specific conf files -->
<fileset dir="${basedir}/env/${run.env}/webapp/WEB-INF/classes" />
<filterset refid="variables.to.replace"/>
</copy>
Lo bueno es que se obtiene un control preciso de las diferentes configuraciones en tiempo de construcción. Lo que es malo es que el sistema tiende a volverse muy complejo y difícil de mantener si usa este método extensivamente para un gran número de configuraciones diferentes. Además, tener que compilar los conffiles también significa ciclos de desarrollo más lentos.
Sustituyendo las variables de conf dentro de la guerra en el arranque webapp
Esto es lo que suele hacer cuando se utiliza Spring Framework, incluso si sólo hay una configuración possble, obteniendo los beneficios de la separación de las preocupaciones. Con Spring, puede hacer que los valores conf se reemplacen con PlaceholderPropertyConfigurer dentro del contexto Spring en el inicio de la aplicación web. En este caso, debe elegir la configuración correcta, que se puede configurar, por ejemplo, en el tiempo de compilación.
En comparación con el reemplazo del tiempo de compilación, es más fácil manipular temporalmente los valores en una aplicación web no comprimida, si es necesario. Por supuesto, la aplicación web necesita reiniciarse si cambia algo, y los cambios manuales no persistirán en las redistribuciones de la aplicación de la webapp. Spring también está limitado al contexto de Spring, así que this doesnt' work e.g. in web.xml (pero tener variables en web.xml probablemente se debería evitar de todos modos debido a sus limitaciones).
Lectura de la conf local a partir de un archivo predefinido
Este enfoque es probablemente el más fácil de configurar: acaba de inventar una ruta del archivo de configuración, por ejemplo, $HOME/mywebapp/conf.properties y haga que su aplicación web de alguna manera la lea al inicio.
Lo bueno aquí es que no tiene que preocuparse por la configuración al compilar/implementar la aplicación web. De todos modos, debe tener algunos valores predeterminados de configuración razonables que luego pueden ser anulados por el conf local.
Tener la conf en una base de datos
Ésta es la solución más flexible para sobrescribir los parámetros conf, pero también puede complicarse en algunos casos. Tener el conf en una tabla con name y value columnas debería funcionar para la mayoría de los casos.
Por supuesto, no puede configurar las URL de conexión JDBC en una tabla de base de datos, pero esta es una buena solución para conf simple textual/numical que afecta la operación de la aplicación después de que se haya configurado la conexión db. Para evitar una penalización de rendimiento, asegúrese de almacenar en caché la conf de alguna manera si se accederá con frecuencia.
prácticas adicionales
como ha señalado kgiannakakis, sino que también ayuda a crear una página de configuración de diagnóstico de algún tipo para su aplicación.
Respuestas relacionadas: http://stackoverflow.com/questions/1634458/can-i-use-a-single-war-file-in-multiple-environments-should-i – McDowell
JNDI (java.sun.com/ products/jndi) fue creado específicamente para resolver este problema, y es lo que normalmente uso para los sistemas de producción, ya que se escala bien (funciona ya sea que tenga 1 entorno o 6). También separa claramente las responsabilidades del desarrollador y del administrador del sistema. Dicho esto, si sabes que solo tendrás 6 entornos, y ese número casi nunca cambiará, la solución de Jeremy debería funcionar, y creo que es lo que usan las convenciones más nuevas sobre los marcos de configuración (por ejemplo, Grails). –
Dicho sea de paso, la configuración JNDI requerirá una configuración manual, pero solo lo hará una vez por entorno (algo así como instalar el servidor de la aplicación o el sistema operativo del entorno). –