Estoy revisando un proyecto JSF actual donde la configuración web.xml contiene:
*.xhtml ) com.sun.faces.config.ConfigureListener Estoy usando la implementación de JSF 2.2 y Mojarra.
Estoy confundido sobre el ConfigureListener . ¿Se necesita esta clase en la configuración? ¿Cuál es el objective de esta clase? No pude encontrar ninguna información y la clase casi no tiene javadoc.
Si elimino esta configuración, todo parece funcionar de la misma manera. Por lo tanto, supongo que el ConfigureListener podría o debería eliminarse, pero no estoy seguro.
El ConfigureListener normalmente se registra automáticamente mediante el archivo /META-INF/jsf_core.tld archivo JAR de implementación de Mojarra. Además, ConfigureListener se registra explícitamente a través de Servlet 3.0 ServletContainerInitializer para solucionar un antiguo error de GlassFish v3 (nota: v3, no 3.0.x, por lo tanto realmente esa primera versión de GF3).
Existen situaciones en las que el registro automático a través del archivo .tld es insuficiente. El más conocido es cuando la aplicación web se despliega en Jetty . Esto se explica en detalle en esta sección de preguntas y respuestas: no se pudo encontrar Fábrica: javax.faces.context.FacesContextFactory .
Además, como se mencionó anteriormente y en esa respuesta detallada, GlassFish v3 tiene un error en el que el archivo TLD se escanea demasiado tarde y, por lo tanto, JSF no pudo hacer su inicialización necesaria en el momento correcto. Entonces necesitaría registrar explícitamente el ConfigureListener en web.xml de web.xml .
Pero si funciona para usted cuando no está registrado explícitamente en web.xml , simplemente guárdelo. Menos ruido en web.xml es mejor. Pero si posiblemente se despliega en un contenedor sensible al problema mencionado (por lo tanto, cuando su aplicación web es realmente distribuida públicamente y usted no tiene control sobre la elección del contenedor objective), será mejor que la guarde “para el caso ese”.
Actualización : parece que Tomcat 8.x muestra un comportamiento con errores cuando esta entrada está habilitada en web.xml : este oyente se ejecutará realmente dos veces en lugar de una sola vez. La consecuencia es desastrosa: entre otros, todos los oyentes de eventos JSF se registrarán dos veces y las bibliotecas de componentes se cargarán dos veces. Esto solo conduce a conflictos durante el tiempo de ejecución. En otras palabras, al implementar en Tomcat, asegúrese de que esta entrada se elimine de web.xml .