Использование сеанса с состоянием Bean для отслеживания сеанса пользователя

это мой первый вопрос здесь, и я надеюсь, что я делаю это правильно.

Мне нужно работать над проектом Java EE, поэтому перед запуском я пытаюсь сделать что-то простое и посмотреть, могу ли я это сделать.

Я застрял в сеансе состояния Beans.

Вот вопрос: Как я могу использовать SFSB для отслеживания сеанса пользователя? Все примеры, которые я видел, оказались "помещением" SFSB в атрибут HttpSession. Но я не понимаю, почему! Я имею в виду, если bean является STATEFUL, почему я должен использовать HttpSession для его сохранения?

Не является ли задача EJB Container возвращать правильный SFSB клиенту?

Я пробовал с помощью простого счетчика bean. Без использования сеанса два разных браузера имеют один и тот же счетчик bean (нажатие на "increment" изменило значение для обоих из них). Используя сеанс, у меня есть два разных значения, каждый для каждого браузера (нажатие на "increment" в Firefox, добавленное только для Firefox bean).

Но мой учитель сказал, что SFSB поддерживает "диалоговое состояние с клиентом", поэтому почему он не просто работает без использования HttpSession?

Если я правильно понял, не использует HttpSession с SFSB то же самое, что и при использовании SLSB?

Я надеюсь, что мой вопрос (вопросы) ясен и что мой английский не такой уж бедный!

ИЗМЕНИТЬ: Я работаю над системой входа в систему. Все идет хорошо, и после завершения входа в систему мне требуется страница профиля, отображающая данные пользователя. Но перезагрузка страницы заставляет мои данные исчезнуть! Я попытался добавить HttpSession во время регистрации, но при этом сделать данные остаются даже после выхода из системы!

ОТВЕТЫ

Ответ 1

Сессия с состоянием Bean (SFSB) должна сочетаться с сеансом HTTP в веб-среде, поскольку это чистый бизнес Bean, который сам ничего не знает о веб-уровне.

Традиционно EJB даже обязательно жили внутри своего модуля (модуль EJB), который даже не мог получить доступ к веб-артефактам, если они этого хотели. Это аспект многоуровневых систем. Дополнительную информацию об этом см. В упаковке EJB в JavaEE 6 WAR vs EAR.

Исходными клиентами для сеанса Stateful Session Beans были среди прочих настольные приложения Swing, которые передавались с удаленного EJB-сервера через двоичный протокол. Приложение Swing получит соединение с удаленным сеансом с состоянием Bean через объект proxy/stub. Встроенный в этот прокси-сервер - это идентификатор некоторого типа, который сервер может связывать с определенным SFSB. Держась за этот прокси-объект, клиент Swing может совершать повторные вызовы, и они перейдут к тому же экземпляру Bean. Таким образом, создается сеанс между клиентом и сервером.

В случае веб-приложения, когда браузер выполняет первоначальный запрос к веб-приложению Java EE, он получает JSESSIONID, который сервер может связать с конкретным экземпляром HTTPSession. Удерживая это JSESSIONID, браузер может предоставить его с каждым последующим запросом, и это активирует одну и ту же серверную сессию http.

Итак, эти понятия очень похожи, но они автоматически не сопоставляются друг с другом.

Браузер получает только JSESSIONID и не знает ни одного идентификатора SFSB. В отличие от приложения Swing, браузер взаимодействует с веб-страницами, а не напрямую с Java beans.

Для сопоставления клиентского запроса с определенным сеансом с состоянием bean контейнер EJB заботится только об идентификаторе, предоставленном через прокси-сервер SFSB. Он не видит, произошел ли звонок из кода в веб-модуле и не может/не должен/не иметь доступа к каким-либо HTTP-контекстам.

Веб-уровень, являющийся клиентским кодом, который обращается к SFSB, должен "удерживать" ссылку на конкретную ссылку прокси. Удержание на что-то в веб-слое обычно означает сохранение его в сеансе HTTP.

Однако существует технология моста под названием CDI, которая может сделать это автоматическое соединение. Если вы комментируете свой SFSB с помощью CDI @SessionScoped и получаете ссылку на SFSB через CDI (например, с помощью @Inject), вам не нужно вручную помещать SFSB в сеанс http. Тем не менее, за кулисами CDI будет делать это в любом случае.

Ответ 2

Вам нужно определить bean с помощью @SessionScoped вместо @RequestScoped (если вы ищете эквивалентное решение HttpSession)

что-то вроде

@SessionScoped
public class SessionInfo implements Serializable{
   private String name;
   public String getName() {
      return name;
   }
   public void setName(String name) {
      this.name = name;
   }
}

Взгляните на следующее (подробно объяснив)

http://www.oracle.com/technetwork/articles/java/cdi-javaee-bien-225152.html