¿Cómo puedo almacenar los parámetros de configuración de Java EE fuera de un EAR o WAR?

parameters java-ee

Question

Quiero almacenar la configuración para un proyecto web fuera del proyecto web (archivo ear / war). La aplicación no debe saber en qué contenedor se está ejecutando (WebSphere / JBoss, etc.).

¿Cuál es la mejor manera de manejar esto?

¿JNDI es una forma limpia? Si JNDI puede resolver mis problemas, ¿cómo debo configurarlo? (¿Objetos personalizados?)

En mi caso, solo hay pares Clave => Valor simples (Cadena, Cadena) para puntos finales SOAP / WS.

Answer 1

Consulte esta question para leer el archivo de propiedades fuera del archivo WAR.

Consulte esta question para leer valores de variables de JNDI. Creo que esta es la mejor solución. Puedes leer una variable String con este código:

Context initialContext = new InitialContext();
String myvar = (String) initialContext.lookup("java:comp/env/myvar");

El código anterior funcionará en todos los contenedores. En Tomcat declara lo siguiente en conf / server.xml:

<GlobalNamingResources ...>
<Environment name="myvar" value="..."
type="java.lang.String" override="false"/>
</GlobalNamingResources>

Lo anterior creará un recurso global. También es posible definir un recurso en el contexto de la aplicación. En la mayoría de los contenedores, los recursos JNDI están disponibles a través de una Consola de administración de MBeans. Algunos de ellos ofrecen una interfaz gráfica para editarlos. Como máximo, se necesita reiniciar la aplicación cuando se realiza un cambio.

Cómo se definen y editan los recursos JNDI es específico del contenedor. Es el trabajo del configurador / administrador aplicar las configuraciones apropiadas.

Estos son los beneficios que ofrece JNDI:

• Puede definir valores predeterminados de los parámetros en el archivo WAR / EAR.
• Los parámetros son fácilmente configurables en el contenedor.
• No necesita reiniciar el contenedor cuando modifica el valor de un parámetro.

Answer 2

Mis lugares favoritos son: Variables del entorno y archivos de propiedades (como lo sugirieron Jared y kgiannakakis arriba).

Propiedades del entorno de almacenamiento de la tabla de base de datos

Sin embargo, otra solución más simple es tener propiedades de entorno de almacenamiento de tabla de base de datos.

Si su aplicación usa la base de datos

• esto es relativamente fácil de configurar
• Proporciona una manera realmente fácil de controlar / cambiar valores
• Puede integrarse bien en el proceso haciéndolo parte de las secuencias de comandos DB

Answer 3

Teníamos un requisito de configuración similar cuando implementamos una aplicación web para diferentes desarrolladores, y en EC2 de Amazon: ¿cómo separamos la configuración del código binario? En mi experiencia, JNDI es demasiado complejo y varía demasiado entre contenedores para ser utilizado. Además, la edición manual de XML es muy susceptible a los errores de sintaxis, por lo que la idea se descartó. Resolvimos esto con un diseño basado en algunas reglas:

1) solo se deben usar entradas simples de nombre = valor

2) las nuevas configuraciones deberían poder cargarse cambiando solo un parámetro

3) nuestro binario WAR debe ser reconfigurable sin necesidad de volverlo a empaquetar

4) los parámetros confidenciales (contraseñas) nunca se empaquetarán en el binario

Usar archivos .properties para toda la configuración y usar System.getProperty("domain"); para cargar los archivos de propiedades apropiados, pudimos cumplir con los requisitos. Sin embargo, la propiedad del sistema no apunta a un archivo URL, en su lugar, creamos un concepto que llamamos "dominio" para especificar la configuración a usar. La ubicación de la configuración siempre es:
$HOME/appName/config/$DOMAIN.properties .

Entonces, si quiero ejecutar mi aplicación usando mi propia configuración, inicio la aplicación configurando el dominio a mi nombre:
-Ddomain=jason
en el inicio, y la aplicación carga el archivo:
/home/jason/appName/config/jason.properties
Esto permite a los desarrolladores compartir configuraciones para que podamos recrear el mismo estado de la aplicación para probar e implementar sin volver a compilar o volver a empaquetar. El valor del dominio se usa para cargar .properties desde una ubicación estándar, fuera del WAR incluido.

Puedo recrear completamente el entorno de producción en mi estación de trabajo utilizando la configuración de producción como:
-Ddomain=ec2 que se cargaría:
/home/jason/appName/config/ec2.properties

Esta configuración nos permite tener ciclos dev / QA / release con exactamente un conjunto de binarios compilados, usando diferentes configuraciones en cada entorno. No hay riesgo de tener contraseñas / etc incluidas en los binarios, y las personas pueden compartir sus configuraciones para recrear los problemas que estamos viendo.

Answer 4

Utilizo una variable de entorno para apuntar a una URL (que probablemente sea un archivo: // URL) que tiene mi configuración en ella. Esto es muy simple de configurar y no requiere la infraestructura JNDI.

Aquí hay un código de muestra (mecanografiado desde la memoria: no lo he compilado / probado):

public void loadConfiguration() {
String configUrlStr = System.getenv("CONFIG_URL"); // You''d want to use a more
// Specific variable name.
if(configUrlStr == null || configUrlStr.equals("") {
// You would probably want better exception handling, too.
throw new RuntimeException("CONFIG_URL is not set in the environment.");
}
try {
URI uri = new URI(configUrlStr);
File configFile = new File(uri);
if(!configFile.exists()) {
throw new RuntimeException("CONFIG_URL points to non-existant file");
}
if(!configFile.canRead()) {
throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
}
this.readConfiguration(configFile);
} catch (URISyntaxException e) {
throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
}
}

Answer 5

simplemente puede almacenar, entonces, ¿es un archivo de propiedades java normal que está en la ruta de clase y simplemente cargar las propiedades?

es sencillo y bastante simple ... a menos que me falta algo