Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2

Rozpocząłem lekturę pierwszej książki o najnowszych specyfikacjach spod parasola Java EE 6 - Pro JPA 2: Mastering the Java Persistence API z Apress. Po kilku dniach znalazłem się przy rozdziale 6tym i muszę przyznać, że minęło niewiele ponad 150 stron (z prawie 400), a ja jestem padnięty nawałem informacji. Książka pretenduje do miana książki roku w moim osobistym rankingu książek informatycznych ze względu na formę przekazywania wiedzy w sposób dokładny i przystępny. Mnogość przykładów i wyjaśnień nie pozostawia złudzeń, że to prawdziwa składnica wiedzy mimo, że do końca jeszcze daleko - ja już mam wrażenie, jakbym znał specyfikację JPA2 od podszewki. Oczywiście nie znam, ale moja wiedza teoretyczna wzrosła znacząco. Bardzo podobają mi się dywagacje nt. różnych wzorców projektowych i ich znaczenia w ewolucji JPA2, albo odwrotnie, ich uproszczeniom ze względu na zmiany w JPA2. W przypadku poprzednich książek, jakie ostatnio przeczytałem, normą było przejście przez 1 rozdział w ciągu 1 dnia. Z "Pro JPA 2: Mastering the Java Persistence API" sytuacja zmieniła się diametralnie - nie rozdział/dzień, ale rozdział/3 dni zdaje się być bardziej odzwierciedlający rzeczywistość. Nie sądzę, aby wynikało to z braku cierpliwości, czy coś w ten deseń, ale po prostu z natłoku informacji, jakie przewijają się przez każdą przeczytaną stronę. Jeśli do tej pory, zaznaczałem kilka fragmentów tekstu do późniejszej analizy, to teraz są to całe sekcje (!) Jestem przerażony skomplikowaniem JPA, skoro potrzebna była taka książka, aby wyjaśnić zasady rządzące specyfikacją. Nie jest to wcale wina JPA, ale samego problemu obiektowej reprezentacji danych relacyjnych, którego rozwiązania szukano przez tyle lat i wciąż nie ma tego jedynego.

Pod wpływem uroków JPA2 z "Pro JPA 2: Mastering the Java Persistence API" postanowiłem zestawić środowisko do nauki specyfikacji i tak powstał artykuł Java Persistence (JPA) 2.0 praktycznie - zestawienie środowiska z EclipseLink i Apache Maven 2. Początkowo spisywałem kroki, aby przymierzyć się do screencastu, ale skoro już pojawił się artykuł, pomyślałem, że z nim zawojuję świat :) W artykule wykorzystałem EclipseLink (referencyjna implementacja JPA2), Apache Maven 2 oraz NetBeans IDE i Mercuriala. Pomyślałem o wystawieniu projektu w sieci w jakieś przystępnej formie i padło na Google Code z włączonym Mercurialem. W ten sposób można popróbować się z rozproszonym repozytorium hg i JPA2 jednocześnie. To lubię. Uwagi mile widziane.

p.s. Dostałem informację od Suna, od Oliwi, w związku z tematem Pakiety certyfikacyjne od Suna za 600 PLN do końca stycznia. Dzisiaj, 28.01.2010, jest ostatnim dniem ważności oferty. Śpieszcie się!

Koniec lektury "WebSphere Application Server 7.0 Administration Guide" - ponownie jedynie "może być"

W samą porę uporałem się z kolejną książką o IBM WebSphere Application Server V7 - WebSphere Application Server 7.0 Administration Guide Steve'a Robinsona wydawnictwa Packt z sierpnia 2009. Mam już dosyć tych administracyjnych broszur o wszystkim i o niczym. Nie powiem, że nie nauczyłem się niczego, bo minąłbym się z prawdą, ale poświęcony czas nie został zrekompensowany. Zdecydowanie więcej było czytania niż wiedzy.

