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!
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ńWitam!
OdpowiedzUsuń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?
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.
OdpowiedzUsuńp.s. Odpowiedź również w wątku na GL, na który *przypadkiem* dzisiaj trafiłem. Niesamowite!