Cannot cast an instance of "class jpa.entities.UserData (loaded by instance of org.glassfish.web.loader.WebappClassLoader(id=142))" to an instance of "class jpa.entities.UserData (loaded by instance of org.glassfish.web.loader.WebappClassLoader(id=129))"
dlaczego nie moge rzucic UserData u=(UserData) obiekt;
za pierwszym razem sie udaje za drugim juz nie.
Prawdopodobnie klasę jpa.entities.UserData masz na serwerze w dwóch jarach.
Rzutowanie się nie udaje, gdyż definicja tej klasy została załadowana przez dwa różne classloadery.
To czemu po restarcie serwera moge tego uzyc?
Mam taki mechanizm do logowania, ktory wyciaga mi dane logujacego sie uzytkownika z bazy danych. Dopoki sesja trwa moge smigac po calej apliakcji. Wyloguje sie i probuje zalogowac sie z powrotem i niestety juz nie moge bo mi blad rzutowania wyskakuje. w ogole nie rozumiem czemu Object podaje sie za klase UserData?
Nie wiem jakiego GlassFisha uzywasz, ale wszystkie maja ten sam problem: redeployment aplikacji nie zwraca ClassLoadera i klas przez niego zaladowanych, przez co powstaja okrutne memory leaki, i po kilku redeployach masz PermSpace czy inne bzdury. To by tlumaczylo dlaczego rzutowanie dziala po restarcie - nie ma zadnych smieciorow z poprzednich redeploymentow. Z kazdym kolejnym powstaje coraz wiecej ClassLoaderow ladujacych ta sama aplikacje w roznych wersjach, i po jakims czasie GF sie po prosru gubi. Jesli mialbym strzelac to uzywasz GF 3.x.
Uzywam 3.1 twierdzisz ze po przejsciu na apache ten problem powinien zniknac? Co moge zrobic zeby nie musiec migrowac na inny serwer?
Nie zrobisz prawdopodobnie nic, tak po prostu jest i wynika to z bugow GF jak i infrastrukture classloaderow. Pierwsze co bym na twoim miejscu zrobil to uzyl profilera i sprawdzil czy te memleaki nie sa powodowane czyms w Twoim kodzie. Po drugie, namowilbym pracodawce lub sam kupil narzedzie o nazwie JRebel - deplojujesz aplikacje raz, piszesz kod i on automatycznie jest podmieniany. Oczywiscie wylaczasz redeployment eclipse / nb i GF aby nie przeszkadzaly sobie. Licencja za to narzedzie jest smiesznie niska w porownaniu z tym co oferuje. Ja juz nigdy nie tkne Javy EE bez tego, chyba ze nie bedzie juz potrzebne i ktos mi udowodni.
Nie wiem rowniez o jakim Apache mowisz - apache nie ma servera aplikacji z prawdziwego zdarzenia, sa tylko jakies skladaki bazujace na tomcacie.
Zapisujesz obiekt UserData w sesji i używasz redeployu? To by wyjaśniało problem.
Przy zmianie serwera problem nie zniknie. To nie jest bug GF.
Możesz zrobić jedną z następujących rzeczy:
-zamiast zapisywać obiekt UserData, zapisz tylko typy proste wchodzące w jego skład (String, int, itp).
-zserializuj UserData do tablicy bajtów i to zapisz w sesji. Taką tablicę powinno dać się zdeseralizować po redeployu (UserData musi oczywiście implementować Serializable).
-umieść klasę UserData w osobnym jarze, który nie będzie redeployowany
Tutaj wyjaśnienie jak działa redeploy (Session Persistence został dodany do GF 3.0):
http://zeroturnaround.com/blog/rjc301/
Dzieki, te wskazowki jak i pozostala zawartosc strony pomogla mi zrozumiec temat. Moim bledem bylo myslenie ze moge zrobic klase ktora laczy funkcjonalnosc kilku kontrolerow na raz. teraz chcac wyluskac dane z jakiejs tabeli korzystam z jej kontrolera (mechanizm wygenerowany przez JPA).