27 listopada 2008

Niespodzianki NetBeans IDE 6.5

6 komentarzy
Pojawiła się długooczekiwana wersja NetBeans IDE 6.5. Zawiera wiele ciekawostek, z których najbardziej intryguje mnie wsparcie dla Groovy oraz Grailsów (aczkolwiek jeszcze nie znalazłem czasu, aby się zabrać za tę parkę z jego pomocą). Okazuje się jednak, że niespodzianki NetBeans IDE 6.5 czekają na nas już przy pierwszym uruchomieniu. W prawym, dolnym rogu pojawiła się ikona z chmurką informującą o aktualizacjach. Rządny wrażeń natychmiast podjąłem się ich aplikowania.

Jakież było moje zdumienie, kiedy po zalecanym, ponownym uruchomieniu NetBeans pojawia się komunikat o niemożności uruchomienia kilku z aktualizacji (!)

I to dokładnie o Groovy, który mnie intryguje. Miałbym odpuścić? Nie. Ponowne uruchomienie NetBeans i tym razem pojawia się komunikat o błędzie instalacji kolejnych wtyczek.

Po ręcznej aktualizacji wtyczki Groovy and Grails

za pomocą Help > Check for Updates

wszystko zagrało...chyba.

Już napotkałem jeden z błędów poprawnionych w kolejnych wersjach rozwojowych NetBeans IDE (należących do wersji 7.0), więc znowu przyjdzie mi dokonać aktualizacji, ale żeby już teraz, dzisiaj?! Nie! Poczekam jeszcze chwilę. Zgoda, dłużą chwilę, bo ostatnimi czasy bliżej mi do IntelliJ IDEA 8.0, która zdumiewająco łatwo spełnia moje niewygórowane oczekiwania związane z zarządzaniem projektami mavenowymi i możliwością debuggowania pracy Spring-DM 1.2.0 M2 (właśnie co się pojawił!). Jeszcze do niedawna rozpatrywałem jedynie pracę w Eclipse IDE i NetBeans IDE. Teraz całkowicie zapominam o Eclipse na rzecz IDEA. I wcale mi nie tęskno.

25 listopada 2008

Relacja z Warsjawa Eclipse DemoCamp 2008

11 komentarzy
Echa konferencji Warsjawa Eclipse DemoCamp 2008 z minionej soboty jeszcze nie cichną, a już w niektórych głowach zaświtał pomysł organizacji kolejnej konferencji. Powiedziałbym, że wielu z nas dopiero teraz zaczęła wracać do właściwego stanu równowagi między javą a światem realnym. Wszystko za sprawą niesamowitego klimatu konferencji Warsjawa Eclipse DemoCamp 2008 w Warszawie.

Zawsze marzyłem, aby doprowadzić nasze konferencje javowe do stanu, gdzie będą one traktowane jako platforma rozwijania wiedzy i kontaktów, i sądzę, że się udało. Niejednokrotnie było słychać uwagi dotyczące zbyt krótkich przerw, podczas których możnaby przedyskutować właśnie odsłuchany temat czy po prostu odsapnąć. W miłej atmosferze nauka przychodzi łatwiej, czas szybko mija, a zabawa podczas konferencji była przednia. Podczas rozmów dało się odczuć duże zainteresowanie tego typu imprezami, które pozwalają uzupełnić, jeśli po prostu nie pozwolić zasmakować, wiedzę na temat technologii javowych.

Czy to za sprawą opadów śniegu, który tego dnia przywitał uczestników, czy 5. piętra, gdzie odbywała się konferencja (a które dla wielu było nielada wyczynem wysokogórskim), czy też porannych godzin sobotnich, ale niektórym to nawet się zapomniało, gdzie są!

Tematem przewodnim konferencji był Eclipse, który "obsłużył" nasz gość specjalny Wassim Melhem z tematem Taking SQL IDEs from the Stone Age to the 21st century (ostatecznie zdryfował na tereny Eclipse RCP)

oraz Jacek Pospychała z Czy Eclipse RCP mieści się w przeglądarce?, aczkolwiek innych technologii nie zabrakło.

Można było wysłuchać Waldka Kota o Comet, Bayeux i mechanizm Publish-Subscribe poprzez HTTP

, Łukasza Lenarta o Dojo Toolkit

i mnie (wspieranego przez żonę telefonicznie) o OSGi/Spring-DM.

Zdumiewająco łatwo przyszło Tomkowi Zieleniewskiemu z TouK zachwycenie publiczności z tematem Telekomunikacja w Javie - kilka słów o konwergencji i usługach w telekomunikacji, a który zmagał się z początkowym przekonaniem publiczności o potencjalnie "sponsorskim przedstawieniu" (wierzcie mi, że gdyby tylko mógł zająłby nawet ponad 2h przedstawiając całą historię telekomunikacji od Bella do XXI wieku! ;-)).

