Mój prezent z okazji święta - Aplikacja korporacyjna z JPA w trybie JTA z GlassFish i PostgreSQL

A co! Każdemu należy się prezent z okazji święta Dnia Dziecka bez względu na wiek, więc moim prezentem jest spisanie moich przemyśleń nt. tworzeniu aplikacji korporacyjnej z JPA w trybie JTA z GlassFish i PostgreSQL w postaci artykułu Aplikacja korporacyjna z JPA w trybie JTA z GlassFish i PostgreSQL. Jest tam również użycie mechanizmu DataModel wspierającego działanie h:dataTable w JSF, więc dużo dobrego do analizy.

Po powrocie z Ukrainy, gdzie miałem możliwość spotkać się z wykładowcami Kijowskiej Politechniki i w wolnych chwilach podczas przelotów naczytałem się i postanowiłem popróbować się z konfiguracją JPA z transaction-type="JTA" oraz PostgreSQL. W zasadzie to zależało mi na utworzeniu aplikacji, która byłaby przyczółkiem dla utworzenia bardziej zaawansowanej aplikacji korporacyjnej, dzięki której będę mógł rozpocząć poznawać szczegóły specyfikacji Java EE. W kolejnych odsłonach aplikacji będzie można oczekiwać kolejnych usprawnień, jak wykorzystanie komponentu sesyjnego EJB 3.0 jako fasady dla encji i zniwelowania konieczności użycia mechanizmów obsługi transakcji bezpośrednio w kodzie komponentu zarządzanego JSF. Chciałbym uniezależnić się również o środowiska programistycznego IDE, czyli pojawiłby się również Apache Maven 2 czy alternatywni dostawcy JPA. Pora rozpocząć podsumowanie wiedzy odnośnie EJB 3.0 i JPA 1.0 i wreszcie zaspokoić swoje ego certyfikatem Sun Certified Business Component Developer (SCBCD) 5.0. Pamiętam ile mogłem nauczyć się podczas egzaminu SCJP 5 i jak wiele wyszło braków. Sądzę, że SCBCD może spełnić podobną funkcję - pogłębienie wiedzy odnośnie specyfikacji. Jeśli przy tym zdobędę certyfikat, to i dobrze (jest on potrzebny do podejścia do Sun Certified Enterprise Architect (SCEA), a o tym to jeszcze nawet nie myślałem, więc z SCBCD mogłoby być ciekawie. Przy okazji, czy ktoś z czytających rozważa SCEA, albo już posiada to cudeńko?).

Nie mógłbym nie wspomnieć o innej przyczynie spisania przemyśleń odnośnie wykorzystania usług serwera aplikacyjnego Java EE 5. Kilka dni temu otrzymałem list od Piotra Kochańskiego, który zwrócił mi uwagę na pewien niuans w wykorzystaniu JPA i mechanizmu wstrzeliwania zależności. Chodzi o wykorzystanie adnotacji @PersistenceUnit i @PersistenceContext. W zasadzie obie dotyczą tej samej funkcjonalności (tak w wielkim skrócie), ale pierwszy z nich jest stosowany dla przekazania referencji do fabryki PU podczas, gdy drugi jest przekazaniem kontekstu PU. I kiedy dopiszę, że pierwszy jest odporny na wielowątkowość, a drugi nie i że użycie drugiego było w servlecie wszystko powinno być jasne - moja aplikacja nie była odporna na wielowątkowość (!) W dodatku sam o tym niedawno wspominałem w kontekście komponentów zarządzanych JSF, które działają w zasięgu (ang. scope) session oraz application, więc z wielkim zadowoleniem przyjąłem uwagę Piotra. Jakby jeszcze było mało, właśnie dzisiaj natrafiłem na ciekawą wzmiankę o tym w artykule Using Java Persistence with JavaServer Faces Technology. Podsumowaniem mogłoby być stwierdzenie, że z prostotą w Java EE 5 idzie również większa odpowiedzialność i jest to przykład czułego miejsca w naszych aplikacjach korzystających z Korporacyjnej 5-tki. Wielkie dzięki Piotr za wychwycenie błędu! Jak zauważyłem, Piotr również spisuje swoje doświadczenia na stronie Xoft.pl, więc może odwdzięczę mu się tym samym?! ;-)

Wracając do artykułu to wspomnę, że natrafiłem na kilka miejsc, których nie miałem świadomości istnienia.

Jednym z nich był mechanizm DI w przypadku komponentu zarządzanego JSF z serwera aplikacyjnego (adnotacja @PersistenceContext) oraz samego środowiska JSF - plik faces-config.xml. Jeśli w konstruktorze korzystamy z obu elementów to z oczywistych względów DI z serwera nie będzie jeszcze wykonane i możemy być zaskoczeni nieprzyjemnym NullPointerException. Więcej o tym w kolejnych notatkach albo nawet i artykule.

Inną kwestią, która mnie zaskoczyła, było wykorzystanie JPA z JTA i uruchomienie EntityManager.merge po wywołaniu EntityManager.getTransaction. Jest to niemożliwe w konfiguracji JTA i kończy się wyjątkiem Exception Description: Cannot use an EntityTransaction while using JTA. W zasadzie jest to bardzo logiczne, że to monitor transakcyjny serwera aplikacyjnego Java EE zarządza transakcjami, ale możnaby oczekiwać, że...zostawiam dywagacje na później.

I na koniec coś, co oczekuje właściwego nagłośnienia, ale przy święcie nie mógłbym o tym nie wspomnieć - JAVArsovia. Grupa Warszawa JUG przygotowuje się do swojego debiutu jako organizator pierwszej konferencji-warsztatów technologii Java, która odbędzie się na Wydziale MIMUW. Więcej w kolejnej notatce...niebawem. Czas pozbierać wszystkie dane i rozpocząć promocję imprezki. Chciałbym, aby podsumowaniem sobotniej konferencji JAVArsovia był toast na Polach Mokotowskich, ale jak będzie zobaczymy. Prelegenci są, sala jest, chętni również, więc poza plakatem i promocją na forach jest wszystko. Dobrze byłoby rozpoczać promocję właśnie dzisiaj - 1 czerwca 2007. Jeszcze jest kilka godzin ;-)