Używanie stanowej fasoli sesyjnej do śledzenia sesji użytkownika

Question

to moje pierwsze pytanie tutaj i mam nadzieję, że robię to dobrze.

Muszę pracować nad projektem Java EE, więc zanim zacznę, staram się zrobić coś prostego i zobaczyć, czy mogę to zrobić.

Utknąłem z stanowymi ziarnami sesji.

Oto pytanie: Jak mogę użyć SFSB SFSB do śledzenia sesji użytkownika? Wszystkie przykłady, które zobaczyłem, zakończyły się "wstawieniem" SFSB do atrybutu HttpSession HttpSession. Ale nie rozumiem, dlaczego! Mam na myśli, jeśli fasola jest PAMIEŚCIOWA, dlaczego muszę używać HttpSession, aby ją zachować?

Czy zadaniem kontenera EJB nie jest zwrócenie klientowi właściwej nazwy SFSB?

Próbowałem już z prostą wersją fasoli. Bez korzystania z sesji dwie różne przeglądarki mają ten sam komponent bean licznika (kliknięcie "przyrost" zmieniło wartość dla obu). Używając sesji, mam dwie różne wartości, każdą dla każdej przeglądarki (klikając na "przyrost" w Firefoksie, dodałem jedną tylko do fasoli Firefoksa).

Ale mój nauczyciel powiedział, że SFSB utrzymuje „stan konwersacji z klientem”, więc dlaczego nie po prostu pracować bez użycia HttpSession?

Jeśli dobrze zrozumiałem, nie używa HttpSession z SFSB to samo robi to z SLSB zamiast?

Mam nadzieję, że moje pytanie (a) jest jasne i że mój angielski nie jest tak słaby!

EDYTOWANIE: Pracuję nad systemem logowania. Wszystko jest w porządku, a po zakończeniu logowania następuje przejście do strony profilu, która pokazuje dane użytkownika. Ale ponowne załadowanie strony powoduje zniknięcie moich danych! Próbowałem dodać HttpSession podczas logowania, ale dzięki temu dane pozostają nawet po wylogowaniu!

Answer 1

Stateful Session Bean (SFSB) musi być połączony z sesją HTTP w środowisku sieciowym, ponieważ jest to czysty komponent biznesowy, który sam nie wie nic o warstwie internetowej.

Tradycyjnie EJB są nawet obowiązkowe, żyją we własnym module (module EJB), który nie może uzyskać dostępu do artefaktów internetowych, jeśli zechcą. Jest to aspekt warstwowych systemów. Zobacz Packaging EJB in JavaEE 6 WAR vs EAR, aby uzyskać więcej informacji na ten temat.

Pierwotnymi klientami dla Stateful Session Beans były między innymi aplikacje Swing dla komputerów stacjonarnych, które komunikowały się ze zdalnym serwerem EJB za pośrednictwem protokołu binarnego. Aplikacja Swing uzyska połączenie ze zdalną, stanową funkcją Session Bean za pośrednictwem obiektu proxy/stub. Osadzony w tym proxy jest pewnego rodzaju identyfikatorem, który serwer może powiązać z określonym SFSB.Trzymając się tego obiektu proxy, klient Swing może wykonywać powtarzające się do niego połączenia, a te trafią do tej samej instancji komponentu bean. W ten sposób zostanie utworzona sesja między klientem a serwerem.

W przypadku aplikacji internetowej, gdy przeglądarka wysyła pierwsze żądanie do aplikacji WWW Java EE, otrzymuje ona numer JSESSIONID, który serwer może skojarzyć z konkretną instancją HTTPSession. Trzymając się tego JSESSIONID, przeglądarka może dostarczyć mu każde kolejne żądanie, co aktywuje tę samą stronę serwera sesji http.

Pojęcia te są bardzo podobne, ale nie są automatycznie wzajemnie odwzorowywane.

Przeglądarka otrzymuje tylko numer JSESSIONID i nie ma wiedzy o żadnym identyfikatorze SFSB. W przeciwieństwie do aplikacji Swing przeglądarka komunikuje się ze stronami internetowymi, a nie bezpośrednio z komponentami Java.

Aby odwzorować żądanie klienta na konkretny, stanowy komponent bean sesji, kontener EJB dba tylko o identyfikator dostarczony przez serwer proxy SFSB. Nie widzi, czy połączenie pochodziło z kodu w module webowym i nie może/nie powinno naprawdę mieć dostępu do żadnego kontekstu HTTP.

Warstwa internetowa, która jest kodem klienta, który uzyskuje dostęp do SFSB, musi "wstrzymywać się" z konkretnym odwołaniem do proxy. Trzymanie się czegoś w warstwie internetowej zwykle oznacza przechowywanie go w sesji HTTP.

Istnieje jednak technologia mostu o nazwie CDI, która umożliwia automatyczne połączenie. Jeśli dodasz notkę do SFSB za pomocą CDI o numerze @SessionScoped i uzyskasz odwołanie do SFSB poprzez CDI (np. Używając @Inject), nie musisz ręcznie umieszczać swojego SFSB w sesji http. Jednak poza sceną CDI zrobi to dokładnie.

Answer 2

Trzeba zdefiniować Bean z @SessionScoped zamiast @RequestScoped (jeśli szukasz HttpSession równoważne rozwiązanie)

coś podobnego

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

Prosze zapoznać się z następującymi (wyjaśnione szczegółowo)

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