java

Krótka historia o GlassFish4 i BeanManager

W aplikacji Java EE6, nad którą pracuję, wykorzystuję CQRS. W związku z tym korzystam z dosyć rozbudowanej floty Commandów i Handlerów. Aplikacja na starcie wyszukuje wszystkie Handlery i zapisuje mapowanie Command na Handler. Aby uzyskać listę wszystkich handlerów korzystam z BeanManagera. Samo pozyskanie instancji BeanManagera odbywa się w następujący sposób:

Gdy mamy już BeanManagera możemy przejść do sedna sprawy. Oto CommandHandler:

Sama rejestracja handlerów wygląda w ten sposób:

Kod bez problemów działał na JBossie oraz Resinie. Po przesiadce na GlassFisha 4 zaczęły się schody – metoda getBeans zaczęła zwracać pusty zbiór. Korzystanie z aplikacji stało się niemożliwe, gdyż nie działało nawet logowanie. Musiałem więc przyjrzeć się temu kodowi bliżej.

Klasa LoginHandler implementuje CommandHandler. Dodatkowo pamiętamy, że początkiem wszystkiego w Javie jest klasa Object, tak więc mamy taką oto hierarchię:

Posiłkując się IntelliJ oraz debugiem za pomocą getBeans(Object.class) uzyskałem dostęp do wszystkich zarejestrowanych beanów. Na tej liście znalazłem także moje problematyczne beany.

Zagłębiając się w problem natrafiłem na to, że metoda getTypes() rzeczonego handlera zwraca 3 wartości:

debug-pt1

Pomimo obecności CommandHandler na pozycji pierwszej, nie jest ona brana pod uwagę podczas wołania beanManager.getBeans(CommandHandler.class). Wynika to z tego, że CommandHandler przyjmuje typy generyczne, a GlassFish4 inaczej niż JBoss i Resin traktuje takie klasy.

Rozwiązanie, które udało mi się znaleźć to wprowadzenie typu nadrzędnego (bez generyków) wobec CommandHandler.

h2

Teraz należało jeszcze zmodyfikować metodę odnajdującą handlery:

I wszystko działa jak należy.

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*