Dostęp do stateful EJB z poziomu message driven beans

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?

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?

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.

@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.

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.

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?

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.

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 ;-)

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.