Лениво искать, но это полубаг полуфича, заставить работать в скопе вью или конверсейшн у вас врядли получится, только сешн

Не совсем понимаю, что значит авторА можно как-то принудительно записать состояние для SessionScoped бина?

Я делал так, но у меня был Seam2 и Richafces3, хотя не особо важно. В общем в методе файлаплоадлистенера я вычитываю файл, паршу его, создаю Holder для данных, и выкидываю этот Holder через аннотацию @Out в session scope, потом в любом другом месте я мог инжектнуть его через аннотацию @In. А что вам надо я не совсем пока понимаю.

авторМой ViewScoped бин реализует Serializable, следовательно - RF его сохраняет и восстанавливает время от времени (куда-то типа session или в другой аналогичный контекст); таким образом, при ajax-вызове я имею дело с восстановленным бином.
не RF сохраняет, а JSF или Seam.

Африканецзабыл ник,

Я понял, что при вызове actionListener'а для fileUpload бин не сохраняется, т.к. список записей, который я получил в этом методе, не виден в следующем ajax-вызове. Вопрос: можно ли как-то принудительно заставить бин сохраниться при вызове actionListener'а?


Бин сохраняется, но не в том скоупе. По какой-то причине метод вызываемый на сервере во время файлаплоадинга, не может подцепить view и conversation-scoped бины, я предполагаю, что RF тупо не передает параметр cid, и неправильно посылает свой viewId, например рандомно добавляет что-то, потому как если использовать session, то как вы заметили все работает нормально. Так как механизмы view и conversation - спрятаны от рук программистов, не видится возможным вклиниться в этот процесс. Думаю теоретически можно продебажить эти механизмы и написать грязнейший хак, но это на любителя, поэтому в общем случае механизм работы такой - разнести view scoped бин и fileuploadListener в разные классы, а в методе fileuploadListenerа вычитывать данные и сохранять их в session scope.

авторБолее обще: при каких ajax-вызовах со страницы ViewScoped бин сохраняется, а при каких - нет? Есть ли способы гарантированно заставить его сохраняться/не сохраняться?
Он должен сохраняться при ВСЕХ вызовах, ваша проблема специфична к компоненту fileUpload, потому что при вычитке данных, он внутри себя создает реквест, который идет вразрез с механизмом view scoped.

авторМне случалось наблюдать этот эффект и в других местах (JSF+RF), где не было fileUpload. Видимо, действительно надо в таких случаях создавать отдельный бин в session и валить туда всё, что должно быть доступно странице и бину, но на форму не выкладывается.
А можно поподробнее? Я таких ситуаций не встречал, если есть возможность опишите - будет интересно, хотя если честно думаю там могли быть другие ошибки. Особенность файлаплоад компонента в том, что он сам генерит реквесты, еще теоретически возможны проблемы с a4j:push, но я о таких не слышал.

авторА вообще - было бы интересно пообщаться с разработчиками RF на эту тему...
Ну собственно я сам бывший разработчик RF и приложил руку в том числе и к файлаплоаду, правда по UI части.
Дело в том, что как я уже указывал, RF абсолютно перпендикулярна к вопросу сохранения\получения бинов из контекста, все отдается на откуп JSF или фреймворков наподобие Seam, они посредством аннотаций, EL-биндинга и настройки facesContextа управляет жизненным циклом и участвуют в поисках view-scoped бинов. Просто возможно файлаплоад непреднамеренно делает что-то несовместимое с этим скоупингом, хз.. Я отошел от этих дел уже, но будет время может и продебажу, самому интересно, с этим вопросом сталкивался давно, но не было времени изучить подробно.