Die ConfigureListener wird normalerweise automatisch über die Datei der Mojarra-Implementierungs-JAR-Datei registriert. Zusätzlich wurde die ConfigureListener explizit über ein Servlet 3.0 ServletContainerInitializer registriert, um einen alten GlassFish v3 Bug zu umgehen (Anmerkung: v3, nicht 3.0.x, also wirklich die erste GF3 Version überhaupt).
Es gibt Situationen, in denen die automatische Registrierung über die Datei .tld nicht ausreicht. Die wohlbekannte ist, wenn die Webapp zu Jetty bereitgestellt wird. Dies wird detailliert in dieser Q & A: could not find Factory: javax.faces.context.FacesContextFactory erläutert.
Wie bereits erwähnt und in dieser detaillierten Antwort, hat GlassFish v3 einen Fehler, bei dem die TLD-Datei zu spät gescannt wird und JSF daher nicht im richtigen Moment die notwendige Initialisierung durchführen konnte. Sie müssten dann die ConfigureListener in Webapps web.xml explizit registrieren.
Aber wenn es für Sie funktioniert, wenn es nicht explizit in web.xml registriert ist, dann halten Sie es einfach aus. Weniger Rauschen in web.xml ist besser. Wenn Sie jedoch möglicherweise in einem Container arbeiten, der für das genannte Problem anfällig ist (also wenn Ihre Webanwendung tatsächlich öffentlich verteilt ist und Sie keine Kontrolle über die Wahl des Zielcontainers haben), sollten Sie sie lieber für diesen Fall behalten Das".
aktualisieren: Es scheint, dass Tomcat 8.x Buggy Verhalten zeigt, wenn dieser Eintrag in web.xml aktiviert ist: diese Hörer tatsächlich zweimal statt nur einmal ausgeführt werden. Die Konsequenz ist katastrophal: unter anderem werden alle JSF-Event-Listener doppelt registriert und Komponentenbibliotheken werden zweimal geladen. Dies führt nur zu Konflikten während der Laufzeit. Stellen Sie bei der Bereitstellung in Tomcat sicher, dass dieser Eintrag aus web.xml entfernt wird.
Suchen Sie diese http://www.codeanch.com/t/428264/JSF/java/function-listener-sun-faces-config – Willmore