Dyskusja z Waldim dodała jeszcze pikanterii całemu wystąpieniu. Niestety nie byłem obecny podczas prezentacji Tomka, więc magiczne 4 palce Waldiego są wciąż dla mnie zagadką.

O czym ten Waldi tak dyskutował?! Widziałem je podczas mojego chwilowego pobytu na prezentacji Tomka i zaraz po niej, więc musi być jakiś związek. Pomysły? Waldi nie pamięta.

Konferencja nie urealniłaby się, gdyby nie wsparcie naszego patrona - władz Wydziału Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego (MIMUW) oraz sponsorów (kolejność alfabetyczna): 7N, e-point, Eclipse Foundation, Javatech, JetBrains oraz TouK. Konferencja odbyła się w gmachu MIMUWu, a sponsorzy zadbali, abyśmy stanęli na wysokości zadania i przygotowali konferencję z właściwą oprawą - nagrodą główną było pokrycie kosztów przelotu, hotelu i wejściówki na 4-dniowy Jazoon 2009, katering z pączkami z rana, dwudaniowym obiadem oraz napojami przez cały dzień, a skończywszy na imprezie integracyjnej w Lolku z Bolkiem na pobliskich Polach Mokotowskich.

Niektórzy się na prawdę dobrze bawili, nieprawdaż? ;-)

Przypadkiem mieliśmy okazję "zestawić" konferencję wspólnie ze szkoleniem z NetBeans RCP, więc, podczas imprezy integracyjnej, gościliśmy również Toniego Epple (NetBeans Dream Team), Geertjan Wielenga oraz Karola Harezlaka.

Wystarczy spojrzeć na radość wygranych, aby uzmysłowić sobie klimat konferencji. Po prostu bajka!

Szczególne podziękowania należą się członkom Kapituły Warsjawa Eclipse DemoCamp 2008 w składzie (porządek alfabetyczny):
Ich zaangażowanie i bezinteresowność w dopięciu całego przedsięwzięcia jest nie do przecenienia. Cytując Łukasza (I już po...):

[...]dla większości uczestników było to tylko 7 godzin, dla innych 48 godzin - mocna ekipa z Trójmiasta (pozdrowienia!), 24 godzin dla Leszka, lider Szczecin JUG (mam nadzieję, że te wykłady nie były takie ważne ;-), nie wiem jak grupa z Poznania i z Lublina - 12 czy 20 godzin? A dla organizatorów plus / minus 1500 godzin.

Ze 153 uczestnikami (przy 214 zarejestrowanych, czyli 71,5% skuteczności) z planowanej małej Warsjawy zrobiła się całkiem pokaźna konferencja z udziałem znakomitości z całej Polski. Miło było spotkać się z załogami ze Szczecina, Trójmiasta, Lublina i Poznania (pominąłem jakieś miasto?). Byli też i młodzi adepcji sztuki javowej.

Najwyraźniej zainteresowanie jest i przy konferencjach GeeCON w Krakowie (maj 2009), Javarsovii 2009 (maj/czerwiec 2009) w Warszawie czy java4people (maj 2009) w Szczecinie już zapowiada się ciekawy rok konferencyjny 2009. A przecież wymieniłem tylko te najbardziej zacne ;-) Na pewno będzie ich jeszcze więcej.

Więcej wrażeń na zdjęciach z konferencji autorstwa Bolka i mojego. Kto nie był niech żałuje. Ja byłem, moja żona była, piwo piliśmy i znakomicie się bawiliśmy. Już teraz zapraszam na Javarsovię 2009. Na pewno będzie ciekawiej!

Tylko dlaczego ten Tomek tak patrzy na moją Agatę?! Grrr.....

18 listopada 2008

Warsjawa Eclipse DemoCamp 2008 w najbliższą sobotę

1 komentarzy
Warsjawa Eclipse DemoCamp 2008

13 listopada 2008

W sprawie EJB 3.0 - Jak pakować komponenty w plik .jar?

3 komentarzy
Dostałem dzisiaj wiadomość, w której padło pytanie o sposób dystrybucji komponentów EJB.

Studiuje sobie ksiazke Enterprise JavaBeans wydawnictwa O'Reilly o komponentach, oczywiscie jeszcze jestem w powijakach ale juz sporo(wg mnie:-) ) rozumiem. Nurtuje mnie jednak pytanie jak pakowac komponenty w plik .jar ktory pozniej wdrozymy na serwer aplikacji. Tzn czy idea jest umiesczanie wszystkie komponentow w jednym pliku .jar jako calej aplikacji np sklep.jar(zapewne nie bo po co bylby .ear ale to tylko moj punkt widzenia malego czlowieczka raczkujacego w technologii EE) jako calej aplikacji czy tez kazdego komponentu oddzielnie, czy umieszczac wszystkie komponenty encyjne w jednym sesyjne w drugim itd, a moze komponenty spojne ze soba logicznie czyli np komponent sesyjny bezstanowy majacy w sobie funkcje odnoszace sie do komponentu sesyjnego. Troche chaotycznie to wszystko napisalem ale mam nadzieje Jacku ze mi wybaczysz moja niewiedze w tej technologii.