Na rynku są dwie pozycje o WASv7, które miałem okazję przeczytać i każda z nich to więcej stron niż wiedzy. Szczęśliwie, ta pozycja opisała konfigurację WASv7 z OpenLDAP i Oracle XE. To właśnie te perełki, które powodują, że zniesmaczony zawartością, trafiając na nie, wraca nadzieja na kolejne. Ale tym razem, nie było więcej. Zdecydowanie za mało o nowościach WASv7, poza agentem administracyjnym. Jak to ujął autor na okładce książki "This book is for administrators with some experience in Java who want to get started with WebSphere", ale nie zgodzę się z zakończeniem "Existing WebSphere users will also find the book useful, especially as there are so many fresh features in the new version", bo, jak już wspomniałem, owych, nowych funkcjonalności jak na lekarstwo. Wiele literówek i pomyłek wcale nie poprawia ogólnej oceny książki. "Może być" oddaje zawartość książki.

Zainteresowani moją recenzją książki w języku angielskim (na potrzeby programu "Książka za recenzję") znajdą ją na moim Wiki - Book review: WebSphere Application Server 7.0 Administration Guide. Zainteresowani lekturą książki mogą ją znaleźć w "Bibliotece Warszawskiego JUGa". Polecam ją jedynie najbardziej zdeterminowanym aktualnym bądź przyszłym entuzjastom WASa. Resztę kierowałbym do WebSphere Application Server Version 7.0 Information Center.

Ale skąd owe "w samą porę", które otwiera ten wpis?! Od kilku dni trwa dyskusja nt. JAX-WS i podejścia między "code-first" a "contract-first" w komentarzach do Przygotowywanie (się do) projektu z JAX-WS i Apache Maven - modularyzacja wychodzi sama. W pełni formy i projektowego doświadczenia, Artur Karazniewicz nie daje za wygraną w batali o sensowność między tymi dwoma podejściami. Moje doświadczenie nie pozwala mi wyjść poza ramy "code-first", bo nad tym da się panować Javą. W konkurencyjnym podejściu króluje WSDL, którego tworzenie może przyprawić o ból głowy. To jednak, w/g Artura, to dobre podejście, zgodne z nurtem - najpierw kontrakt, a później developerka. Tym sprowokował mnie do lektury najnowszej specyfikacji JAX-WS 2.2 (JSR 224), aczkolwiek już obserwuję jego ciągoty w stronę JAX-RS (JSR 311). Nie zapominam też wciąż o mojej ulubionej specyfikacji EJB 3.1 (JSR 318) i jej okolicach. Czytania co nie miara :)

jacek.hostingjava.pl - z podziękowaniami od JSystems

Jeszcze w 2009 na GoldenLine trafiłem na wątek dotyczący hostingu Javy w Polsce - gigantyczne rozbieżności w cenach hostingu Javy.dlaczego?.... Bez wahania uderzyłem do Andrzeja Klusiewicza, który jest właścicielem JSystems, który z kolei jest właścicielem hostingjava.pl. Po kilku dniach otrzymałem propozycję konta na ich systemie w ramach niewielkiej reklamy w społeczności (co właśnie czynię). Taki układ partnerski - ja pomagam im, aby oni pomogli mi. Nie mogłem życzyć sobie ciekawszej propozycji! Od razu się zgodziłem.

Trwało to trochę zanim się wszystko u nich zestawiło, ale ostatecznie cierpliwość została wynagrodzona i mam swój serwer aplikacyjny Apache Tomcat publicznie - http://jacek.hostingjava.pl. Ciekawe, że rozważają wejście na rynek z GlassFishem i/lub JBossem - hosting glassfish, jboss- czy potrzebny?, więc skoro im się chce, to mi również. Z Tomcatem i Grails na razie mam wszystko. Pełen serwer aplikacyjny, np. taki GlassFish v3 z Java EE 6 byłby ciekawą propozycją, ale nie widzę, dla niego zastosowania teraz. Może później. Teraz pozostaje jedynie (?) popracować nad swoimi aplikacjami i je wystawić do publicznego użytku.

