proyecto - spring mvc tutorial español pdf

contexto de la aplicación de la carga del junit de la primavera para las pruebas

Question

Tengo algunos archivos XML en mi directorio WEB-INF:

• lyricsBaseApp-servlet.xml
• hibernate.xml
• dataSource.xml
• beans.xml

el servlet xml importa otros archivos xml:

<import resource="dataSource.xml"/>
<import resource="hibernate.xml"/>
<import resource="beans.xml"/>

Me gustaría que mi clase junit4 JukeboxTest incluya toda la configuración de muelles. Usando el nombre de archivo predeterminado, he creado un archivo JukeboxTest-content.xml . Y finalmente, no sé qué poner ahí ...

He intentado:

<import resource="/WEB-INF/dataSource.xml"/>
<import resource="/WEB-INF/hibernate.xml"/>
<import resource="/WEB-INF/beans.xml"/>

o

<import resource="classpath:./WEB-INF/dataSource.xml"/>
<import resource="classpath:./WEB-INF/hibernate.xml"/>
<import resource="classpath:./WEB-INF/beans.xml"/>

y algunas otras ideas, pero todas fallaron. ¿Podría alguien indicarme cómo acceder a esos archivos y de qué manera la primavera interpreta esos archivos?

Answer 1

prueba esto

@ContextConfiguration(locations = {"classpath:**/dataSource.xml",
                               "classpath:**/hibernate.xml", 
                               "classpath:**/WEB-INF/beans.xml"})

Answer 2

Opción 1 (se debe preferir ya que es la mejor práctica):
Refactorice sus archivos de configuración en WEB-INF y mueva las partes comunes (a las que desea acceder también desde las pruebas de integración) a src/main/resources/ . Luego escriba los archivos de configuración específicos de la prueba en src/test/resources/ (si solo necesita importar varios archivos de configuración diferentes de src/main para ensamblar el contexto de prueba, omita esto y use preferiblemente @ContextConfiguration ).

Opción 2 (pirateo):
Use referencias como:

@ContextConfiguration("file:src/main/webapp/WEB-INF/dataSource.xml")

Opción 3 (pirateo):
Si tiene un proyecto Maven, puede configurar maven-surefire-plugin (utilizado en la fase de prueba) para declarar src/main/webapp como un elemento classpath adicional durante la ejecución de la prueba.

Las últimas dos opciones se consideran como pirateo, porque no se supone que los archivos en src/main/webapp estén en el classpath.

Ahora la explicación detallada:

La razón por la que no puede referirse a estos archivos como classpath:/WEB-INF/*.xml es que de hecho no están en la ruta de clases. Es importante comprender cómo está empaquetada su aplicación web, y qué es exactamente lo que termina en la ruta de clases. Asumiendo una estructura de proyecto Maven por defecto:

1. Las clases de Java de src/main/java van a /WEB-INF/classes después de la compilación.
2. Los recursos de src/main/resources van a /WEB-INF/classes .
3. Las dependencias del proyecto van a /WEB-INF/lib .
4. Todo lo que tiene en src/main/webapp va a / (raíz del paquete). Esto significa que todos los archivos de src/main/webapp/WEB-INF van a /WEB-INF , por supuesto.

Lo más importante que debe saber es que classpath solo contendrá /WEB-INF/classes y una entrada para cada jar en /WEB-INF/lib . En consecuencia, los recursos fuera de estas dos ubicaciones son completamente invisibles para el cargador de clases. Esto también es cierto para los archivos de configuración xml directamente en /WEB-INF , razón por la cual el classpath:/WEB-INF/dataSource.xml referencia classpath:/WEB-INF/dataSource.xml nunca funcionará.

Puede preguntarse, ¿cómo diablos son estos archivos de configuración xml cargados por Spring si no son accesibles desde el classpath? La respuesta es simple: cuando inicia su aplicación web (en lugar de ejecutar solo pruebas de unidad / integración), se ejecuta en un contenedor de servlets que proporciona acceso al ServletContext (una clase real de la API del servlet), por lo que utiliza ServletContext.getResourceAsStream() para cargar estos archivos. La clave para la comprensión es la siguiente cita del javadoc de este método:

Este método es diferente de java.lang.Class.getResourceAsStream, que usa un cargador de clases. Este método permite que los contenedores de servlets hagan que un recurso esté disponible para un servlet desde cualquier ubicación, sin usar un cargador de clases.

Lo siento, esto se volvió demasiado largo, pero esa es toda la historia ...