java - datos - Configure Tomcat para usar el archivo de propiedades para cargar información de conexión de BD

que es un pool de conexiones en java

Question

¿Cuáles son las prácticas aceptadas para crear una implementación de Tomcat que lee los parámetros de configuración de un archivo de propiedades?

Sería bueno poder entregar un archivo WAR y especificar que el cliente solo necesita crear o editar un archivo de propiedades en un directorio específico. ¿Es esta una forma algo regular de hacer las cosas? ¿Hay un mejor enfoque que esto?

Answer 1

Es una buena práctica almacenar la configuración fuera de la zona de guerra. En nuestra GUERRA, tenemos una ubicación predeterminada para buscar el archivo de propiedad. Si el valor predeterminado no funciona, puede especificar la ubicación a través de un parámetro JVM o un parámetro de contexto definido en el fragmento de contexto en el directorio conf / Catalina / [host]. Por ejemplo,

<Context docBase="/server/app.war"
swallowOutput="true" unpackWAR="false" useNaming="false">
<Parameter name="config-file" value="/config/db.properties" override="true" />
</Context>

Answer 2

La forma en que manejamos esto:

1. Haga que el cliente cree un grupo de conexiones en GlobalNamingResources usando un nombre de recurso en el que estamos de acuerdo. El controlador de la base de datos debe estar en el classpath de Tomcat.
2. Nuestro archivo war incluye un archivo META-INF / context.xml que tiene un enlace ResourceLink al grupo de conexiones configurado en el paso 1.

Este es un trabajo un poco más adelantado que simplemente alterar la información de conexión context.xml directamente, pero con el tiempo debería dar sus frutos. Un servidor de desarrollo se configuraría con GlobalNamingResources apuntando al desarrollo y un servidor de prueba para probar, etc. Luego, el mismo archivo WAR se puede copiar en cada servidor sin editar nada.

Esto no usa archivos de propiedades, pero creo que logra el mismo objetivo. Permitir que un usuario / cliente configure la información de conexión de la base de datos.

Ejemplo de GlobalNamingResource:

<Resource name="jdbc/dbconnection" auth="Container"
type="javax.sql.DataSource" driverClassName="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:@127.0.0.1:1546:SID"
username="scott" password="tiger" maxActive="8" maxIdle="4"
validationQuery="select 1 from dual"
testOnBorrow="true"/>

Ejemplo de context.xml en el archivo war:

<Context path="/MyWebApp" docBase="MyWebApp" debug="5" reloadable="true">
<ResourceLink name="jdbc/dbconnection" global="jdbc/dbconnection"
type="javax.sql.DataSource"/>
</Context>

Answer 3

A menudo distribuimos webapps al proporcionar un GUERRA y un archivo XML de contexto, que se coloca en el directorio tomcat/conf/Catalina/localhost , y puede cargar la aplicación web desde cualquier ruta. Hay un documento de referencia here . Esto proporciona las siguientes ventajas:

• Los parámetros de contexto se pueden configurar aquí y leer por la aplicación web
• DataSources se puede definir y configurar aquí
• El WAR puede vivir en cualquier lugar del sistema de archivos, lo que significa que si Tomcat se actualiza, solo este único archivo de configuración debe trasladarse a la nueva instalación de Tomcat, la aplicación web y cualquier otro archivo pueden permanecer donde están.

Si realmente desea un archivo de propiedades, puede establecer un parámetro en el archivo XML de contexto que apunta a su archivo de propiedades, leer el parámetro en un ServletContextListener y luego leer en el archivo de propiedades.