Kiedy planowałem stworzenie własnego serwisu javowego z elementami społecznościowymi, serwer stanowił jeden z niebagatelnych problemów finansowych. Pojawiła się propozycja z zespołu dWorld.pl, ale moje "Ja chcę od zera, po swojemu" wzięło górę i postanowiłem iść drogą samotnego wilka szukającego swojej watachy. Bodajże rok temu, wspólnymi siłami z Mateuszem Mrozewskim, powstawał projekt nauczyciel, a już teraz można się nim pobawić pod adresem http://jacek.hostingjava.pl/nauczyciel-0.1.1/ (niech ta wersja w adresie siedzi, bo to prototyp, który niedługo i tak powinien zniknąć z Sieci). Miłej zabawy!

Gdyby komuś przyszło zapytać mnie o wrażenia z nowego serwisu, to śpieszę donieść, że poza założeniem konta (wersja podstawowa) i uruchomieniem aplikacji, nie mam ich wiele. Całość zajęła mi niespełna 5-10 minut, więc wybaczcie, że nie napiszę więcej. Świadomie wybrałem najniższy pakiet, aby poczuć klimaty nowych inwestycji, w których często największą bolączką jest kaska. Każdy grosz się liczy, a w ten sposób moje wrażenia będą bliższe realiom innych, spragnionych własnego hostingu javowego, ale bez pieniędzy.

Pakiety certyfikacyjne od Suna za 600 PLN do końca stycznia

Końcówka roku to dobry moment na jego podsumowanie i podjęcie decyzji odnośnie nowego. Pewnie niejednego z Was męczyło przeświadczenie o mizerności mijającego roku i postanowienie poprawy w kolejnym, co zwykle znowu kończy się nadmiarowymi planami, których spełnienie i tak przyniosłoby niewiele. Tak też u mnie zwykle bywa, że postanawiam wiele, a realizuję niewiele. Oby Wam się to nieprzytrafiało w tym roku i lepiej postanowić mniej i zrealizować wszystko niż postanowić zbyt wiele. Docelowo najważniejsze jest nasze samopoczucie, które szkoda byłoby popsuć na własne życzenie zbyt wygórowanymi postanowieniami. W końcu, nasze życie to nie ciągła praca w korporacji, a po co dobijać się wyśrubowanymi wymaganiami w stosunku do siebie "po godzinach".

I tak możnaby jeszcze długo, ale tutaj o Javie ma być, a nie o mglistych marzeniach ściętej głowy. "Mnie to lotto" jeszcze mnie nie dotyczy, więc humor poprawiam sobie kolejnymi certyfikatami, co po części rekompensują mi niespełnione postanowienia z innych dziedzin. Kilka certyfikatów już poszło na półkę "Zdane", a kilka z nich jeszcze oczekuje na swoje 5 minut.

Pamiętam, że podczas organizowania spotkania z Kirkiem Pepperdine w ramach Warszawa JUG, Sun zaoferował nam nie tylko strawę na to spotkanie, ale i zniżki na certyfikaty javowe. Nie byłoby w tym nic nadzwyczajnego pod koniec roku, kiedy firmy pchają na rynek produkty w korzystnych cenach, aby podbić zyski, ale ta konkretnie oferta wydała mi się interesująca (pamiętam pewną rozmowę, w której uczestniczyłem jako kupujący, który upierał sie przy wyższej cenie, która przypominała targowanie z "Żywota Briana" Monty Pythona) - w ramach tej ceny mamy również możliwość podejścia do egzaminu testowego. Wszystko za 600 PLN. Nie raz słyszę o planach innych z światka javowego i wciąż przewija się jedno - zdać ten czy tamten egzamin. Mimo, ze zwykle przeszkodą jest brak czasu, to jak mawiał Grzesiek Duda (a może to był Radek Holewa):

"Jeśli nie masz czasu na zrobienie czegokolwiek nowego, to zrobienie chociażby jednej z tych rzeczy nie zmieni tego stanu, a zawsze to jedna rzecz do przodu."

Nie jestem pewien, czy szło to dokładnie tak, ale w moim przypadku sprawdza się ta wersja (może stąd brak wyników "na poziomie" i wszystko idzie "po łebkach"?).

