ConfigureListener thường được đăng ký tự động qua tệp của tệp JAR triển khai Mojarra. Ngoài ra, ConfigureListener được đăng ký rõ ràng qua Servlet 3.0 ServletContainerInitializer để giải quyết lỗi GlassFish v3 cũ (lưu ý: v3, không phải 3.0.x, do đó thực sự là phiên bản GF3 đầu tiên bao giờ).
Có các tình huống trong đó đăng ký tự động qua .tld tệp không đủ. Một trong những nổi tiếng là khi webapp được triển khai để Jetty. Điều này được giải thích chi tiết trong Q & A: could not find Factory: javax.faces.context.FacesContextFactory.
Ngoài ra, như đã đề cập trước đó và trong câu trả lời chi tiết đó, GlassFish v3 có lỗi trong đó tệp TLD được quét quá muộn và do đó JSF không thể thực hiện việc khởi tạo cần thiết vào đúng thời điểm. Sau đó, bạn cần đăng ký một cách rõ ràng ConfigureListener trong trang web web.xml của webapp.
Nhưng nếu nó hoạt động cho bạn khi nó không được đăng ký rõ ràng trong web.xml, thì hãy giữ nó ra. Ít tiếng ồn hơn trong web.xml là tốt hơn. Nhưng nếu bạn có thể triển khai một vùng chứa nhạy cảm với vấn đề được đề cập (vì vậy khi webapp của bạn thực sự được phân phối công khai và bạn không có quyền kiểm soát lựa chọn vùng chứa đích), thì bạn nên giữ nó trong "đối với trường hợp cái đó".
Cập nhật: Dường như Tomcat 8.x cho thấy hành vi lỗi khi cụm từ này được kích hoạt trong web.xml: nghe điều này thực sự sẽ được thực hiện hai lần thay vì chỉ một lần. Hậu quả là tai hại: trong số những người khác, tất cả các trình lắng nghe sự kiện JSF sẽ được đăng ký hai lần và các thư viện thành phần sẽ được tải hai lần. Điều này dẫn đến xung đột trong thời gian chạy. Nói cách khác, khi triển khai vào Tomcat, hãy đảm bảo rằng mục nhập này bị xóa khỏi web.xml.
Hãy tìm http://www.coderanch.com/t/428264/JSF/java/function-listener-sun-faces-config – Willmore