I już zacząłem moją krótką odpowiedź, aż przypomniałem sobie podobne pytanie od kogoś innego, więc padło na odpowiedź publiczną na moim blogu. Oto ona.

Każde ziarno EJB w EJB 3.0 to fizycznie dwa pliki class - interfejs (biznesowy w sensie EJB) oraz jego realizacja (implementacja). Klasy w javie umieszcza się w pakietach (zalecane jest, aby nie korzystać z pakietu domyślnego, tj. zadeklarowanego, gdy nie korzystamy ze słowa kluczowego package). Rozmieszczenie klas w pakietach nie ma żadnego wpływu na ich zarządzanie przez kontener EJB. Kontener jest w tym względzie neutralny. Mając interfejs oraz klasę w wybranych pakietach (dalej nazwijmy je artefaktami programistycznymi) przychodzi do ich organizacji w postaci ich umiejscowienia w odpowiadającym pakietowi katalogu lub plikowi jar. Zalecane jest, aby do dystrybucji naszej aplikacji stosować format jar. Ile i jakie ziarna EJB będą w pojedyńczym pliku jar nie ma kompletnie znaczenia. Może być tak, że dla każdej pary interfejs+implementacja stworzymy dedykowane im pliki jar. Może być też tak, że wszystkie pary będą umieszczone w pojedyńczym, obszernym pliku jar. Z punktu widzenia EJB 3.0 nie ma to żadnego znaczenia, poza faktem ich widoczności w ładowarce klas dla naszej aplikacji.

Każdy serwer aplikacyjny (w tym również kontener EJB) tworzy sieć (graf skierowany w postaci drzewa) ładowarek klas, gdzie dla pojedyńczego pliku jar mamy dedykowaną ładowarkę. Jeśli ta ładowarka klas obejmuje wszystkie klasy uczestniczące w pracy ziarna EJB, przynajmniej interfejs oraz klasa realizująca, wszystko będzie w należytym porządku. Istnieje "pojemniejszy" format organizacji artefaktów aplikacji korporacyjnych w Java EE 5 - plik ear. W nim możemy umieszczać pliki jar i inne (na chwilę obecną nieistotne). Plik ear tworzy przestrzeń widoczności (poprzez dedykowaną ładowarkę klas) dla wszystkich plików jar, które są w jego strukturze. Jeśli zdarzy się stworzyć plik sklep-interfejs.jar oraz sklep-implementacja1.jar to tylko w sytuacji dostępności pierwszego możemy oczekiwać poprawnej pracy ziarna EJB reprezentowanego przez drugi plik jar. Najczęściej jest to realizowane poprzez skorzystanie z pliku ear jako formatu dystrybucji naszych ziaren EJB.

Można zapytać, dlaczego warto zadać sobie trud, aby dzielić naszą aplikację, opartą o kilka ziaren EJB, na kilka plików jar, np. jeden per ziarno, potencjalnie z plikiem zawierającym interfejs jako osobny plik jar? Oczywiście zwiększa to modularność aplikacji. Jakkolwiek z punktu widzenia specyfikacji Java EE 5 nie jest to prawdziwe stwierdzenie, gdyż w "gołej" Javie reguły rządzące widocznością klas nie są zbyt wyrafinowane i czy jesteś w jednym pliku jar, czy w wielu, nie ma to znaczenia (zakładając ich widoczność w ładowarce klas), to już w środowiskach OSGi tak nie jest. Ma to znaczenie? Oczywiście nie dla...niekorzystających z OSGi. W samej korporacyjnej javie umieszczenie jarów na ścieżce klas (dosłownie, w systemie plików, lub wirtualnie poprzez umieszczenie ich w tej samej ładowarce klas) już wystarczy. Modularność w Java EE 5 mamy przez zastosowanie ziaren EJB, a ich fizyczne rozmieszczenie na jeden czy kilka jarów nie ma żadnego znaczenia. Muszą być po prostu dostępne i tyle. W bardziej restrykcyjnych środowiskach, jak OSGi, podział na większą liczbę plików jar pozwala na stworzenie aplikacji bardziej modularnie patrząc na jej fizyczną strukturę. W OSGi jar tożsamy jest z podstawowym bytem OSGi - pakunkiem. Dla OSGi plik jar jest pewnym bytem, podczas gdy dla EJB 3.0 jest niczym (jest to jedynie format dystrybucji dla języka Java, ale EJB 3.0 już nie wie, ile i czy w ogóle korzystaliśmy z pliku jar lub symulowaliśmy go strukturą podobną do pliku jar - "rozpakowany jar", czy po prostu umieściliśmy odpowiednio wiele na ścieżce klas). Możemy uruchomić jeden pakunek OSGi z interfejsem (=jeden plik jar), a drugi pakunek dostarczyć później i zmieniać ich widoczność dynamicznie, podczas działania aplikacji. W EJB 3.0 nie ma już takiej funkcjonalności, aczkolwiek sam serwer może to udostępniać, np. będąc oparty o OSGi lub inny mechanizm.

