Конфигурация 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 недостаточна. Хорошо известно, когда 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.