java - mvc - spring reference español

Diferencia entre applicationContext.xml y spring-servlet.xml en Spring Framework

Question

• ¿ spring-servlet.xml y spring-servlet.xml relacionados de spring-servlet.xml manera en Spring Framework?
  
• ¿Los archivos de propiedades declarados en applicationContext.xml estarán disponibles para DispatcherServlet ?
  
• En una nota relacionada, ¿por qué necesito un *-servlet.xml ? ¿Por qué applicationContext.xml solo es insuficiente?

Answer 1

escenario 1

En la aplicación cliente (la aplicación no es una aplicación web, por ejemplo, puede ser una aplicación swing)

private static ApplicationContext context = new ClassPathXmlApplicationContext("test-client.xml");
context.getBean(name);

No hay necesidad de web.xml . ApplicationContext como contenedor para obtener servicio de bean. No hay necesidad de contenedor de servidor web. En test-client.xml puede haber bean simple sin comunicación remota, bean con comunicación remota.

Conclusión : En el escenario 1, applicationContext y DispatcherServlet no están relacionados.

Escenario 2

En una aplicación de servidor (aplicación desplegada en el servidor, por ejemplo, Tomcat). Servicio accedido a través de la comunicación remota desde el programa cliente (por ejemplo, la aplicación Swing)

Definir oyente en web.xml

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

En el inicio del servidor, ContextLoaderListener instancia de los beans definidos en applicationContext.xml .

Suponiendo que haya definido lo siguiente en applicationContext.xml :

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

Los beans se crean instancias de los cuatro archivos de configuración test1.xml , test2.xml , test3.xml , test4.xml .

Conclusión : En el escenario 2, applicationContext y DispatcherServlet no están relacionados.

Escenario 3

En una aplicación web con Spring MVC.

En web.xml define:

<servlet>
<servlet-name>springweb</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>springweb</servlet-name>
<url-pattern>*.action</url-pattern>
</servlet-mapping>

Cuando se inicia Tomcat, se crean instancias de los beans definidos en springweb-servlet.xml . DispatcherServlet extiende FrameworkServlet . En FrameworkServlet creación de instancias de beans tiene lugar para springweb. En nuestro caso springweb es FrameworkServlet.

Conclusión : En el escenario 3, applicationContext y DispatcherServlet no están relacionados.

Escenario 4

En aplicación web con muelle MVC. springweb-servlet.xml para servlet y applicationContext.xml para acceder al servicio de negocios dentro del programa del servidor o para acceder al servicio de DB en otro programa del servidor.

En web.xml se definen los siguientes:

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>springweb</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>springweb</servlet-name>
<url-pattern>*.action</url-pattern>
</servlet-mapping>

Al inicio del servidor, ContextLoaderListener instancia de los beans definidos en applicationContext.xml ; asumiendo que usted ha declarado aquí:

<import resource="test1.xml" />
<import resource="test2.xml" />
<import resource="test3.xml" />
<import resource="test4.xml" />

Los beans están todos instanciados de los cuatro test1.xml , test2.xml , test3.xml , test4.xml . Después de completar la creación de instancias de beans definida en applicationContext.xml, se crean instancias de los beans definidos en springweb-servlet.xml .

Entonces el orden de creación de instancias es raíz es el contexto de la aplicación, luego FrameworkServlet.

Ahora deja claro por qué son importantes en qué escenario.

Answer 2

En la tecnología Servlet, si desea pasar cualquier entrada a un servlet en particular, necesita pasar el parámetro de inicio como el siguiente código.

 <servlet>
<servlet-name>DBController</servlet-name>
<servlet-class>com.test.controller.DBController</servlet-class>
<init-param>
<param-name>username</param-name>
<param-value>John</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>DBController</servlet-name>
<url-pattern>/DBController</url-pattern>
</servlet-mapping>

Si desea pasar algo de entrada que sea común para todos los servlets, entonces esa vez necesita configurar el parámetro de contexto. Ejemplo

 <context-param>
