Конфигурация com.sun.faces.config.ConfigureListener

Question

Я обзор текущего проекта JSF, где конфигурация web.xml содержит:

• в FacesServlet (настроенный на *.xhtml)
• com.sun.faces.config.ConfigureListener

Я использую реализацию JSF 2.2 и Mojarra.

Я смущен насчет ConfigureListener. Нужен ли этот класс в конфигурации? Какова цель этого класса? Я не мог найти никакой информации, и у класса почти нет javadoc.

Если я удалю эту конфигурацию, все будет работать одинаково. Таким образом, я думаю, что ConfigureListener мог или должен быть удален, но я не уверен.

Answer 1

ConfigureListener, как правило, автоматически регистрируется посредством файла файла реализации JJ-файла Mojarra. Кроме того, ConfigureListener явно зарегистрирован через сервлет 3.0 ServletContainerInitializer, чтобы обойти старый значок GlassFish v3 (примечание: v3, а не 3.0.x, таким образом, это действительно первая версия GF3).

Существуют ситуации, при которых автозапись через файл .tld недостаточна. Хорошо известно, когда webapp развернут до Jetty. Это подробно объясняется в этом ответе Q & A: could not find Factory: javax.faces.context.FacesContextFactory.

Кроме того, как упоминалось ранее и в этом подробном ответе, GlassFish v3 имеет ошибку, в которой файл TLD сканируется слишком поздно, и поэтому JSF не может выполнить необходимую операцию инициализации в нужный момент. Затем вам необходимо будет явно зарегистрировать ConfigureListener в файле10 в webapp.

Но если это сработает для вас, когда оно явно не зарегистрировано в web.xml, тогда просто не используйте его. Меньше шума в web.xml лучше. Но если вам удастся развернуть контейнер, чувствительный к указанной проблеме (поэтому, когда ваш webapp на самом деле является общедоступным, и вы не имеете контроля над выбором целевого контейнера), то вам лучше сохранить его в «случае» что".

---

Update: Похоже, что Tomcat 8.x показывает поведение багги, когда эта запись включена в web.xml: этот слушатель будет фактически выполняться два раза, а не только один раз. Последствия катастрофичны: среди прочих, все слушатели событий JSF будут зарегистрированы дважды, а библиотеки компонентов будут загружаться дважды. Это приводит только к конфликтам во время выполнения. Другими словами, при развертывании в Tomcat убедитесь, что эта запись удалена с web.xml.