Dostęp do stateful EJB z poziomu message driven beans

0

Witam

Mam utworzony stateful EJB, który przechowuje informacje konfiguracyjne. Następnie wysyłam message do topicu i message driven beans ją obsługują. Pytanie brzmi, czy możliwy jest dostęp do danych konfiguracyjnych w stateful EJB z poziomu MDB? Innymi słowy czy jest możliwość odwołania się po jakimś ID do konkretnego SF EJB?

0

Wydaje mi się że nie ma takiej możliwości. Bo przecież ten EJB ma określoną tożsamość tylko z punktu widzenia konkretnego użytkownika i w zasięgu określonej sesji. To co chcesz zrobić byłoby bardzo brzydkie :P Tym bardziej że jaką masz pewność ze to EJB w ogóle musiałoby istnieć w danej chwili? Nie możesz potrzebnych danych pobrać z tego stateful ejb i wysłać ich w wiadomości?

0
Shalom napisał(a)

Wydaje mi się że nie ma takiej możliwości. Bo przecież ten EJB ma określoną tożsamość tylko z punktu widzenia konkretnego użytkownika i w zasięgu określonej sesji.

Właśnie to chcę wykorzystać. Konfiguracja miałaby być właśnie pod konkretnego użytkownika i sesję.

Shalom napisał(a)

To co chcesz zrobić byłoby bardzo brzydkie :P Tym bardziej że jaką masz pewność ze to EJB w ogóle musiałoby istnieć w danej chwili?

Zawsze można sprawdzić czy obiekt jest null. :P

Shalom napisał(a)

Nie możesz potrzebnych danych pobrać z tego stateful ejb i wysłać ich w wiadomości?

Mogę, jest to pewna opcja, ale najpierw chciałbym wiedzieć, czy nie można tych danych uzyskać bezpośrednio z SF EJB.

0

@JamaycaMan brawo, ale zauważ że ten MessageDrivenBean musiałby skądś znać tego użytkownika i jego identyfikator sesji. Co więcej gdyby faktycznie mógł tak zrobić żeby "wydobyć" EJB na podstawie użytkownika i identyfikatora sesji to by był spory problem z bezpieczeństwem.

0
Shalom napisał(a)

zauważ że ten MessageDrivenBean musiałby skądś znać tego użytkownika i jego identyfikator sesji. Co więcej gdyby faktycznie mógł tak zrobić żeby "wydobyć" EJB na podstawie użytkownika i identyfikatora sesji to by był spory problem z bezpieczeństwem.

Ten problem akurat nie jest poważny, gdyż serwer jest pod moją kontrolą. Klient ma dostęp jedynie do servletów. User name i ID sesji można przesłać w messagu. Chciałbym uniknąć jednak przesyłania całej konfiguracji, gdyż może byc ona dosyć obszerna. Ale tak jak napisałem, opcja z przesyłaniem całej konfiguracji jest rozważana.

0

A jakis bean z metoda ktora umie pobierac konfig dla danej sesji? Mozna by wstrzyknac do MDB, ktory w jakis sposob , np. jako argument wiadomosci, pobralby identyfikator i wywolal metode ktora pobiera konfig?
Zwroc jednak uwage, ze cale to rozwiazanie jakies kulawe - MDB dzialaja asynchronicznie, wiec mozliwe potencjalnie, ze ktos sie zaloguje, costam zrobi, wysle wiadomosc na kolejke / topic, wyloguje sie, i dopiero wtedy ta wiadomosc zostanie przetwarzana. Wyloguje sie == sesja zostanie usunieta (zakladam ze mowisz o HttpSession, ale i inne typy powinny po sobie sprzatac gdy user sie wyloguje). I co teraz ma robic taki MDB?

0

Prawda, on ciagle pisze o SFSB. Jak poprawnie to zaimplementuje, i kontener nie zwleka z usuwaniem SFSB ktore nie sa potrzebne, to to nie zadziala.

0
mućka napisał(a)

A jakis bean z metoda ktora umie pobierac konfig dla danej sesji? Mozna by wstrzyknac do MDB, ktory w jakis sposob , np. jako argument wiadomosci, pobralby identyfikator i wywolal metode ktora pobiera konfig?

Czegoś takiego właśnie szukam. Jakiś przykład?

mućka napisał(a)

Zwroc jednak uwage, ze cale to rozwiazanie jakies kulawe - MDB dzialaja asynchronicznie, wiec mozliwe potencjalnie, ze ktos sie zaloguje, costam zrobi, wysle wiadomosc na kolejke / topic, wyloguje sie, i dopiero wtedy ta wiadomosc zostanie przetwarzana. Wyloguje sie == sesja zostanie usunieta (zakladam ze mowisz o HttpSession, ale i inne typy powinny po sobie sprzatac gdy user sie wyloguje). I co teraz ma robic taki MDB?

Co ma zrobić? Nic. Odbiera message, sprawdza czy ma dostęp do konfiguracji. Nie ma? No to niech user spada. Może jeszcze wysłać taki obrazek. http://g900.noop.pl/nie-robie.jpg ;-)

0

A ja nadal nie rozumiem jaki to w ogóle ma sens. Może te konfiguracje powinny być bardziej persystentne niż tylko na czas sesji? Rozwiązanie z dodatkowym beanem przypuszczalnie na takim mechanizmie by się opierało -> miałbyś beana który ma dostęp do konfiguracji (które są np. w Bazie) i zwraca je na podstawie identyfikatora.

1 użytkowników online, w tym zalogowanych: 0, gości: 1