Похоже, что вы имели ввиду вывод данных из бина в выпадающий список на странице. С этим у меня проблем не было с самого начала. А я спрашивал о конвертации в обратном направлении - из выпадающего списка на странице в поле объекта (а не просто в строку или число как в примере из SWF). 

Да, был не прав. Если просто вставить itemValue=#{w} то в html в значении option будет значение Wallet.toString(), что не верно.
Моё предложение, чтобы не связываться с конверторами: поместить в itemValue значение индентификатора Wallet. Тогда во время сохранения можно будет его восстановить.
Собственно я сделал ещё более «лёгкую» версию, только JSF2.0, безо всякого Spring'а. Недеюсь принцип понятен.

Присоединённый файл ( Кол-во скачиваний: 5 )
 webkeeper_lite.zip 8,59 Kb

Спасибо - разберу ваш пример. Для тех кто нас прочтёт    - если хочется обойтись JSF только в качестве view, а весь IoC иметь от spring то, похоже, единственно правильный путь - делать как учил товарищ BalusC Using a Backing Map

Если кто-то знает как внедрить Spring-бины в JSF-конвертер - очень хотелось бы услышать. (Только не через вытаскивание посредством Spring-контекста).

Внедрить Spring-Bean'ы в JSF-конвертор — вот ещё один вариант.
Если посмотреть со стороны JSF — то правильный способ — Spring должен предоставлять реализацию JSF ApplicationFactory, которая в методе createConvertor возвращала бы экземпляр с внедрёнными зависимостями.
Но…, почему ты так хочешь воспользоваться именно конвертором?

Понять будет ли то что тут предложено работать и как Внедрить Spring-Bean'ы в JSF-конвертор мне пока не хватает опыта. Вот если бы там рабочий пример был... 

JSF ApplicationFactory - она уже есть в Spring или подразумевается, что я сам её напишу? 

Потому что конвертор - это стандартный подход в JSF. Не нужно реализовывать подпорки типа той, что описана у BalusC. И вроде всё для него есть - одна только проблема - заставить JSF увидеть бин walletService...


Это сообщение отредактировал(а) isabsent - 3.5.2011, 07:03

В Spring'е я такого не обнаружил, хотя он вполне там и мог бы быть. Самому писать лениво — Spring мне не особо интересен но общий принцип простой. Реализуем ApplicationFactory, где все методы кроме создания Application переправляем в оригинальную ApplicationFactory. В методе создания Application оборачиваем созданный Application с помощью ApplicationWrapper, где в свою очередь переопределяем метод возвращения конвертора. Вместо него пишем получаем Bean конвертора из Spring'а. Как-то так.

Может способ, приведённый на stackoverflow всех устраивает (@Component("myConverter")).

Насчет конвертеров и валидаторов.
Зачем их определять в faces-config.xml, если у тебя есть Spring?
Просто берешь их и определяешь как Spring бины, разве что имплементишь нужные интерфейсы. И будет тебе счастье с @Autowired.
Разве что нужно быть аккуратным со scope, чтобы они не оказались у тебя на все приложение, да и чтобы не получился scope impedans.

И насчет RequestContextListener.

Такова рекомендация интеграции JSF+Spring. Он нужен для того, чтобы мокжно было работать со scopes session & request.
а также в его исходниках так и написано:

Золотые слова! Жаль, что сразу не доходят - только после того как на всех граблях постоишь... Не забывайте переопределять equals() и hashCode() у бина, для которого пишется свой пользовательский Converter - иначе долгий и упорный "Validation Error: Value is not valid" в элементах типа selectOneMenu...

Странно, почему конвертер в JSF так выделен среди других классов? Ведь можно же инжектировать Spring-бины в другие JSF-бины (вот, например, без проблем инжектятся), а как только класс implements Converter, так всё это благолепие рушится и остаётся один грубый FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance()).getBean("yourServiceBean")! Почему так?!

Это сообщение отредактировал(а) isabsent - 8.5.2011, 22:17

В приведённой ссылкы injectируется результат выполнения Expression Language выражение, а так как используется Spring EL Resolver, то там работает подключение Spring-Bean'ов. Жизненный цикл конвертора управляется JSF'ом, который ничего про Spring не знает.

В приведённой ссылке жизненный цикл бина BikeDetails, в который легко и непринуждённо инжектируется Spring-бин bikeDataProvider, находится под управлением JSF IoC. Однако в JSF Converter, точно так же находящийся под управлением JSF IoC, невозможно инжектировать ничего, что находится под управлением Spring IoC - даже с помощью EL-Resolver. Поэтому я не совсем понимаю ваш ответ - ведь ситуация одна и та же, а spring-бин не инжектируется во втором случае...

Не совсем так. В BikeDetails inject'ируется не Spring Bean, а результат выполнения ExpressionLanguage выражения! И Spring представляет реализацию ELResolver'а, который может получать доступ к Spring'овым Bean'ам.

Всё равно непонятно - почему тот же самый результат выполнения ExpressionLanguage выражения не может инжектироваться в Converter!? Чем Converter принципиально отличается от любого другого JSF-бина с точки зрения Spring'a или EL-Resolvera?

Это сообщение отредактировал(а) isabsent - 9.5.2011, 11:39

Конвертор не поддерживает @ManagedProperty, если я правильно помню.

Да - я в этом на собственной шкуре убедился   Осталось понять за что его так обидели те, кто всё это  придумали и почему они не написали этого в API   . Кстати - если он не поддерживает @ManagedProperty, то значит я и находясь только под JSF IoC (без Spring'a вообще) не смогу попользоваться инжекцией какого-нибудь JSF ManagedBean. То есть буду вынужден какими-то статическими методами вызывать свои сервисы или опять же тащить их через Context. В чём смысл таких жёстких ограничений?

Это сообщение отредактировал(а) isabsent - 9.5.2011, 15:35