Компонент @ConversationScoped ведет себя как @RequestScoped, начиная с OmniFaces 2.5 FacesViews.

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

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

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

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


cdi jsf jsf-2.2 omnifaces
person jheider    schedule 04.02.2017    source источник
comment
Вы используете FacesViews? @ConversationScoped зависит от наличия определенного параметра запроса. Теоретически возможно, что это каким-то образом потерялось.   -  person BalusC    schedule 04.02.2017
comment
Я использую ExtensionlessURLs, вот и все, насколько я знаю. ‹context-param› ‹param-name›org.omnifaces.FACES_VIEWS_SCAN_PATHS‹/param-name› ‹param-value›/*.xhtml‹/param-value› ‹/context-param›   -  person jheider    schedule 04.02.2017

Ответы (1)


arrow_upward
2
arrow_downward

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

Во время этого капитального ремонта я сделал ошибку обратной совместимости в 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-адреса действия явно сохраняется.

person BalusC    schedule 04.02.2017
comment
ах, идеально! Это решило все мои проблемы. Большое спасибо! - person jheider; 05.02.2017