Miało być krótko i mimo, że zahaczyłem o OSGi sądzę, że było. Pytania?

10 listopada 2008

Nazwa puli połączeń w Geronimo 2.1.x

0 komentarzy
Trochę czasu minęło od mojego ostatniego spotkania z Apache Geronimo i jakimś cudem zawsze udawało mi się uniknąć spędzania czasu nad konfiguracją puli połączeń do bazy danych. Tym razem było inaczej.

Połączenia do bazy danych w aplikacjach Java EE 5 zaleca się, aby oprzeć o wykorzystanie puli połaczeń zarządzanej przez serwer aplikacyjny. Wprowadzenie dodatkowej warstwy abstrakcji między wirtualną nazwą puli połączeń, z której pobierane są połączenia bazodanowe, a jej fizyczną reprezentacją w serwerze aplikacyjnym pozwala na oddelegowanie zadań jej zarządzania do serwera oraz jej właściwą konfigurację przez administratora serwera. W niewielkich zespołach podział na programistę aplikacji i administratora serwera zazwyczaj nie istnieje (i stąd najczęściej wynikają pytania o sensowność takiego podejścia), ale w większych (albo mniejszych, ale bardziej rozsądnie podzielonych) oddelegowanie zadań do właściwych członków zespołu ma znaczenie, chociażby na ich wykonanie z należytą starannością i w planowanym czasie.

Tym razem, w moim niewielkim projekcie, przyszło mi tworzyć aplikację opartą o JPA oraz zestawić pulę połączeń w Geronimo. Zazwyczaj nazwę puli umieszcza się w przestrzeni jdbc w JNDI, więc moja pula połączeń dostępna była jako jdbc/UsosDev.

Wystarczy, więc użyć tej nazwy w pliku /META-INF/persistence.xml, w sekcji <jta-data-source>UsosDev</jta-data-source> i załatwione.

Kluczem jest zapamiętanie, że wszędzie tam, gdzie potrzebna jest nazwa JNDI puli połączeń korzystamy z nazwy puli podanej w polu Name of Database Pool w asystencie Geronimo database pool wizard.

Podczas uruchomienia Geronimo z opcją -vv, np. ./bin/geronimo.sh run -vv pojawi się komunikat o uruchomieniu puli:
 15:48:36,015 INFO  [KernelContextGBean] bound gbean console.dbpool/UsosDev/1.0/rar?J2EEApplication=null,JCAConnectionFactory=UsosDev,
JCAResource=console.dbpool/UsosDev/1.0/rar,ResourceAdapter=console.dbpool/UsosDev/1.0/rar,ResourceAdapterModule=console.dbpool/UsosDev/1.0/rar,
j2eeType=JCAManagedConnectionFactory,name=UsosDev at name console.dbpool/UsosDev/JCAManagedConnectionFactory/UsosDev
Atrybut name wskazuje, pod jaką nazwą została zarejestrowana pula. W powyższym przykładzie będzie to UsosDev, a ja przez kilka dłuższych chwil oczekiwałem jdbc/UsosDev (!) i stąd poniższy komunikat błędu:
 Deployer operation failed: Unable to resolve reference "JtaDataSourceWrapper"
in gbean pl.jaceklaskowski.statystyki/przyklad/1.0/war?J2EEApplication=null,PersistenceUnitModule=WEB-INF/classes/,
WebModule=pl.jaceklaskowski.statystyki/przyklad/1.0/war,j2eeType=PersistenceUnit,name=usosPU
to a gbean matching the pattern [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "NonJtaDataSourceWrapper"
in gbean pl.jaceklaskowski.statystyki/przyklad/1.0/war?J2EEApplication=null,PersistenceUnitModule=WEB-INF/classes/,
WebModule=pl.jaceklaskowski.statystyki/przyklad/1.0/war,j2eeType=PersistenceUnit,name=usosPU
to a gbean matching the pattern [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
org.apache.geronimo.common.DeploymentException: Unable to resolve reference "JtaDataSourceWrapper"
in gbean pl.jaceklaskowski.statystyki/przyklad/1.0/war?J2EEApplication=null,PersistenceUnitModule=WEB-INF/classes/,
WebModule=pl.jaceklaskowski.statystyki/przyklad/1.0/war,j2eeType=PersistenceUnit,name=usosPU
to a gbean matching the pattern [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
Unable to resolve reference "NonJtaDataSourceWrapper"
in gbean pl.jaceklaskowski.statystyki/przyklad/1.0/war?J2EEApplication=null,PersistenceUnitModule=WEB-INF/classes/,
WebModule=pl.jaceklaskowski.statystyki/przyklad/1.0/war,j2eeType=PersistenceUnit,name=usosPU
to a gbean matching the pattern [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
due to: No matches for referencePatterns: [?name=jdbc/UsosDev#org.apache.geronimo.naming.ResourceSource]
at org.apache.geronimo.deployment.DeploymentContext.getConfigurationData(DeploymentContext.java:516)
at org.apache.geronimo.deployment.Deployer.install(Deployer.java:320)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:257)
at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:134)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.geronimo.gbean.runtime.ReflectionMethodInvoker.invoke(ReflectionMethodInvoker.java:34)
at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:130)
at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:850)
at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:237)
at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:116)
at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:61)
Teraz będę pamiętał! A może by tak zgłosić usprawnienie w komunikatach Geronimo i ostatecznie zapomnieć, aby zapamiętać, i nic nie pamiętać? ;-)