<param-name>email</param-name>
<param-value>[email protected]</param-value>
</context-param>

Así que, exactamente de esta manera, cuando trabajemos con Spring MVC, debemos proporcionar información al servlet predefinido proporcionado por Spring que es DispatcherServlet a través de init param. Por lo tanto, la configuración está en barbecho, aquí proporcionamos el spring-servlet.xml como parámetro de inicio a DispatcherServlet.

 <?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
<display-name>Spring MVC App</display-name>
<servlet>
<servlet-name>SpringController</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring-servlet.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>SpringController</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
</web-app>

Nuevamente necesitamos algún contexto param. Eso es aplicable para toda la aplicación. Entonces podemos proporcionar el contexto raíz que es applicationcontext.xml. La configuración es como esta:

 <context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationcontext.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>SpringController</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring-servlet.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>SpringController</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>

Answer 3

En palabras simples,

applicationContext.xml define los beans que se comparten entre todos los servlets. Si su aplicación tiene más de un servlet, entonces la definición de los recursos comunes en el applicationContext.xml tendría más sentido.

spring-servlet.xml define los beans que están relacionados solo con ese servlet. Aquí está el servlet despachador. Por lo tanto, sus controladores Spring MVC deben estar definidos en este archivo.

No hay nada de malo en definir todos los beans en el spring-servlet.xml si está ejecutando solo un servlet en su aplicación web.

Answer 4

Los contextos de la aplicación proporcionan un medio para resolver mensajes de texto, incluido el soporte para i18n de esos mensajes. Los contextos de la aplicación proporcionan una forma genérica de cargar recursos de archivos, como imágenes. Los contextos de aplicación pueden publicar eventos en beans que están registrados como oyentes. Ciertas operaciones en el contenedor o beans en el contenedor, que deben manejarse de forma programática con una fábrica de beans, pueden manejarse de forma declarativa en un contexto de aplicación. Soporte de ResourceLoader: la interfaz de recursos de Spring Spring nos ofrece una abstracción genérica flexible para manejar recursos de bajo nivel. El contexto de una aplicación en sí es un ResourceLoader, por lo que proporciona una aplicación con acceso a instancias de recursos específicas de la implementación. Soporte de MessageSource: el contexto de la aplicación implementa MessageSource, una interfaz que se usa para obtener mensajes localizados, con la implementación real conectable

Answer 5

Spring le permite definir múltiples contextos en una jerarquía padre-hijo.

applicationContext.xml define los beans para el "contexto de aplicación web raíz", es decir, el contexto asociado con la aplicación web.

spring-servlet.xml (o como se llame) define los beans para el contexto de la aplicación de un servlet. Puede haber muchos de estos en una aplicación web, uno por servlet Spring (por ejemplo, spring1-servlet.xml para servlet spring1 , spring2-servlet.xml para servlet spring2 ).

Los beans en spring-servlet.xml pueden hacer referencia a beans en applicationContext.xml , pero no al revés.

Todos los controladores Spring MVC deben ir en el contexto spring-servlet.xml .

En la mayoría de los casos simples, el contexto applicationContext.xml es necesario. Generalmente se usa para contener beans que se comparten entre todos los servlets en una aplicación web. Si solo tiene un servlet, entonces no tiene mucho sentido, a menos que tenga un uso específico para él.

Answer 6

Un punto más que quiero agregar. En spring-servlet.xml incluimos la exploración de componentes para el paquete del controlador. En el siguiente ejemplo, incluimos una anotación de filtro para el paquete del controlador.

<!-- Scans for annotated @Controllers in the classpath -->
<context:component-scan base-package="org.test.web" use-default-filters="false">
<context:include-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>

En applicationcontext.xml agregamos un filtro para el paquete restante, excluyendo el controlador.

<context:component-scan base-package="org.test">
<context:exclude-filter type="annotation" expression="org.springframework.stereotype.Controller"/>
</context:component-scan>