Ответ 1
ConfigureListener обычно автоматически регистрируется через файл /META-INF/jsf_core.tld файла JAR для реализации Mojarra. Кроме того, ConfigureListener явно зарегистрирован с помощью сервлета 3.0 ServletContainerInitializer, чтобы обход старой ошибки GlassFish v3 (примечание: v3, а не 3.0.x, так что это действительно первая версия GF3).
Существуют ситуации, когда автоматическая регистрация через файл .tld недостаточна. Хорошо известно, когда webapp развернут на Jetty. Это подробно объясняется в этом Q & A: не удалось найти Factory: javax.faces.context.FacesContextFactory.
Кроме того, как упоминалось ранее и в этом подробном ответе, GlassFish v3 имеет ошибку, в которой файл TLD сканируется слишком поздно, и поэтому JSF не может выполнить необходимую операцию инициализации в нужный момент. Затем вам необходимо явно зарегистрировать ConfigureListener в webapp web.xml.
Но если он работает для вас, когда он явно не зарегистрирован в web.xml, просто сохраните его. Меньше шума в web.xml лучше. Но если вам удастся развернуть контейнер, чувствительный к указанной проблеме (поэтому, когда ваш webapp на самом деле является общедоступным, и вы не имеете контроля над выбором целевого контейнера), то вам лучше сохранить его в "случае" что".
Обновить. Похоже, что Tomcat 8.x показывает ошибочное поведение, когда эта запись включена в web.xml: этот прослушиватель фактически будет выполняться дважды, а не только один раз. Последствия катастрофичны: среди прочих, все слушатели событий JSF будут зарегистрированы дважды, а библиотеки компонентов будут загружаться дважды. Это приводит только к конфликтам во время выполнения. Другими словами, при развертывании в Tomcat убедитесь, что эта запись удалена из web.xml.