03 listopada 2008

@Resource UserTransaction w EJB 3.0 i poprawka dla OpenEJB

3 komentarzy
Pojawiła się kolejna wersja Apache OpenEJB 3.1 z obsługą EJB 3.1. Tak, tak, my tu o EJB 3.0, a na horyzoncie już się pojawił EJB 3.1 w OpenEJB 3.1 oraz GlassFish v3 Prelude. Na fali wydania postanowiłem obsłużyć jedno ze zgłoszeń dotyczących kontroli poprawności ziaren EJB w kontekście użycia UserTransaction - OPENEJB-847 Validation: @Resource UserTransaction injection mistakenly used on bean with Container-Managed Transactions. Zgłoszenie OPENEJB-847 dotyczyło sprawdzenia, czy deklaracja dostępu do zasobu UserTransaction ma miejsce jedynie w ziarnie EJB z samodzielnie zarządzanymi transakcjami. Zgodnie ze specyfikacją EJB 3.0, rozdział 16.12 UserTransaction Interface (strona 448) dostęp do UserTransaction jest możliwy wyłącznie dla ziaren sesyjnych (stanowych i bezstanowych) oraz komunikacyjnych (sterowanych komunikatami) z zarządzaniem transakcjami przez nie same (ang. BMTD - bean-managed transaction demarcation).

W najczęściej spotykanych przypadkach, transakcyjność ziaren EJB zarządzana jest przez kontener i w takim przypadku nie mamy prawa skorzystać z interfejsu UserTransaction wprost, czy to przez adnotację @Resource UserTransaction, czy deklarując go w deskryptorze wdrożenia (META-INF/ejb-jar.xml). Po prostu, kontrola zasięgu transakcji odbywa się deklaratywnie na poziomie metody lub całej klasy za pomocą adnotacji TransactionAttribute (domyślnie REQUIRED) z TransactionManagement ustawionym na CONTAINER (wartość domyślna).

Pod wpływem niekończących się dyskusji o bardziej przyjaznej IntelliJ IDEA do tworzenia aplikacji javowych (chociażby Fwd: JetBrains Giveaway Program Update), do napisania poprawki dla OpenEJB postanowiłem właśnie z niej skorzystać i przekonać się o tym na własnej skórze. Pamiętam czasy wersji 3 i później Ariadnę (nazwa kodowa dla wersji 4.0), i faktycznie coś w niej było. Później jeszcze kilkakrotnie przymierzałem się do niej, ale nie starczyło zacięcia. Tym razem zawziąłem się. Rozpocząłem od uruchomienia IntelliJ IDEA 8.0M1 i zaimportowałem projekt dzięki wsparciu dla projektów mavenowych. Po ostatniej lekturze artykułu "Poznaj JUnita" (Refleksje po "Poznaj JUnit 4" z Internet MAKER 5/08) tylko czekałem chwili, aby zmierzyć się z tematem tworzenia oprogramowania począwszy od testów jednostkowych. Trochę trwało, zanim faktycznie dałem się przekonać, że właśnie od testu powinienem zacząć i ruszyłem z miejsca, gdyż samo zestawienie całego "środowiska" do wykonania poprawki nie należało do najtrywialniejszych zadań (przede wszystkim utworzenie reprezentacji obiektowej konfiguracji ziarna EJB operając się na klasach JAXB). Szczęśliwie dzisiaj nie trwało to na tyle długo, abym się zniechęcił i po chwili miałem swoją wymarzoną, działającą poprawkę (!) Nadeszła upragniona pora, aby ją sprawdzić poza testem jednostkowym. Skorzystałem z pomocy NetBeans IDE 6.5 RC2 (który właśnie niedawno został wydany - do ostatniego wydania pozostało już kilka tygodni) i stworzyłem przykładowe ziarno bezstanowe z adnotacją @Resource.
 package nopackage;

import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.transaction.UserTransaction;

@Stateless
public class CheckUserTransactionRefsTestBean implements CheckUserTransactionRefsTestLocal {

@Resource
UserTransaction tx;

public String businessMethod() {
String result;
try {
result = "tx is null? " + (tx == null);
} catch (Exception ex) {
result = ex.getMessage();
}
return result;
}
}
Jakież było moje zdumienie, kiedy podczas jego uruchomienia na GlassFish V2 otrzymałem komunikat:

