Comprender los contextos en Spring MVC

Soy nuevo en la spring y estoy creando una aplicación web simple. He estado leyendo sobre contextos en Spring MVC.

Estoy usando el complemento STS para eclipse. Creé un proyecto Spring MVC usando el complemento.

Ahora tengo tres documentos xml en el proyecto, web.xml, root-context.xml y servlet-context.xml. Estos fueron creados por STS para mí.

  1. En web.xml, el servlet del asignador apunta hacia servlet-context.xml y entiendo que el trabajo de los servlets del despachador es crear un contexto de aplicación web que sepa cómo resolver vistas y sea un lugar para que existan beans de controlador. Es mi entendimiento correcto? Si es así, ¿qué otro trabajo se lleva a cabo en este contexto?

  2. Ahora, hay un archivo llamado root-context.xml que tiene un análisis de componente en el paquete predeterminado de mi proyecto. Según entiendo, este contexto necesita tener beans globales que muchos servlets podrían usar. Es mi entendimiento correcto? ¿Qué más hace esto? ¿Qué tipo de contexto se crea utilizando este archivo?

  3. Ahora, estoy más avanzado en el proyecto y tengo varios archivos * -context.xml (dao-context.xml, security-context.xml, etc.) que se cargan usando contextLoaderListner (en web.xml). ¿Es esta una buena idea? ¿O debería entrar todo en servlet-context.xml? Creo que es una buena idea tener diferentes contextos, ya que proporciona una separación de la preocupación. ¿Comentarios? Además, ¿qué tipo de contexto se crea a partir de estos archivos * -context.xml? ¿Cuál es la ubicación correcta de la carpeta para estos archivos?

  4. Web.xml es para el contenedor de servlets como tomcat, etc. y todos los demás archivos xml del proyecto son para el contenedor de spring. ¿Es eso correcto? Todos estos archivos están separados para proporcionar la separación de la preocupación?

  5. ¿Cuántos contextos de aplicaciones y contextos de aplicaciones web existen en el escenario actual?

¿Por qué alguien necesitaría más de un servlet despachador?

¿Por qué alguien necesitaría más de un contexto de aplicación?

¿Pensamientos? ¿Comentarios? Correcciones? ¿Mejores prácticas?

La idea detrás de este diseño es manejar diferentes capas de architecture en una aplicación web típica y proporcionar un mecanismo de herencia / anulación para los beans en todos los contextos. Cada tipo de contexto en Spring está relacionado con diferentes capas arquitectónicas, por ejemplo, capa web, capa de servicio, etc.

Una aplicación web basada en Spring puede tener múltiples servlets de despachador configurados (aunque en la mayoría de los casos es un solo servlet, pero el dispatcher serlvet es un servlet y puede haber varios configurados en web.xml). Estos se pueden configurar para manejar diferentes patrones de URL. Entonces, obviamente, cada uno es un servlet diferente y, por lo tanto, puede tener un contexto de aplicación web Spring diferente. Cada uno de estos puede contener diferentes configuraciones para la capa web de Spring, como controladores, interceptores, resolución de vistas, resolución de locaciones, etc., ya que generalmente pertenecen a la capa web de una aplicación. Todas estas configuraciones y beans son privados para cada servlet de despachador, por lo que no son visibles entre sí. Por lo tanto, tener un contexto de aplicación web de spring separada tiene sentido para habilitar esta privacidad. Sin embargo, hay otros beans que están diseñados para ser compartidos, por lo tanto, pertenecen a un contexto raíz. Entonces, todas las cosas que se pueden compartir pertenecen al contexto raíz y se puede considerar global para esta aplicación web.

Cada servlet despachador hereda todos los beans definidos en el contexto raíz. Sin embargo, el punto importante a tener en cuenta es que los beans compartidos pueden ser reemplazados por los respectivos beans específicos del servlet dispatcher. Por lo tanto, en las aplicaciones web, el contexto raíz se puede ver como algo que se hereda pero que se puede anular.

Bueno, la spring no te obliga a tener archivos xml de esa manera, puedes trabajar todo usando solo un archivo xml que sería servlet-context.xml y usando solo el servlet despachador. Generalmente hay diferentes archivos para definir los beans de servicio o los beans de dao, así que esto básicamente depende del diseño de la aplicación, por ejemplo, si está utilizando la seguridad de spring, es posible que desee agregar un archivo xml más como security-context.xml como dije, depende del diseño. En realidad, puede eliminar por completo el oyente del cargador de contexto y aún así administrar todo mediante el servlet de despachador. Su pregunta tiene un scope demasiado amplio, ya que es nuevo para la spring, es posible que deba obtener más detalles sobre los contenedores de muelles y decidir qué se adapta a sus necesidades. Generalmente tengo mi servlet-context.xml en WEB-INF y otra configuración como service-context.xml en classpath, de nuevo, esta no es una regla estricta, simplemente cómo me conviene.