¿Se puede construir un archivo .war con bibliotecas 8.4 y 9.0 postgres (hibernación)?

Question

que hemos estado usando dependencias de Maven para especificar las bibliotecas hasta ahora, es decir:

<dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-core</artifactId> 
    <version>3.6.10.Final</version> 
</dependency> 
<dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-c3p0</artifactId> 
    <version>3.6.10.Final</version> 
    <type>jar</type> 
    <scope>compile</scope> 
</dependency> 
<dependency> 
    <groupId>postgresql</groupId> 
    <artifactId>postgresql</artifactId> 
    <version>8.4-702.jdbc4</version> 
</dependency> 

Sin embargo, ahora estamos corriendo el mismo archivo .war exacta en diferentes máquinas, y le gustaría mantener el mismo One- war-file-to-rule-them-all, pero no desea atacar problemas utilizando un controlador anterior en una instalación de postgres 9.1 (especialmente cuando los valores predeterminados de la codificación de array byte han cambiado, por ejemplo). Cliff-Claven esque como información que probablemente no importará, pero agregó de todos modos: el sistema operativo para ambas instalaciones son Mac OS X Server, Postgres 8.4 uno se ejecuta en 10.6, el 9.1 uno se está ejecutando en 10.7. No tenemos necesidad de actualizar ningún dato (instancias separadas comenzaron desde cero).

Quizás es más una pregunta maven que otra cosa, pero no pude ver nada específico de mi situación. Encontré this, pero es Hibernate 3.5 anterior que ya no se aplica.

Answer 1

Para PostgreSQL, la última versión del controlador JDBC se debe usar independientemente de la versión del servidor, excepto en el caso de las versiones verdaderamente antiguas.

http://jdbc.postgresql.org/download.html#current dice:

Esta es la versión actual del controlador. A menos que tenga requisitos inusuales (ejecutando aplicaciones antiguas o JVM), este es el controlador que debe utilizar. Es compatible con Postgresql 7.2 o posterior y requiere una JVM 1.4 o posterior.

Para el controlador JDBC de PostgreSQL, ya que los errores se reparan y las funciones se agregan, por lo general solo se usan en la última versión. Las versiones más recientes del controlador JDBC conocen las versiones anteriores del servidor y se comportarán correctamente de acuerdo con la versión del servidor.

Tenga en cuenta que los controladores JDBC anteriores son no conoce las versiones más recientes del servidor, y de hecho puede causar problemas de seguridad mediante el uso de un controlador JDBC anterior a la versión del servidor.

Answer 2

La mejor solución sería poner el controlador jdbc en una carpeta lib compartida en el servidor y no empaquetarlo dentro de la guerra. Esto puede hacerse configurando el alcance en provided.

Puede definir perfiles de compilación en su pom con diferentes versiones de dependencia, pero eso requeriría invocar la compilación dos veces y resultar en dos archivos war diferentes.

Answer 3

No estoy seguro de haber entendido su pregunta. Tengo una opinión un poco diferente sobre este problema. Aquí están mis comentarios/sugerencias:

1. En lugar de agrupar los frascos relacionados con el conductor directamente en el archivo de la guerra, utilizan una fuente de datos gestionado por el servidor de aplicaciones (Tomcat, etc)
2. De esta manera no no lo hará ser cualquier dependencia de la guerra en la clase de controlador.
3. La configuración del origen de datos se puede realizar en el servidor de aplicaciones y su aplicación web solo necesita conocer su nombre JNDI para buscarla.
4. Esto también sintonizará con su One-war-file-to-rule-all-all ya que el archivo war será verdaderamente independiente de las dependencias relacionadas con el controlador.

El inconveniente con este enfoque es que los frascos de los conductores debe ser mantenido manualmente en el servidor de aplicación, pero su tarea sólo una vez y completamente separada de cualquier cambio de nivel de aplicación.