Configurazione di com.sun.faces.config.ConfigureListener

Sto rivedendo un progetto JSF attuale in cui la configurazione web.xml contiene:

  • il FacesServlet (configurato su *.xhtml )
  • il com.sun.faces.config.ConfigureListener

Sto usando l’implementazione di JSF 2.2 e Mojarra.

Sono confuso riguardo a ConfigureListener . Questa class è necessaria nella configurazione? Qual è l’objective di questa class? Non sono riuscito a trovare alcuna informazione e la class non ha quasi javadoc.

Se rimuovo questa configurazione, tutto sembra funzionare allo stesso modo. Quindi immagino che il ConfigureListener possa o debba essere rimosso ma non ne sono sicuro.

Normalmente ConfigureListener viene registrato automaticamente tramite il file /META-INF/jsf_core.tld file JAR di implementazione di Mojarra. Inoltre, ConfigureListener è registrato esplicitamente tramite ServletContainerInitializer Servlet 3.0 per risolvere un vecchio bug di GlassFish v3 (nota: v3, non 3.0.x, quindi davvero una prima versione GF3 di sempre).

Esistono situazioni in cui la registrazione automatica tramite file .tld è insufficiente. Il noto è quando la webapp viene distribuita su Jetty . Questo è spiegato in dettaglio in questo Q & A: imansible trovare Factory: javax.faces.context.FacesContextFactory .

Inoltre, come menzionato prima e in quella risposta dettagliata, GlassFish v3 ha un bug in cui il file TLD viene scansionato troppo tardi e quindi JSF non potrebbe fare la sua cosa di inizializzazione necessaria al momento giusto. Dovresti quindi registrare esplicitamente ConfigureListener nel web.xml di webapp.

Ma se funziona per te quando non è registrato esplicitamente in web.xml , basta tenerlo fuori. Meno rumore in web.xml è migliore. Ma se ti capita di schierare in un contenitore sensibile al problema menzionato (quindi quando la tua webapp è in realtà una pubblicamente distribuita e non hai il controllo sulla scelta del contenitore di destinazione), allora è meglio tenerla in “per il caso” quella”.


Aggiornamento : sembra che Tomcat 8.x mostri un comportamento buggy quando questa voce è abilitata in web.xml : questo listener verrà effettivamente eseguito due volte anziché solo una volta. La conseguenza è disastrosa: tra gli altri, tutti gli ascoltatori di eventi JSF verranno registrati due volte e le librerie dei componenti verranno caricate due volte. Questo porta solo a conflitti durante il runtime. In altre parole, quando si esegue la distribuzione su Tomcat, assicurarsi che questa voce sia stata rimossa da web.xml .