В Spring mvc если у Controller не указать Scope, то по умолчанию он будет singleton, про thread-safe надо позаботится самому, видимо сделать synchronized методы.




Можно указать "prototype".

А почему собственно не указать " session " scope?



Тогда к каждой сессии юзера будет привязан один контроллер, который будет перенаправлять его по нужным url.
И проверять удобно, залогинившийся юзер пытается перейти к url или еще нет и вернуть на страницу login.
Зачем обязательно делать Controller singleton или prototype?

Вот тут вроде рассматривается как вариант session scope для Controller
http://richardchesterwood.blogspot.com/2011/03/using-sessions-in-spring-mvc-including.html
2: Scope the Controller

Ну вопрос возник по такой причине
У меня есть session scoped объект




Когда user залогинился, этот UserManager делает запрос через service в бд и если такой user есть то сохраняет его как свое поле.
Теперь когда user переходит по другим линкам, я хочу проверять, есть ли этот loggedUser еще или нет.
Поэтому удобно сделать




Но если у Controller не указан scope, то есть singleton по умолчанию, то я не могу сделать inject session scoped UserManager.

Scope 'session' is not active for the current thread; consider defining a scoped proxy for this bean if you intend to refer to it from a singleton; nested exception is java.lang.IllegalStateException: No thread-bound request found: Are you referring to request attributes outside of an actual web request, or processing a request outside of the originally receiving thread ? If you are actually operating within a web request and still receive this message, your code is probably running outside of DispatcherServlet/DispatcherPortlet...

То есть для этого мой контроллер должен быть session/request scoped.

BlazkowiczА как UserManager хранит ссылку на Service+Persistence? А что будет после сериализации и десериализации UserManager?

UserManager имеет inject service класса, а тот имеет inject repository класса (Spring Data Jpa).

По поводу Spring Security. Мне представляется надежнее самому прописать в нужных местах проверки залогинившегося юзера, какие он имеет права. И проще наверное, чем писать кучу конфигурационных файлов.

Какие преимущества вообще дает этот Spring security - реальные?

BlazkowiczНу, то есть. Положили UserManager в сессию. Остановили сервер. Сервер сериализовал UserManager на диск. (В вашем случае тупо обрыгался, потому что UserManager не Serializable). Но допустим мы сделали его Serializable.
Запустили сервер. Тот прочитал UserManager с диска, восстановил сессию. И что у нас там стало с Service и Repository? Они ведь уже не привязаны к новому спринговому контексту.
Я считал, что при перезагрузке сервера - это ж не обычная ситуация, а форс-мажор - все сессии и так должны отключиться, и зачем их восстанавливать после перезагрузки?
Почему после десериализации (даже если это необходимо) Service и Repository не будут привязаны к спринговому контексту?

BlazkowiczВнимательно перечитайте статью. В вашем случае сервер будет пытаться сериализовать UserManager со всеми его сервисами, репозиториями и, возможно, вообще полным спринговым контекстом.
Т.е. на продакшн сервере, при ребуте все клиентские сессии умирают это раз.
Кластеризация с репликацией сессии становится не возможно это два.
А если мы сделаем ссылки транзиентными, то они будут обнулятся.

то есть в случае, если UserManager имеет scope "session"?
Я не понял, почему из сериализации следуют такие выводы : Blazkowiczпри ребуте все клиентские сессии умирают это раз.
Кластеризация с репликацией сессии становится не возможно это два.

BlazkowiczПо-хорошему нужно переопределить десериализацию и восстанавливать ссылки на классы контекста при чтении объектов сессии из байт.
Что значит "переопределить десериализацию и восстанавливать ссылки на классы контекста при чтении объектов сессии из байт".
То есть переопределить поведение интерфейса Serializable?


BlazkowiczНо ведь гораздо проще хранить тупые Value Object в сессии и не заморачиваться с ссылками.

Сорри, не понял - про какие тупые Value Object идет речь?
Что значит хранить в сессии - то есть не делать scope "Session", а получить доступ к объекту HttpSession и положить туда объекты как аттрибуты? Тут есть различие - указать scope session для класса или попложить в HttpSession аттрибут?

Честно говоря до конца не понял.
Получается указывать scope session вообще плохо для классов. Но что тогда по поводу JSF?
Там есть специальный layer, называется managed beans. Для каждого такого бина можно указать session или request scope.
Собственно этот подход я взял оттуда. У меня получается между страницей и service layer добавлен manager уровень, которому я указываю Scope Session.
Что по поводу JSF в таком контексте? Там тоже возникают проблемы с сериализацией после перезагрузки сервера?

Мне - как это обычно бывает- надо сохранять какие-то введенные данные между запросами.
Сделать какой-то класс session scope - это плохо.
Как мне сохранять введенные данные между запросами?
Устанавливать именно их в сессию как аттрибуты? А сам класс должен быть request scoped?

Может быть Spring webflow как вариант?

Petro123небольшой...не так уж плохо....вроде бы....))))
Вот тут по-русски про корзину....т.к. нету faq
http://it.vaclav.kiev.ua/2010/12/25/spring-framework-for-beginners-part-10/

Значит делать компонент session scope НЕХОРОШО, и если необходимо сохранять состояние между запросами, то нужен
<aop:scoped-proxy/> - то есть ИММИТАЦИЯ session scope. так чтоли ?

Почему в статье рекомендуется использовать <aop:scoped-proxy/>? Чем это лучше, чем указать scope Session?

Столько эмоций.
Буду медитировать над сказанным - может пойму зачем сессию через aop указывать.
И насчет SingleThreadModel в контроллере.
Хотелось бы, чтобы был хотя бы Request cope - то есть чтобы быть уверенным, что один инствнц контроллера гарантировано обслуживает один запрос от user.
Ну а в том пункте, что нужно схранять состояние этого клиента между его запросами, я делаю значит некий UserState класс, указываю ему scope prototype




и при логине этого юзера создаю внутри Controller (не Service) класса этот UserState, укладываю его в HttpSession



Правильно я понял? Этот userState и будет Value Object.

Уважаемый Blazkowicz, напишите один раз развернуто, не обрывками фраз :)

1.Blazkowicz Это имеет смысл если всю логику писать в контроллере. Тогда появятся поля, состояния и т.п. Если слоёв на сервере больше, то кроме контроллера, ведь, и другие станут scope request.
А где писать логику?
Есть уровни такие - на мой взгляд :
page -> controller -> service -> dao -> database.
Controller состояние не сохраняет, это singleton (ну или prototype, максимум - request scope).
Service - тоже singleton? Service просто предоставляет возможности каких-то вычислений для поданных данных, открывает транзакции, делает запросы через dao в database.
В dao - тоже не место для логики.
Какой делать уровень для бизнес логики, для самого движка?

2. BlazkowiczДа. Только зачем это всё делать руками?
А как это делать - объясните ж пожалуйста, а то какие то загадочные фразы.

Значит SpringSecurity - это не только проверка данных при авторизации и прав на какой-то ресурс, но и сохранение данных в сессии между запросами? То есть то, что в JSF реализуется при помощи session scope для managedBean. Я долго работал с JSF и поэтому пытаюсь в Spring в Spring использовать такой подход с session scope. Видимо это неправильно.

Буду разбираться с Spring Security.
Бизнес логику обычно реализую в service лайере.

chpashaosonв service лайере.в сервисном вруне что ли?

????

Service layer - так лучше?

Могу по-украински - кому английский не подходит :)

"Blazkowicz
Подскажите пожалуйста где можно посмотреть пример использования Spring Security для работы с session и хранением в ней Data value.

Спасибо.