Wracając do Suna i jego oferty certyfikacyjnej, to mamy do dyspozycji wszystkie javowe w cenie, która powinna dać się rozliczyć w naszych korporacjach. To w końcu dla dobra wspólnego. Najważniejsze, że kupujemy pakiet teraz, do końca stycznia 2010, a zdajemy do końca roku. Jeśli potrzebujesz dodatkowego bodźca certyfikacyjnego, to świadomość posiadania już zapłaconego egzaminu spełni się w tej roli doskonale. Może i mi w końcu powiedzie się przy SCWCD i SCEA.

Pełna treść oferty od Suna (za ich pozwoleniem):

W ramach oferty mogą Państwo kupić vouchery na wymienione poniżej certyfikacje z pakietem ePractice (pytania testowe). Wysyłając zamówienie należy wpisać kod oferty PL_EXL

CX-310-065 + WGS-PREX-J065C Sun Certified Java Programmer (SCJP)
http://www.sun.com/training/catalog/courses/WGS-PREX-J065C.xml

CX-310-083 + WGS-PREX-J083C Sun Certified Web Component Developer (SCWCD)
http://www.sun.com/training/catalog/courses/WGS-PREX-J083C.xml

CX-310-091 + WGS-PREX-J091C Sun Certified Business Component Developer (SCBCD)
http://www.sun.com/training/catalog/courses/WGS-PREX-J091C.xml

CX-310-230 + WGS-PREX-J230C Sun Certified Developer For Java Web Services (SCDJWS)
http://www.sun.com/training/catalog/courses/WGS-PREX-J230C.xml

CX-310-110 + WGS-PREX-J110C Sun Certified Mobile Application Developer (SCMAD)
http://www.sun.com/training/catalog/courses/WGS-PREX-J110C.xml

CX-310-052 + WGS-PREX-J052C Sun Certified Enterprise Architect (SCEA)
http://www.sun.com/training/catalog/courses/WGS-PREX-J052C.xml

Cena katalogowa każdego z powyższych pakietów to 750 PLN + 165 PLN = 915 PLN
Cena dla uczestników spotkania: *600 PLN* za pakiet

Oferta ważna jest do końca stycznia 2010 r.

W przypadku pytań proszę o kontakt,
Oliwia Łączyńska

--
Sun Business Development Manager Sun Learning Services,
SUN Microsystems Poland Sp. z o.o.

60. spotkanie Warszawa JUG - Sebastian Pietrowski i Michał Karwański z "Hmm Java jawą, a co z iPhone?"

Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 60. spotkanie, które odbędzie się we wtorek, 26. stycznia o godzinie 18:00 w sali 5440 Wydziału MIM UW przy ul. Banacha 2 w Warszawie.

Temat: Hmm Java jawą, a co z iPhone?
Prelegenci: Sebastian Pietrowski (aka Pedro) & Michał Karwański (aka Karwer)

Prezentacja obejmie demonstrację środowiska programistycznego na platforme iPhone oraz poruszy kwestię, czy warto inwestować swój czas w naukę nowej rzeczy, czy nie lepiej wybrać platformę javopodobną jaką jest Android.

Oprócz filozoficznych rozważań nie zabraknie "twardej treści" w postaci programowania na żywo z Xcode, językiem Objective-C i prawdziwym iPhone

Sebastian i Michał są absolwentami Wydziału Informatyki Uniwersytetu Warszawskiego. O Pedro już kiedyś było (przy okazji prezentacji o Ruby on Rails 06.02.2007), Karwer natomiast to cicha gwiazda, mistrz Polski w sudoku, wielokrotny reprezentant Polski na międzynarodowych konkursach sudoku oraz łamigłówkach. Jeżeli zauważysz człowieka, który w minutę rozwiązuje sudoku, w którym z ledwością w tym czasie wpisałeś 1 cyfrę, to znaczy, że masz do czynienia z Karwerem.

Planowany czas prezentacji to 1,5 godziny, po której planuje się 15-30-minutową dyskusję.

