¿Diferencia entre el mapeo de servlet/servlet y el mapeo de filtro/filtro?

Question

Como parte de la exploración/aprendizaje de Struts2, JSP y Servlets, veo en here y there que los servlets y servlets-mapping se pueden usar en web.xml. Sin embargo, Struts2 menciona filtros y mapeo de filtro también para web.xml.

¿Cuál es la diferencia entre ambos? ¿Son estos mutuamente exclusivos? ¿Cuándo debería usar cuál y por qué? ¿Alguien puede aclarar los conceptos? Gracias.

CLARIFICACION

acabo de entender que tenía que entender cómo Struts2 y servlets están relacionados: http://www.coderanch.com/t/57899/Struts/Difference-between-servlet-struts

Answer 1

Filtros de servometro implementan intercepting filter patrón. Si bien servlet es el objetivo final de la solicitud web, cada solicitud pasa por una serie de filtros. Cada filtro puede modificar la solicitud antes de transmitirla o responder después de recibirla del servlet. Incluso puede abstenerse de pasar la solicitud más y manejarla completamente como servlet (no poco común). Por ejemplo, el filtro de caché puede devolver el resultado sin llamar al servlet real.

Answer 2

filtros se utilizan como filtros de servlets. Por ejemplo, si necesita hacer comprobaciones de seguridad en ciertas URL, puede agregar un filtro para esas páginas. Por ejemplo, puede decir que /secure/pages/*.do debe ser interceptado por securityFilter. Luego, el método doFilter() de la clase SecurityFilter (una clase que implementa la interfaz Filter) manejará la auditoría de seguridad antes de reenviarla al servlet solicitante real.

Los servlets son prácticamente lo estándar. Usted define un servlet y luego deja que el contenedor de servlets sepa qué tipo de solicitudes deben asignarse a ese servlet.

No son mutuamente excluyentes. Ambos se pueden usar al mismo tiempo. Piense en el filtro como lo hace la palabra: "filtra" cosas (registro, seguridad, etc.) antes de pasar al siguiente servlet/acción.

Answer 3

El ciclo de vida de la solicitud según la especificación del servlet pasa por una cadena de filtros antes de ser finalmente ejecutado por un servlet.

Esto es bastante intuitivo cuando se mira a la firma para el método doFilter en la interfaz Filter

doFilter(ServletRequest request, ServletResponse response, FilterChain chain) 

Es decir, en el filtro que tiene acceso a la petición y la respuesta y la cadena. El contrato es que usted, como implementador, debe invocar el chain antes o después de las operaciones que realiza en el filtro, o no realizar nada si no desea continuar la ejecución. Llamar al chain.doFilter(...) provocará que el siguiente filtro en la cadena de filtros con una asignación que coincida con la URL solicitada se ejecute. El miembro final de la cadena es el servlet cuya asignación coincide con la URL solicitada.

Técnicamente, puede hacer todo lo que pueda en un servlet en un filtro. Puede construir su aplicación para hacer todo el procesamiento y la representación en un filtro y tener un servlet en blanco que no haga nada. La principal diferencia es que si no hay ningún servlet mapeado contra una URL determinada, el contenedor debe responder con un error 404, por lo que siempre debe existir un servlet mapeado contra cualquier URL que desee atender. También puede tener un servlet mapeado contra una URL, pero puede tener cualquier cantidad de filtros.