@ConversationScoped bean ведет себя как @RequestScoped с OmniFaces 2.5 FacesViews

Question

Я попытался обновить приложение Java EE 7/JSF 2.2 до Omnifaces 2.6. В настоящее время я запускаю версию 2.4. После этого я заметил странное поведение при использовании @ConversationScoped и Ajax-Requests. При вызове область, которая должна быть отображена после запроса, очищается (без исключения на сервере, код статуса ответа 200).

Далее у меня есть реализация мастера, основанная на @ConversationScoped. Он содержит класс под названием ViewManager, который имеет сам список представлений. Инициализация прекрасна, и этот список заполняется. Но как-то он очищается (устанавливается в null), когда первая форма/представление отправляется. Сетчатка для этого никогда не вызывается после инициализации, поэтому мой код не изменяется. Как-то экземпляр диспетчера представлений все еще доступен, только этот список представлений в диспетчере представлений имеет значение NULL, что довольно странно.

С omnifaces 2.4 все работает нормально (вот почему я не добавил код моего волшебника). Я проверил журнал изменений и заметил конфигурацию MultiViews при использовании ExtensionlessURLs. Не знаю, почему это может повлиять на мою проблему, но я попробовал ... без успеха. Я понятия не имею, что может быть проблемой, так что, возможно, вы можете мне помочь.

Заранее спасибо :)

Answer 1

В OmniFaces, то FacesViews extensionless URL-адреса Функция получила в версии 2.5 капитального ремонта, чтобы поддержать так называемый MultiViews, как вы можете прочитать на this blog.

Во время этого ремонта я совершил ошибку совместимости в обратном направлении в FacesViewsViewHandler, где манипулирует URL-адрес <h:form>, чтобы включить виртуальные папки в функцию MultiViews. Параметры строки запроса были удалены из исходного URL-адреса действия и не добавлены обратно.

@ConversationScoped зависит от параметра cid запроса присутствует в URL <h:form> действий, как в /context/page?cid=1. Таким образом, это стало /context/page, и поэтому разговор не сохраняется через обратные передачи.

Я исправлю это в следующем выпуске OmniFaces, на данный момент вы можете вернуть желаемое поведение, добавив ниже контекстный параметр в web.xml.

<context-param> 
    <!-- Workaround for disappearing @ConversationScoped ?cid= parameter --> 
    <!-- This can be removed in next OmniFaces version after 2.6 --> 
    <param-name>org.omnifaces.FACES_VIEWS_VIEW_HANDLER_MODE</param-name> 
    <param-value>BUILD_WITH_PARENT_QUERY_PARAMETERS</param-value> 
</context-param> 

Этот параметр запускает другой способ построения URL-адреса, в результате чего вся строка запроса из исходного URL-адреса действия явно сохраняется.