Wstęp wolny

Zapraszam w imieniu prelegentów i grupy Warszawa JUG!

Przygotowywanie (się do) projektu z JAX-WS i Apache Maven - modularyzacja wychodzi sama

Po tych moich certyfikacyjnych wojażach i bojach z recenzjami (jeszcze jedna czeka w kolejce do napisania) wracam (na blogu) do tematu mojego obecnego projektu, którego pierwsze rezultaty można było "podziwiać" w Każdemu będzie w końcu dane - wreszcie Java EE 5 w projektach!.

Komentarzy posypało się co nie miara, za co wszystkim dziękuję, bo chciałbym móc powiedzieć, że to nie moje, albo że miałem jedynie 5-10 minut na poprawki przed publikacją, aby wybronić się z kilku, ale nic z tego. Wszystko, co opublikowałem było moje na bazie tego, co nie było moje :] Migracja miała na celu wypuszczenie działającego rozwiązania możliwie niewielkim nakładem pracy. Udało się. Jakkolwiek nie oznacza to zakończenia prac nad tym "dziwolągiem", ale przyświecał mi jeden cel - dzisiaj testuję prototyp, aby zweryfikować mój punkt widzenia, aby jutro i w kolejnych dniach wyciosać coś rzeczywiście przyzwoitego. Od niewielkiego tworu, ale działającego, do większego, bardziej naładowanego wzorcami i dobrymi praktykami, i wciąż działającego. Takie iteracyjne programowanie. Prace trwają.

Dzisiaj postanowiłem wprowadzić zmiany w obszarze zarządzania projektem, w którym można wyróżnić część serwerową (uruchomioną w centrali) oraz część kliencką. Ich zależność polega na interfejsie, z którego korzystają. W tym przypadku nie tylko interfejs programistyczny (w sensie programowania w Javie), ale również technologiczny (w sensie wykorzystania technologii/szkieletu aplikacyjnego w Javie) łączy oba moduły. Skorzystałem z technologii Web Services (JAX-WS), więc moduł centralny wystawia usługę sieciową, którą konsumuje moduł kliencki. Logiczne, co?

I tutaj natrafiłem na problem zdefiniowania zależności między modułami. Gdyby założyć, że część serwerowa jest aplikacją webową, to w jaki sposób określić zależność w module klienckim? Nie ma jak, bo war to podział technologiczny, a nie programistyczny i nie tędy droga. Potrzebuję zdefiniować SEI (ang. Service Endpoint Interfejs), abym na nim oparł technologiczny moduł serwerowy i programistyczny, kliencki. Moduł serwerowy to war, który zanurzy moduł SEI, z którego będzie mógł skorzystać moduł kliencki.

Teraz jest dla mnie jasny komentarz Artura Karazniewicza (aczkolwiek jego pierwszy "wyjazd" był do kosza, co się ostatecznie stało :)):

"Po drugie uniezależnienie samego WebService od implementacji endpointu w java (zastosowanie SEI oraz nazwanie poszczególnych elementów WSDL w adnotacjach WebService, WebMethod itd.)."

Początkowo pomyślałem "Kto by się tym przejmował?!", ale teraz samo rozczłonkowanie projektu na moduły wymusiło na mnie poćwiartowanie modułu serwerowego z wydzieleniem modułu z SEI. Inaczej po prostu nie dałoby rady. Do mnie przemawiają przykłady, co daje mi dane podejście i w tym przypadku samo stwierdzenie "Bo tak się robi. Bo to dobra praktyka." to zdecydowanie za mało. Potrzebuję konkretów, a nie kiwania głowami, że tak się robi, a kiedy zapytać "Dlaczego?", nikt nie jest skłonny wytłumaczyć.

