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

Я рассматриваю текущий проект JSF, где web.xml Конфигурация содержит:

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

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

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

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

Источник

1 ответ

Решение

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

Существуют ситуации, когда авторегистрация через .tld файла недостаточно. Хорошо известно, когда веб-приложение развернуто на Jetty. Это подробно объясняется в этом вопросе и ответе: не удалось найти Factory: javax.faces.context.FacesContextFactory.

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

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

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

Источник
Другие вопросы по тегам