Ale jak to?! False?! Czyż @Resource UserTransaction nie jest dedykowane wyłącznie dla ziaren sesyjnych i MDB z samodzielnym zarządzaniem transakcji?! Taką miałem wiedzę, kiedy tworzyłem moją poprawkę dla OpenEJB i tego spodziewałem się w GlassFish (!) W tym momencie, przypomniałem sobie, jak podczas mojego ostatniego wystąpienia z tematem EJB 3.0 podczas NetBeans Day 2008 w Gdańsku, właśnie wykorzystanie transakcji zakończyło się porażką, gdyż...wykonałem przynajmniej jedną metodę na przekazanym egzemplarzu UserTransaction (cóż za zbieg okoliczności - najpierw NetBeans Day, później artykuł o JUnit, a teraz okazja do zastosowania wiedzy praktycznie w OpenEJB). Zmieniłem kod ziarna na następujący
 result = "tx is null? " + (tx == null) + " ze statusem " + tx.getStatus();
i...jest wyjątek!

Przyszła więcej pora na testy w środowisku OpenEJB. Najpierw sprawdzenie, jakie będzie działanie przykładowego ziarna w ramach Apache Geronimo 2.1.2, który jest serwerem aplikacyjnym Java EE 5 z kontenerem EJB opartym na OpenEJB. I tu bez niespodzianek - działa i to zgodnie z oczekiwaniami - UserTransaction jest puste. Odetchnąłem z ulgą. Teraz było już z górki - upragnione zatwierdzenie zmian (commit). Zainteresowanych szczegółami implementacji zapraszam do lektury Subversion Commits dla tego zgłoszenia. Nie ma tego wiele, więc pełne rozpoznanie tematu powinno zająć niespełna kwadrans.

p.s. Zauważyłem wiele podobieństw między NetBeans IDE 6.5 a IntelliJ IDEA 8.0M1, gdzie okienko tworzenia nowych elementów klasy, w NetBeans - Ctrl+Insert istnieje w IDEA jako...Alt+Insert oraz sout+TAB jako szablon dla System.out.println("")...również. Gdzieś już trafiłem na podobną refleksję (nie był to Radek Holewa?!). Już te dają mi do myślenia, a pewnie jest więcej.

02 listopada 2008

316: IBM WebSphere Integration Developer V6.1, Application Development oblany

1 komentarzy
Tym razem się nie powiodło i oblałem kolejny w swoim życiu egzamin. Tym razem zdecydowałem się na podejście do mojego pierwszego certyfikatu produktowego, po poprzednich egzaminach javowych z Suna. Nie miałem bladego pojęcia, jakich pytań mógłbym oczekiwać, więc tym bardziej nie jestem zdziwiony takim wynikiem (aczkolwiek brak 4 pytań do najniższej zdającej noty trochę wstrząsnęło moim ego).

Po kilkunastomiesięcznej pracy z IBM WebSphere Process Server (WPS) 6.0, później 6.1, aby w końcu zakotwiczyć przy ostatniej produkcyjnej wersji 6.1.2 z pomocą IBM WebSphere Integration Developer (WID) z identycznymi wersjami postanowiłem sprawdzić swoją znajomość tematyki SOA (ang. Service-Oriented Architecture) w wydaniu IBM podchodząc do egzaminu 316: IBM WebSphere Integration Developer V6.1, Application Development.

Kiedy zobaczyłem pierwsze pytania dotyczące Human Task API (sekcja, która poszła mi najgorzej), wiedziałem, że nie będzie lekko. Właśnie z tego obszaru wiedziałem najmniej i tutaj nie było zaskoczenia. Zastanawiają mnie jednak pozostałe obszary, z których czułem się znacznie, znacznie pewniej. Było jedno pytanie dotyczące widoczności modułów w konfiguracji dwóch klastrów w jednej celli wpsowej, które miałem wrażenie, że lekko wykracza poza zakres samego tworzenia oprogramowania. Nie zdałem, płakać nie będę i już zaplanowałem kolejne podejście, które zamierzam zakończyć z sukcesem, i to na znacznie lepszym poziomie niż mierne 3.

Kolejny raz potwierdziła się reguła, że egzaminy techniczne są niezwykle cennym źródłem wiedzy, poza różnego rodzaju książkami, artykułami, dokumentacjami, specyfikacjami, aby na doświadczeniu projektowym zakończyć. Podczas 2h z 57 pytaniami mogłem zapoznać się ze scenariuszami, których wcześniej nie miałem okazji spotkać, a które pozwoliły mi na jeszcze dokładniejsze rozpoznanie produktu i jego potencjalnego użycia (oby z korzyścią dla klientów ;-)). Tematyka integracji spod parasola SOA obejmuje bardzo szerokie spektrum specyfikacji i pewnie jeszcze długo przyjdzie mi zmagać się z tymi produktami, aby w pełni poznać ich możliwości, więc każde źródło jest mile widziane, nawet jeśli jest to...niezdany egzamin. Veni, vidi, ale nie vici.

