04 października 2007

Kwadrans w Bibliotece z JSF 1.2, EJB 3.0 i JPA

Podczas ostatniego spotkania Warszawa JUG Wiktor Gworek przedstawił temat związany bardzo blisko z tematami, z którymi ostatnio przyszło mi się zmagać - głównie JPA oraz JSF. Jakież było moje zdziwienie, kiedy znaleziska jakie udało mi się znaleźć i z których byłem niezwykle dumny, pojawiły się na...prezentacji Wiktora (!) Moje zdziwienie było tym większe, kiedy Wiktor przedstawił się jako 2-latek w tworzeniu aplikacji z Korporacyjną Javą, a może nawet z jej standardową wersją. Na szczęście jednak Wiktor skoncentrował się na zestawieniu całego środowiska poza serwerem aplikacji Java EE 5, co pozwoliło mi na zachowanie twarzy i opisanie moich dokonań w postaci kolejnego artykułu Kwadrans w Bibliotece z JSF 1.2, EJB 3.0 i JPA, który opisuje aplikację Biblioteka opartą o JavaServer Faces (JSF), Enterprise JavaBeans 3.0 (EJB3) oraz Java Persistence (JPA) uruchomioną na serwerze Glassfish v2. Pomysł na artykuł zaczerpnąłem z wątku hibernate one-to-many - czy tak? na pl.comp.lang.java. Nie będąc pewny odpowiedzi postanowiłem zestawić środowisko i stworzyć aplikację, aby znaleźć odpowiedź empirycznie. Jestem w trakcie testowania NetBeans IDE 6.0, więc pozostało usiąść i stworzyć aplikację. Postanowiłem wykorzystać wszelkie dobrodziejstwa płynące z Korporacyjnej Javy 5 i minimalizowałem kod potrzebny do ukończenia przedsięwzięcia. O tym, co wyszło można przekonać się w artykule i załączonym do niego kodzie źródłowym aplikacji. Mnie się podoba - szczególnie wykorzystanie konwertera w JSF i automatyczne zarządzanie transakcjami przez serwer, gdzie wraz z wykorzystaniem transakcyjnego zarządcy trwałego dostęp do danych jest niezwykle prosty. Komentarze mile widziane!

3 komentarze:

  1. Wyjdzie na to, że się ciągle czepiam Twoich artykułów, ale 'Ciekawostką strony jest wykorzystanie konwertera AutorConverter (o którym za moment).' to przedostatnie zdanie o konwerterze w artykule - chyba gdzieś wcięło jakiś rozdział ;)

    OdpowiedzUsuń
  2. Witam!

    Mam do tego artykulu pewne, mam nadzieje ze ciekawe nie tylko dla mnie pytanie:) Zalozmy ze jednym zamachem(w jednej metodzie) updateujemy informacje o wielu ksiazkach na przyklad iterujac po ich liscie i w petli jezeli ktores sie zmienily, updateujemy takie informacje do bazy danych. Moje pytanie brzmi: jak oprogramować taki przypadek od strony transakcji? tzn, jeśli update jednej ksiazki się nie powiedzie, jak wycofać update poprzednich?

    Dodam ze raczkuję w technologiach OR/M i EJB wiec pewnie wielu osobom pytanie wyda się śmieszne. Walczyłem (nie wiem czy dobrze) z @TransactionManagement... jest jakiś prosty/dobry/lepszy sposób na uzyskanie takiego efektu?

    OdpowiedzUsuń
  3. Tworzysz projekt EJB dla ziarna EJB oraz projekt webowy (WAR) dla ziarna zarządzanego JSF. Spinasz oba EARem i voila. Po przerwie z Grails widać potrzebę powrotu do źródeł, czyli Java EE. Dzięki za natchnienie! Obowiązkowo raportuj wynik.

    p.s. Odpowiedź również w wątku na GL, na który *przypadkiem* dzisiaj trafiłem. Niesamowite!

    OdpowiedzUsuń