Bardzo ucieszyłem się, kiedy pojawiły się komentarze wskazujące konkretne błędy z chociażby skromną, ale zawsze, próbą wytłumaczenia "Dlaczego nie". Niestety pojawiły się też takie ogólnikowe, zrób to, zrób tamto, bez jakiegokolwiek wyjaśnienia "Dlaczego". A szkoda, bo jestem w stanie wyobrazić sobie niedoświadczonych programistów, którzy postawieni w tej roli, w jakiej ja byłem przed chwilą - wystawienia ich kodu na publiczną krytykę - dostają multum dobrych rad, które są dobre jedynie z ich nazwy. Co mi po dobrej radzie, jeśli nie dostaję racjonalnego ich wytłumaczenia? Są dla mnie równie wartościowe, jak wskazanie palcem, co mam zrobić...milcząco.

Zestawiam projekt z pomocą Apache Maven, bo nie tylko wymusiło to na mnie poćwiartowanie (aka zmodularyzowanie) aplikacji, ale również uniezależni mnie od zależności środowiska programistycznego (IDE). Do tej pory w zespole królował Eclipse/RAD. Teraz, z wprowadzeniem mnie do zespołu, wszedł NetBeans IDE (bo jakoś łatwiej mi było stworzyć i przetestować Web Service), a ostateczny cel to uruchomienie narzędzia budowania aplikacji bez udziału ludków z zespołu. Bez wykorzystania Apache Maven, czy jemu podobnego rozwiązania, nie byłoby to możliwe.

Zastanawiam się, jak testować działanie usługi sieciowej? Czy w ogóle warto, skoro mogę przetestować implementację bez narzutu infrastruktury JAX-WS? To w końcu "oznakowane" POJO? A co z klientem? On jest zależny od wygenerowanego przez wsgen. Jak sobie z tym tematem poradzić? Może po prostu zaniechać testowania komunikacji usługa-klienta, bo to ma działać (jest poza moją kontrolą i jestem tego klientem), a przetestować metody, które otrzymają wynik wywołania przesłoniętego zaślepką (ang. mock object)? Rady mile widziane (zlitujcie się jednak nade mną i dodajcie słów kilka dlaczego, albo chociaż odnośniki do dokumentacji).

Recenzja "GlassFish Administration" z Packt - ogólnie, może być

Jeszcze w grudniu zeszłego roku zostałem poproszony o recenzję nowej książki GlassFish Administration wydanej przez Packt w tym samym miesiącu. Długo się bidulka naczekała, aż się za nią wezmę i dopiero kilka dni temu zabrałem się za jej lekturę. Sądziłem, że będę mógł zapoznać się z nowinkami najnowszego wydania GlassFish v3, który nie tylko, że jest implementacją referencyjną dla Java EE 6, ale również zmigrował do OSGi. I na tym się skończyło. Sądziłem, że będzie o v3, a było o 2.1.1. Nie było też nic o OSGi. Cóż nie można mieć wszystkiego.

Ogólna ocena to "może być". Nie należy spodziewać się cudów administracyjnych wysokiego lotu, a jedynie przegląd możliwości GlassFish v2. Podkreślam słowo "przegląd", bo nie można tej książki nazwać encyklopedią administracji GFv2, a jedynie kompendium. Czyta się przyjemnie, ale wiedzy znacząco nie przybywa. Coś mi się wydaje, że to (przed)ostatnia książka o administracji z Packt. Mam ich już dosyć. Kiedy już pojawi się jakaś zajawka czegoś ciekawego w książce, to kończy się właśnie na tej zajawce. Zero zgłębiania się w bardziej zaawansowane tematy, jak chociażby pisanie skryptów administracyjnych. Po prostu przegląd i tyle.

Zainteresowanych recenzją zapraszam do lektury Book review: GlassFish Administration, a samą książką na priv, bo właśnie trafiła na półki Biblioteki Warszawskiego JUGa i jest gotowa do publicznej konsumpcji. Wiedzy specjalnie nie przybędzie, ale chociażby dla poprawienia ogólnej znajomości GFv2 i samego angielskiego można się z nią popróbować. A może jednak będzie coś w niej odkrywczego?! Jest też darmowy rozdział 6. "Configuring JMS Resources" w formacie PDF, który okazał się być jednym z lepszych w tej książce.