01 listopada 2008

Refleksje po "Poznaj JUnit 4" z Internet MAKER 5/08

3 komentarzy
Kiedy przeglądałem półkę z czasopismami informatycznymi w kiosku na dworcu Warszawa Centralna (przed podróżą na NetBeans Day 2008 w Gdańsku) niewiele czasopism dotyczyło programowania w Javie - Software Developer's Journal (SDJ) oraz Internet MAKER. Paradoksalnie nie powinienem mieć żadnych trudności z wyborem i chciałbym móc napisać, że padło na SDJ, ale wybrałem (nie pierwszy już raz) Internet MAKERa 5/08 (wrzesień-październik). Jednym z artykułów, który przykuł moją uwagę był "Poznaj JUnit 4 - Wstęp do programowania sterowanego testami" autorstwa Tomasza Gębarowskiego. Zastanawiałem się cóż można napisać nowego o jednym z najbardziej rozpowszechnionym szkielecie aplikacyjny JUnit, czego jeszcze mógłbym nie wiedzieć. W zasadzie, z niewielką nadzieją na coś nowego, zabrałem się za lekturę i...nie żałuję. Chociażby samo poznanie adnotacji @Ignore oraz asercji assertThat (wspartej projektem Hamcrest) rekompensuje "dość obszerne wprowadzenie teoretyczne" (jak raczył zauważyć sam autor!). Poza tym, bardzo podobało mi się przedstawienie projektu JUnit po polsku bez korzystania z żargonu informatycznego (bo czyż Ci, którzy wiedzą jak posługiwać się żargonem informatycznym w stylu "framework" nie zakładają, że rozmówca w ogóle wie, czym jest framework?!). Wielokrotnie jestem pytany o wyjaśnienie działania technologii javowych i jeszcze nigdy nie spotkałem się z niezrozumieniem, kiedy zamiast framework używam szkielet aplikacyjny, czy ziarno zamiast bean. Jakkolwiek użycie "ziarno" zamiast "bean" wymaga porównywalnego nakładu pracy przy wyjaśnieniu, po co i dlaczego dany byt istnieje, to już w przypadku "szkielet aplikacyjny" (zamist "framework") można liczyć na pewne skojarzenia i intuicję rozmówcy. Właśnie dlatego uważam, że tłumaczenie technologii informatycznych korzystając z języka ojczystego adresata ostatecznie bardziej procentuje niż używanie zapożyczeń angielskich (licząc na ich znajomość u niego). Są takowe, których nie da się w prosty sposób zastąpić, jak "debugger", ale jak pokazuje przykład polskiego "logowanie" nawet one wciąż mogą prowadzić do nieporozumień. Jakich?! A proszę mi powiedzieć, o czym autor miał na myśli przy "logowaniu" - uwierzytelnianie (ang. log in/authenticate) czy zapis do dziennika zdarzeń (ang. log). A wracając do artykułu, to bardzo mile zaskoczył mnie język w jakim Tomasz wyjaśniał rolę JUnita w naszym warsztacie javowym. Pojawił się "szkielet aplikacyjny" i "programowanie sterowane testami", ale do czasu. Na 3. stronie artykułu pojawiły się wyjaśnienia w dedykowanych sekcjach (boksach?), gdzie zagościł "framework" i "plugin" przemieszany z "wtyczka", czy "kreator" zamiast "asystent" (czy "pomocnik"). Jakby pisała to już inna osoba (!)
Jako wadę artykułu możnaby nadmienić brak wyjaśnienia zalet programowania opartego o testy. Brak odpowiedzi, dlaczego warto zająć się nimi, przed faktycznym programowaniem samej aplikacji (już przy tym pytaniu widać, że rozróżniam testy od samej aplikacji, co nie twierdzę, że już samo w sobie jest niepoprawne). Mimo, że i testy, i sama aplikacja to wciąż programowanie, zdaje się, że przy tym pierwszym nie mamy tyle przyjemności. A ja pytam dlaczego? Zdaje się, że mimo, że podczas programowania myślimy o tym, co aplikacja ma robić, to po chwili i tak zaczynamy budować aplikację, jak nakazuje dany szkielet aplikacyjny i skupiamy się na niuansach niego samego, zamiast na czas realizować cele projektu (a nie swoje własne, jak poznanie nowego i w danej chwili popularnego szkieletu). Sądzę, że owe skupianie się na zawiłościach środowiska, które samemu sobie nałożyliśmy (również akceptacja zastałego środowiska rozważam w kategoriach świadomego własnego wyboru) przesłania nam faktyczny celu, jakim jest stworzenie działającej aplikacji w terminie. Jest to bodaj najczęstszy powód, dla kolejnego przesunięcia terminu oddania etapu projektu, bo poznanie danego szkieletu aplikacyjnego zabiera więcej czasu niż planowaliśmy (mimo wcześniejszych zapowiedzi, że jest tak prosty, jak tylko było to możliwe) lub posiada błąd, a niestety już nie mamy możliwości wycofać się z tej decyzji projektowej. Brzmi znajomo? Niejednokrotnie przyszło mi uczestniczyć w projekcie, w którym wybierałem co bardziej popularne rozwiązanie (szkielet aplikacyjny, serwer aplikacyjny, język programowania), zamiast sprawdzone czy właściwe. Consuetude altera natura est, co? Niejednokrotnie wybieram w projekcie rozwiązanie efektowniejsze, a nie efektywne. Drobna różnica w słowach, a jakie skutki w projekcie (!) Dlatego też, brakowało mi w artykule jakiegoś scenariusza, w którym byłaby próba przedstawienia wartości płynących z podejścia "najpierw testy" i w ten sposób upewnienie się, że bez względu na inne elementy wspomagające aplikację, np. interfejs użytkownika (aplikacja desktopowa vs webowa z ajaxem czy bez), jej podwaliny biznesowe (trzon aplikacji) ma gwarancję poprawności, tj. zgodności z założeniami. Kiedy mamy poprawnie skonstruowany trzon aplikacji możemy śmiało podejść do jej rozbudowywania i opakowania wymyślnym szkieletem aplikacyjnym, który *uprości* tworzenie wyrafinowanego rodzaju aplikacji. Podkreślam słowo uprości. Wiemy, co i jak mamy działające, ale efekt końcowy, który powali klienta na kolana warto już oprzeć o gotowe rozwiązanie, które spełnia rolę nakładki na już działające "bebechy". Właśnie owa gwarancja poprawności założeń daje nam pewność, że ostatecznie aplikacja w ogóle zaistnieje. Aby dojść do tego etapu, skorzystanie z JUnita (czy innego alternatywnego rozwiązania) wydaje się być kluczem do sukcesu. Skoncentrowanie się na pojedyńczych, wyizolowanych elementach naszej aplikacji sprawia, że "odpukujemy każdą z cegiełek i sprawdzamy, że żadna nie ma wady produkcyjnej". Samemu nie mam w zwyczaju rozrysowywać aplikacji w postaci diagramów UMLowych, na których widać byłoby, co w ogóle robimy, ale dostrzegam ich zaletę (chociażby dla nowoprzybyłych w projekcie). Z zastosowaniem JUnita jest podobnie. Widzimy ich zaletę, ale niewielu z nas (mnie włączając) ma wystarczające zacięcie, aby je wdrożyć. Dlaczego?! Czyżby moda na kolejny szkielet aplikacyjny sprawiała, że zapominamy o faktycznie wartościowej inżynierii programowania, gdzie posiadanie testów jednostkowych w projekcie, znajomość algorytmów ma znaczenie? Nie poświęcam wiele czasu na analizę algorytmów, nie tworzę wielu testów jednostkowych, nie stworzyłem żadnego szkieletu aplikacyjnego, ale mam nieodparte wrażenie, że dobry szkielet aplikacyjny nie obroni się bez testów jednostkowych, odpowiednich algorytmów i dokumentacji, np. w postaci diagramów UMLowych. Chciałbym móc spełnić choć jeden z tych postulatów. Poza kilkoma uwagami odnośnie zalecenia umieszczania testów jednostkowych w dedykowanym pakiecie test, który tym samym pozbawiłby nas możliwości testowania metod package protected, oraz kilku błędach w samej klasie testowej artykuł oceniam wysoko. Na zakończenie (chociaż wydaje się, że dopiero od tego momentu rozpoczyna się) artykułu pojawia się przedstawienie integracji JUnit w środowisku Eclipse IDE. Jakby uwypukleniem niesystematycznego użycia framework vs szkielet czy test-driven development vs programowanie sterowanym testami jest rozdział "Zakończenie". Autor nadmienił, że "tematyka (...) jest niezwykle szeroka i trudno jest przedstawić jej wszystkie założenia w jednym krótkim artykule". Oczekuję kolejnych.

p.s. W trakcie czytania nasunął mi się skrót odpowiadający programowaniu sterowanego testami, aby po prostu nazywać je "testosteronem" (TESTami STEROwaNe programowanie) ;-)

Nie cichną echa zeszłotygodniowej konferencji NetBeans Day 2008 w Poznaniu i Gdańsku. Na stronie głównej java.net Communities pojawiła się zajawka o wpisie na blogu Toniego - NetBeans DreamTeam visit to Poland on the java.net Communities tab + Polish JUGs helped organize these events. Najwyraźniej jest to pierwsza tak nagłośniona międzynarodowo, konferencja javowa w Polsce. Jam tam byłem, miodu i wina nie piłem, ale prezentacje odstawiłem ;-) Więcej w Wrażenia po NetBeans Day 2008 w Gdańsku. Gratulacje dla poznańskiego i gdańskiego JUGa!