12 grudnia 2008

Wrażenia po SCDJWS 5 (311-230)

2 komentarzy
I mam za sobą. Pozytywnie? Nie wiem. Na koniec egzaminu pojawił się jedynie komunikat:

THANK YOU ...blebleble...your score will be sent to you in 6-8 weeks after the beta analysis is complete.

Znaczy się, że w Sylwestra nie będę opijał sukcesu. Pisałem (patrz: Sun Certified Developer for Java Web Services (SCDJWS) bezpłatnie do 10 grudnia!), że "nie mam co liczyć na PASS, ale przynajmniej rozeznam się w materiale, w moich brakach i jeszcze wyrażę swój głos", ale już po połowie wiedziałem, że ten konkretny egzamin nie należy do bardzo wyrafinowanych i z każdym pytaniem byłem coraz bardziej przekonany, że go zdam (podkreślam, że moja wiedza Web Services nie należy do najbardziej oszałamiających i podszedłem do egzaminu z czystej ciekawości, czego można się spodziewać). Niestety, po 150 pytaniach w ciągu 240 minut pozostaje mi jeszcze czekać 6-8 weeks, aby poznać wynik.

Komentarzy zostawiłem sporo, bo udało mi się namierzyć pytania, które były błędne (proste literówki, które powodowały, że program nie mógłby się skompilować, a więc i odpowiedź była niepoprawna) i w ten sposób wyraziłem swoją opinię. Dług spłacony. Pojawiło się kilka pytań o "servlet-based vs EJB3-based Web Services", więc mam nadzieję, że chociaż pytaniami o EJB3 podniosłem trochę wynik. Nie mogłem uwierzyć, kiedy pod koniec, około 130. pytania, pojawiły się pytania zahaczające o....Net! Bodajże 10 pytań dotyczyło WCF, z czego trzech całkowicie nie zrozumiałem. Był moment, że koło mnie zdawały jeszcze 2 osoby z tematów microsoftowych, więc może testy ze sobą interferowały. 3 pytania dot. WCF to były "strzały". Ostatecznie na 30 minut przed końcem miałem 15 pytań do przejrzenia, a wiele odpowiadałem na zasadzie podobieństw pytań tak, że jedno pytanie było zarazem odpowiedzią na inne. I tak przeszło mi zabawiać się z akronimami i pojęciami webservice'owymi. A naliczyłem ich sporo. Zresztą sami zobaczcie (w kolejności ich występowania):

JAX-WS, JAXB, WSIT, SAAJ, WSDL, REST, SOAP, XML, JAXP, SAX, DOM, JAXR, SEI, apt, wsimport, wsgen, WS-I Basic Profile, WSDL-to-Java, Java-to-WSDL, EJB-based vs servlet-based endpoints, I-Stack, EJB3, doc-style, proc-style/rpc-style, rpc-lit, doc-lit, asynchronous WS, interaction/processing layer, XML Digital signatures, enveloping vs enveloped vs detached signatures, SSL, HTTP, mutual authentication, XML encryption, XACML, XKMS, X.509, SAML,Kerberos, WS-* (Policy, SecureConversation, Message, Security, ReliableMessaging, SecurityPolicy, Trust), XSD, MIME, SOA, JSON, RESTful WS vs SOAP WS, JAXB Validations, Fast InfoSet, StAX, WCF, .Net, MTOM, UDDI, i tak dalej.

Podsumowując, dużo było o JAXR i bezpieczeństwie (powiedziałbym, że razem naliczyłbym do 1/3 pytań). Trochę o REST, WS-I Basic Profile 1.1 (raz pojawiła się wzmianka o 1.0a i sądzę, że była to pomyłka z poprzedniego egzaminu) i te nieszczęsne WCF. Pojawiły się 2-3 pytania o SOA. Generalnie niezbyt techniczny egzamin, a raczej taki architektoniczny.

Podchodził ktoś jeszcze? Wrażenia?

05 grudnia 2008

Sun Certified Developer for Java Web Services (SCDJWS) bezpłatnie do 10 grudnia!

10 komentarzy
Natrafiłem na dWorld.pl na ciekawą informację - SCDJWS za darmo. Jeszcze zostały 3 dni (poza weekendem), aby skorzystać z możliwości bezpłatnego podejścia do egzaminu Sun Certified Developer for Java Web Services (SCDJWS) i mimo, że zarobionym po pachy, potraktowałem egzamin czysto rekreacyjnie (w końcu, ile można siedzieć w tych kodach korygujących błędy z Tornado w tle?!).

Przeglądając wymagania dotyczące egzaminu, nie mam wątpliwości, że nie mam co liczyć na PASS, ale przynajmniej rozeznam się w materiale, w moich brakach i jeszcze wyrażę swój głos. W końcu poza 4h, nic nie tracę, a z pewnością dużo mogę zyskać. Potraktowanie tematu Web Services w postaci egzaminu stanowi dla mnie ciekawą formę szkolenia, więc zysk oczywisty. A może jednak mam wystarczająco wiedzy, aby to obronić? Jak nie podejdę, nie będę wiedział. A jak z Tobą? Podchodzisz?

01 grudnia 2008

37. spotkanie Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG)

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 37. spotkanie, które odbędzie się 02.12.2008 o godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: Java Native Interface, czyli dlaczego Java jest zależna od platformy
Prowadzący: Damian Szczepanik

Podczas prezentacji należy oczekiwać wiadomości wprowadzających do Java Native Interface (JNI), jak można go wykorzystać, gdzie i w jakich przypadkach jest niezbędny oraz kiedy należy się trzymać od niego z daleka. Z upływającym czasem pojawi się więcej praktyki. Zostanie zaprezentowane, co należy pobrać z Sieci i jak skonfigurować, aby móc korzystać z możliwości JNI w swoim IDE. Dla tych, których tematyka zainteresuje bardziej, garść porad. Dla tych, których nie zainteresuje (czytaj nie wykażą podczas spotkania chęci współpracy), będzie "wyjściówka" - nie wyjdą ze spotkania, dopóki nie odpowiedzą na pytania dotyczące JNI :) Tym samym uczestnicy zostali ostrzeżeni.

Lektura (nie)obowiazkowa: Java Native Interface w Wikipedii.

Historia Damiana z Javą zmieniała się jak w kalejdoskopie, co pozwoliło mu poznać jej wszystkie trzy oblicza. Zaczynalem, jak wszyscy, od SE, ale dość szybko dane mu było poznać tajniki pisania oprogramowania na platformie ME. W czasie studiów prowadził wykopaliska na terenie EE i pewnie tak zostałoby do dziś, gdyby nie firma Samsung, gdzie od prawie trzech lat tworzy oprogramowanie do telewizorow cyfrowych (!) Damian jest programistą z zawodu, integratorem kodu z doświadczenia, a (jak nikt nie patrzy) zarzadza systemem kontroli wersji. Podsumowując, ciekawa osóbka, której niewysłuchać to zgrzeszyć.

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

Wstęp wolny!

Zapraszam w imieniu grupy Warszawa JUG!

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.....

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!

27 października 2008

Wrażenia po NetBeans Day 2008 w Gdańsku

8 komentarzy
Nie byłoby całego NetBeans Day 2008, gdyby nie wkład, jaki w zorganizowanie jej, włożyły załogi poznańskiego i gdańskiego JUGa. Szkoda byłoby zapomnieć choćby o jednej osobie z zespołu organizacyjnego, ale pozwolę sobie na wymienienie wyłącznie trzech, które są głównymi sprawcami całego zdarzenia - Jakub P. Nowak, Adam Dudczak (Poznań JUG) oraz Jakub Neumann (Trójmiasto JUG). Osób organizujących NetBeans Day 2008 w Poznaniu (25.10.2008) i Gdańsku (26.10.2008) było więcej, ale te szczególnie utkwiły mi w pamięci (delikatnie pomijając uczestników naszego sobotniego spotkania integracyjnego). Bardzo dziękuję organizatorom, że mogłem uczestniczyć w niezwykle sprawnie przygotowanej oraz obfitującej w sławy światka netbeansowego konferencji NetBeans Day 2008 w Gdańsku.

A wszystko zaczęło się tak niewinnie. Kiedyś tam napisał do mnie Jakub P. Nowak i spytał, czy dałoby się zebrać grupę prelegentów na konferencję NetBeans Day do Poznania (zdaje mi się, że wtedy jeszcze tylko Poznań był brany pod uwagę). Kilka postów na grupy NetBeans Dream Team, NetBeans CAT 6.5 i już nie pamiętam, gdzie jeszcze, i z lokalnej konferencji zrobiła się całkiem międzynarodowa, z udziałem jednego guru netbeansowego - Geertjan Wielenga, czempiona javowego - Adama Biena oraz członka zespołu NetBeans Dream Team - Toniego Epple. Dodając do tego, inne sławy w osobach Karola Harezlaka oraz Łukasza Lenarta i mamy całkiem ciekawą śmietankę naszego zakątka javowego.

Wspólnie z Łukaszem pojawiliśmy się w Gdańsku około 19-tej w sobotę, 25-tego i od razu skierowaliśmy się do "Miasta Aniołów". Jeśli ktokolwiek pomyślał o Los Angeles, to raczej o tej jego "ciemnej" części. Panowie w czarnych gajerach od razu dali odczuć, że nie jesteśmy w byle jakiej knajpce i zgodnie z zapowiedziami trójmiastowiczów od 21-szej miało się dopiero zacząć. Jako dodatkowe wrażenie, nakazano nas opieczętować niewidzialnym tuszem (podobno widocznym pod ultrafioletem). Kiedy poproszono mnie o zdjęcie bluzy z kapturem nie miałem złudzeń, że miejsce jakieś szemrane. Po dwóch turach pizzy, piwa zaczęła się dyskoteka, a my wyszliśmy szukać wrażeń w innym miejscu. Jeszcze przy wyjściu karteczka na wejściu "Wyjść na chwileczkę nie akceptuje się" i aż dziw bierze, że w takich oto miejscach integrują się trójmiastowicze ;-) Przeszliśmy się starówką gdańską i zlądowaliśmy w niewielkiej "pizzernia-like pubie". Tam dogadaliśmy do około 1AM i po kebabie przy rynku wróciliśmy do hotelu Dwór Prawdzica. Tam bilard przez godzinę/półtorej i powrót do pokoju. A tam z kolei pełne zaskoczenie - pokój w ogóle nie był sprzątany po ostatnim lokatorze (śmiem twierdzić, że lokatorce - pełno włosów w łazience i kilka innych "śladów")! Jeszcze chwila przed komputerem i o 5AM wylądowałem w łóżku (wierząc, jak się później okazało mylnie, że 5AM to faktycznie 4AM, bo w końcu była zmiana czasu). Ranek równie ciekawy - śniadanie, a po nim 1-godzinna partyjka bilarda z Łukaszem (który tym razem dał mi wygrać 5:4!).

Rozpoczęła się konferencja. Przede mną wystąpił Adam Bien, który zahaczył w wielu miejscach o moją tematykę EJB3, więc musiałem uaktualniać swoje wystąpienie na bieżąco. Początkowo planowałem przedstawienie zaawansowanych elementów EJB3 jak kontekst rozszerzony, stanowe ziarna sesyjne, LEFT JOIN w JPA i transakcyjne ziarna MDB, ale skończyło się na przejściu przez średniozaawansowane elementy jak interceptory, omówienie ogólnego działania EJB3 i atrybucie beanName w @EJB. Prezentacja dostępna jako JacekLaskowski-NetBeansDay2008-ZaawansowaneEJB3zNetBeans65-26.10.2008.pdf. Komentarze mile widziane, bo trudno utrzymać ciągłe zainteresowanie EJB3 po tylu dniach z nim spędzonych, a wielu domaga się kursu wprowadzającego (a ja już myślę o EJB 3.1 i jestem w rozterce!).

Powrót do domu IC o 17:15 z Oliwy i około 23-ciej byłem spowrotem u siebie. Nie ukrywam, że balowanie do 2-giej, a później prelekcja nie pasują do siebie. Do poniedziałku byłem całkowicie bez pary.

Zainteresowanych zdjęciami ze spotkania Trójmiasto JUG, Warszawa JUG i reszta znajdą kilka na stronie Krzysztofa Zubika.

Inni uczestnicy również opublikowali swoje spojrzenie na konferencję - Adam Bien w Danzig Band and City, Netbeans 6.5 rc1 on Vista, Xtreme Makeover, Restful and Beeing Doomed to Present the Basics, Geertjan Wielenga w Poznan & Gdansk: NetBeans Day, Poland oraz Łukasz Stachowiak w Po NetBeans day Poznań.

p.s. Podczas wyjazdu miałem okazję odwiedzić dworcowy kiosk w poszukiwaniu ciekawej publikacji informatycznej o javie i z przykrością muszę przyznać, że nic dla programistów javowych nie ma! Stąd też wcale nie dziwi mnie recenzja Piotra Maja dotycząca ostatniego SDJ - Software Developer's Journal z 11.2008. Dla mnie to kompletna porażka, aby tak ciekawe technologie javowe traktować po macoszemu. Skończyło się kolejny raz na kupnie INTERNET Maker wrzesień/październik 2008, który przykuł moją uwagę artykułami "Aplikacja na Androida", "Poznaj JUnit 4", "HTML i CSS - układy kolumnowe w CSS, część 2" i w końcu "Kurs UML - część 5 - diagramy czynności/aktywności". Nie ma w nich nic nadzwyczajnego, ale są one dużo lepsze od tych, które mógłbym znaleźć w SDJ. Szkoda.

26 października 2008

36. spotkanie Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG)

0 komentarzy
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na 36. spotkanie, które odbędzie się 28.10.2008 o godzinie 18:00 w sali 5440 Wydziału MIMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: JBoss Enterprise Service Bus - Connecting Systems
Prowadzący: Jarosław Kijanowski

JBoss Enterprise Service Bus (JBoss ESB) jest otwartym oprogramowaniem przeznaczonym do integracji rozproszonych systemów informatycznych udostępniając mechanizm szyny usługowej. W trakcie prezentacji poznamy jego najważniejsze cechy i dowiemy się jak szybko (i przyjemnie?) rozpocząć ratowanie świata, w którym dominuje oprogramowanie niezdolne do porozumienia się między sobą bezpośrednio bez mediatora w postaci ESB. Uczestnicy będą mogli zapoznać się praktycznie z produktem w serii specjalnie przygotowanych przykładów wyjaśniających działanie JBoss ESB oraz jego integrację z JBoss Drools i JBoss jBPM. Na samym początku będzie niespodzianka, więc spóźnialscy stracą (i z tego chociażby powodu warto rozważyć wyjście na spotkanie 15 minut wcześniej). Nie będzie tasiemców-wyjątków czy kilometrowych XMLi. Od uczestników nie oczekuję żadnej znajomości Javy, tym bardziej JEE - o wszystkim co będzie potrzebne, dowiemy się w trakcie spotkanie.

Jarek Kijanowski rozpoczął przygodę ze światem bitów i bajtów w wieku 7 lat (kiedy to inni zachwyceni dzieciństwem preferowali spotkania z istotami żywymi). Do dziś posiada swoje pierwsze Commodore64, aczkolwiek z żalem przyznaje, że już nie pamięta w którą stronę i o ile stopni, należy przekręcić śrubkę w magnetofonie taśmowym do poprawnego wczytania gry (np. Boulder Dash). Dorastał i pisał kalkulatory czterodziałaniowe w Basicu, Pascalu, C, Perlu, Fortranie, PHP, JavaScriptcie i Assemblerze. W Javie już nie próbował. Od dwóch lat jako wolny strzelec pomaga JBossowi, załodze spod czerwonego kapelusza Inc., aby tym samym uszczęśliwiać klientów, pracując z fantastyczną ekipą nad wczesnym wykrywaniem wyjątków (taki wyjątek-hunter).

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

Wstęp wolny!

Zapraszam w imieniu grupy Warszawa JUG!

22 października 2008

NetBeans IDE 6.5 RC, NetBeans Decathlon oraz przyszłość Spring-DM i SpringSource dm Server

2 komentarzy
Ostatnimi dniami, a w zasadzie tygodniami, zaangażowany byłem w projekt-pilota, w którym dwa zewnętrzne systemy z własnymi mechanizmami generowania identyfikatorów zleceń synchronizowane były przez IBM WebSphere Process Server za pomocą usługi wiązania (ang. relationship service). Do tej pory taką integrację wyobrażałem sobie przez zastosowanie odpowiednich adapterów, a tu proszę, wystarczyło oprzeć się o usługi sieciowe (web services), niewielką dawkę programowania w Javie i...hula! Bajka. Ale nie o tym dziś ja (chociaż nie mogłem się opanować, aby nie skrobnąć co nieco, taki jestem zachwycony rezultatami).

Dzisiejszy dzień również obfitował w nowości, których kompletnie się nie spodziewałem. Zacząłem niewinnie od pobrania ostatniej wersji rozwojowej NetBeans IDE 6.5, którego wydanie RC właśnie się pojawiło. Jako (obecnie mniej aktywny) uczestnik programu NetBeans Community Acceptance Test (NetCAT) 6.5 przywykłem do pobierania wersji rozwojowych, ale dla mniej żądnych wrażeń proponuje się skorzystanie z wersji NetBeans IDE 6.5 Release Candidate, a w nim:

The focus of NetBeans IDE 6.5 is simplified and rapid development of web, enterprise, desktop, and mobile applications with PHP, JavaScript, Java, C/C++ , Ruby, and Groovy. New features for 6.5 include a robust IDE for PHP, JavaScript debugging for Firefox and IE, and support for Groovy and Grails. This release also offers a number of enhancements for Java, Ruby and Rails, and C/C++ development. Java feature highlights include: built-in support for Hibernate, Eclipse project import, and compile on save. The Release Candidate improves on the support offered in NetBeans 6.5 Beta.

The final NetBeans IDE 6.5 release is planned for November 2008.


Poza typowymi cechami NetBeans IDE, do których przywykłem i stosuję, moją uwagę przykuło wsparcie dla Groovy i Grails, o którym słyszałem, że jest na przywoitym poziomie (piszę bez entuzjazmu, gdyż samemu nie miałem jeszcze możliwości popróbowania się z tematem). Właśnie nieprzeciętne wsparcie dla Java EE oraz inne elementy, jak wsparcie dla Grails, powodują, że nie jest to narzędzie, koło którego można przejść obojętnie. A jeśli do tego dodać, że NetBeans IDE właśnie skończyło 10 lat i rozpoczęto ogólnoświatową imprezę NetBeans 10th Birthday (aka NetBeans Decathlon), to nie tylko można skończyć projekt krócej (korzystając z funkcjonalności NetBeans), ale również i dobrze na tym "zarobić". Więcej informacji na wspomnianej stronie NetBeans Decathlon. Cała zabawa to jedynie zebranie 50 punktów przez różnego rodzaju aktywność wokół NetBeans i "a limited edition NetBeans 10th Anniversary Shirt" jest Twoja. Moje pierwsze 15 punktów to wzmianka o mojej kolejnej, dzisiejszej niespodziance - wsparciu dla GlassFish v3 "Prelude", w którym można skorzystać z...EJB 3.1! Sądziłem, że wsparcie dla EJB 3.1 to domena Apache OpenEJB, którego wydanie 3.1 jest właśnie głosowane - [VOTE] OpenEJB 3.1 take 1, co, za sprawą NetBeans IDE, okazało się być nieprawdą. Otwieram nowiuteńką rozwojową wersję NetBeans IDE 6.5 i po chwili pojawiła się informacja o nowych aktualizacjach wtyczek.


Zaintrygowała mnie zmiana wersji GlassFish v3 "Prelude" na 1.0. To pierwsza wersja stabilna, więc zaraz zabrałem się za wyszukiwanie o tym informacji. Niedługo trwało, kiedy trafiłem na NetBeans 6.5 Beta is out - GlassFish 'Prelude' included z dnia moich urodzin (!), gdzie w komentarzach znalazłem "I got to know modules for ejb 3.1 and JSF (mojarra) available for V3. For Servlet 3.0, does it have any similar EDR modules available?". "Co?! EJB 3.1 już dostępny w GlassFish v3?!" - pomyślałem. Kolejne wyszukiwanie i trafiłem na EJB 3.1 in GlassFish V3 TP2. Nie pozostaje przyjrzeć się specyfikacji EJB 3.1, która nie tak dawno pojawiła się w wersji EJB 3.1 public review draft. Ech, nie pomyślałem o tym wcześniej, ale nadchodzące moje niedzielne wystąpienie podczas NetBeans Day 2008 w Gdańsku mogło być właśnie o EJB 3.1 i NetBeans. Następnym razem. Sądzę, że moje "Zaawansowane EJB3 z NetBeans 6.5" wciąż może być interesujące i warte rozważenia ;-)

I tak dzień mijał, kiedy trafiłem na ciekawą dyskusję o przyszłości Spring Dynamic Modules (Spring-DM) w kontekście pojawienia się SpringSource dm Server. Czytając dyskusję Spring DM Roadmap, należałoby raczej zająć się rozpoznawaniem produktu SpringSource dm Server niż Spring-DM, który:

"Firstly on a 1.2 release that will fill in the long-promised configuration administration support, making the core programming model feature complete."

oraz

"The 2.0 branch is where we are implementing the OSGi Blueprint Service (RFC 124) that will be part of OSGi R4.2. The Spring DM project will be the RI for this forthcoming specification (which is essentially a standardization of Spring DM + the core Spring beans support)."

i dalej

"So in summary, the future of Spring DM is to move towards becoming an RI for the standardization of the existing DM model, as the OSGi Blueprint Service. The Spring DM project provides an open source (and soon standards-based) programming model for use on any OSGi Service Platform."

Wydaje się, że praca przy Spring-DM wre, ale daje się odczuć kierowanie wysiłków ku SpringSource dm Server, zamiast rozbudowywać Spring-DM, który de facto jest jego składową.

"We will maintain the existing web support in Spring DM, but are not planning to take this any further in terms of significant new features etc. We're running into a law of diminishing returns there in terms of how good an experience we can deliver on a vanilla OSGi Service Platform. This was one of the motivations for creating the dm Server in the first place - to provide the best environment we could for OSGi-based enterprise applications and there are many issues that we can resolve much more easily in the dm Server world. [The SpringSource dm Server is of course also freely available in open source]."

Nie pozostaje nic innego, jak przyjrzeć się SpringSource dm Server i OSGi 4.2 - OSGi RFC 124 ("OSGi Blueprint") przygaszając działalność wokół Spring-DM do niezbędnego minimum.

16 października 2008

Java Developers' Day 2008 za nami, NetBeans Day 2008 za tydzień

2 komentarzy
Java Developers' DayWłaśnie wróciłem z bardzo interesującej konferencji Java Developers' Day 2008 w Krakowie, w której miałem możliwość zaprezentowania dwóch tematów - 5-minutowe "Dlaczego warto budować swoje profesjonalne życie publicznie" w ramach Java Underground, której gospodarzem był Grzegorz Duda oraz 50-minutowe "Wprowadzenie do OSGi i Spring Dynamic Modules (Spring-DM)". Już dawno nie czułem takiego wspaniałego klimatu konferencyjnego, jak podczas dzisiejszego JDD. Impreza wspaniale przygotowana i pomijając wystąpienia sponsorskie, które mówiło się, że były do bani, reszta była najwyższych lotów. Pewnie można było tak dobrać prelegentów, aby poziom mógł dorównać tegorocznej Javarsovii 2008, ale organizatorzy w osobie Andrzeja i Ani obiecywali więcej i lepiej wkrótce ;-) Podobno już szykuje się jakaś konferencja techniczna w przyszłym roku, w okolicach maja 2009. Znaczy się należy rezerwować maj na wyjazd do Krakowa. A przecież Polish JUG też nie zasypia gruszek w popiele i organizuje własną konferencję. Zapowiada się ciekawy konferencja fajt (skoro o fajt, to nie mógłbym nie napisać o powalającym na kolana skeczu w wykonaniu kabaretu Limo - Dres i Anioł).

Jest kilka rzeczy, które podpatrzyłem na JDD'08 i chciałbym wykorzystać podczas organizacji warszawskiej Javarsovii 2009. Bodaj najważniejsze, to pamiętać, że sama rola organizatora nie powinna być dzielona z rolą prelegent czy hostessa. Tutaj widziałbym pomoc innych osób niż sami organizatorzy. Ich rolę pozostawiłbym jako ewangeliści spotkań Warszawa JUG czy agitacja do większej aktywności publicznej, innymi słowy dyskutowanie z uczestnikami i rozpoznawanie ich preferencji konferencyjnych, zapraszanie do wystąpień publicznych, itp. Obowiązkowe wydają się być identyfikatory zawieszane na szyi, bo chociażby dzięki temu wielu mogło rozpoznać Grzegorza Dudę, który jak to się wyrażono "inaczej wygląda w Sieci, a inaczej na żywo" (Grzegorz, może należałoby już uaktualnić zdjęcie na blogu?!). Przestronne sale i dwa ekrany pozwalały wygodnie rozsiąść się i wysłuchać wystąpienia. Warto było wziąć udział w JDD 2008. Kto nie był, niech żałuje! Dla mnie była to bardzo wartościowa kulturalnie impreza. Już nie mogę doczekać się wyników ankiet z ocenami prezentacji. Podobno będą dostępne publicznie. Brrr...

Moja prezentacja "Wprowadzenie do OSGi i Spring Dynamic Modules (Spring-DM)" dostępna jest jako JacekLaskowski-JDD2008-OSGi-SpringDM-16.10.2008.pdf.

Zatem JDD'08 przechodzi do historii, a przed nami kolejna konferencja - NetBeans Day 2008 w Poznaniu i Gdańsku w weekend 25-26.10.2008. Występuję w Gdańsku z tematem "Tworzenie zaawansowanej logiki biznesowej w aplikacjach Java EE w środowisku NB 6.5", który lekko przydługi na potrzeby przyciągnięcia przychylnego oka sponsorów, a dla nas, technicznych, powinien być raczej "Zaawansowane EJB3 a NetBeans 6.5", gdzie zaprezentuję kilka mniej powszechnych acz bardzo wyrafinowanych funkcjonalności udostępnianych przez EJB3, m.in. rozszerzony kontekst trwały (JPA extended context), ziarna stanowe, interceptory i...jeszcze się zastanawiam, co podciągnąć pod kategorię "zaawansowane". Kolejne dni zapewne spędzę ponownie przeglądając specyfikację EJB3 w poszukiwaniu ciekawych kąsków. Organizatorzy gwarantują dobrą zabawę, na której nie może Cię zabraknąć. Zapraszam w imieniu organizatorów!

13 października 2008

Spring-DM 1.2.0 M1 z Jetty na Equinox z pomocą pax-runner

0 komentarzy
Wczoraj, w pax-runner w akcji - uruchamianie aplikacji webowych jako pakunków OSGi, opisałem uruchamianie aplikacji webowych korzystając z dobrodziejstw pax-runner. Przykładowa aplikacja spring-osgi-webapp uruchomiona została w ramach Jetty, który był zanurzony w Equinoksie za pomocą pakunku org.ops4j.pax.web.service. Prosta aplikacja, więc i proste środowisko wystarczyło (przez "proste" rozumiem wyłącznie łatwość zestawienia gotowego do działania środowiska, a nie funkcjonalność niskiej jakości). Kiedy jednak chcielibyśmy skorzystać z dobrodziejstw oferowanych przez Spring Framework na scenę wchodzi Spring Dynamic Modules for OSGi(tm) Service Platforms (Spring-DM).

Rolą Spring-DM jest monitorowanie środowiska uruchomieniowego OSGi i reagowanie na instalację pakunków korzystających z funkcjonalności Spring Framework, tak aby bardziej restrykcyjne środowisko javowe, jakim jest OSGi, nie powodowało zbyt wielu komplikacji podczas tworzenia i uruchamiania aplikacji. Skoncentrowałem swoje wysiłki na aplikacjach webowych, ale nie ma to w zasadzie wielkiego znaczenia, czy są to aplikacje webowe, czy niewebowe. Chodzi jedynie o połączenie cech Spring Framework i OSGi (potencjalnie z Java EE). Marzenie ściętej głowy? Już przekonałem się, że nie (bagatela, na chwilę przed moim wystąpieniem Wprowadzenie do OSGi i Spring Dynamic Modules (Spring-DM) podczas tegorocznej konferencji Java Developers Day 2008 w Krakowie za...3 dni!). Przekonaj się samemu, że idzie gładko. Zapraszam również na konferencję, abyśmy mogli omówić szczegóły.

Rozpoczynamy od zebrania wymaganych pakunków OSGi do uruchomienia Spring-DM (zakładam, że sam pax-runner jest już gotowy. Nie?! Zajrzyj do wspomnianego pax-runner w akcji - uruchamianie aplikacji webowych jako pakunków OSGi). Posiłkuję się plikami dystrybuowanymi w ramach Spring-DM 1.2.0 M1 oraz dostępnych w repozytoriach Spring-DM OSGified Artifacts Repository i SpringSource Enterprise Bundle Repository. Cały zestaw pakunków to następująca lista:
  • com.springsource.javax.el-2.1.0.jar
  • com.springsource.javax.servlet.jsp-2.1.0.jar
  • com.springsource.javax.servlet.jsp.jstl-1.1.2.jar
  • com.springsource.junit-3.8.2.jar
  • com.springsource.net.sf.cglib-2.1.3.jar
  • com.springsource.org.aopalliance-1.0.0.jar
  • com.springsource.org.apache.taglibs.standard-1.1.2.jar
  • com.springsource.org.objectweb.asm-2.2.3.jar
  • jetty-6.1.9.jar
  • jetty-util-6.1.9.jar
  • jetty.start.osgi-1.0.0.jar
  • jetty.web.extender.fragment.osgi-1.0.0.jar
  • servlet-api.osgi-2.5-SNAPSHOT.jar
  • spring-aop-2.5.5.jar
  • spring-beans-2.5.5.jar
  • spring-context-2.5.5.jar
  • spring-context-support-2.5.5.jar
  • spring-core-2.5.5.jar
  • spring-osgi-core-1.2.0-m1.jar
  • spring-osgi-extender-1.2.0-m1.jar
  • spring-osgi-io-1.2.0-m1.jar
  • spring-osgi-web-1.2.0-m1.jar
  • spring-osgi-web-extender-1.2.0-m1.jar
  • spring-web-2.5.5.jar
  • spring-webmvc-2.5.5.jar
Umieszczam pakunki w wybranym katalogu, powiedzmy springdm-jetty, i uruchamiam pax-runner.
 C:\apps\equinox-springdm\pax-runner-profiles\springdm-jetty
> pax-run "--platform=equinox" "--log=DEBUG" "--profiles=log" springdm-jetty
Po chwili, kiedy przewinie się mnóstwo komunikatów (dzięki --log=DEBUG, który jest dla celów poznawczych, jak działa Spring-DM pod spodem) można podejść do wdrożenia aplikacji webowej korzystającej ze Spring Framework.
 osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900
1 ACTIVE org.eclipse.osgi.util_3.1.300.v20080303
2 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605
3 ACTIVE org.ops4j.pax.logging.pax-logging-api_1.1.1
4 ACTIVE org.ops4j.pax.logging.pax-logging-service_1.1.1
5 ACTIVE com.springsource.javax.el_2.1.0
6 ACTIVE com.springsource.javax.servlet.jsp_2.1.0
7 ACTIVE com.springsource.javax.servlet.jsp.jstl_1.1.2
8 ACTIVE com.springsource.junit_3.8.2
9 ACTIVE com.springsource.net.sf.cglib_2.1.3
10 ACTIVE com.springsource.org.aopalliance_1.0.0
11 ACTIVE com.springsource.org.apache.taglibs.standard_1.1.2
12 ACTIVE com.springsource.org.objectweb.asm_2.2.3
13 ACTIVE org.mortbay.jetty.server_6.1.9
14 ACTIVE org.mortbay.jetty.util_6.1.9
15 ACTIVE org.springframework.osgi.jetty.start.osgi_1.0.0
16 RESOLVED org.springframework.osgi.jetty.web.extender.fragment.osgi_1.0.0
Master=27
17 ACTIVE org.springframework.osgi.servlet-api.osgi_2.5.0.SNAPSHOT
18 ACTIVE org.springframework.bundle.spring.aop_2.5.5
19 ACTIVE org.springframework.bundle.spring.beans_2.5.5
20 ACTIVE org.springframework.bundle.spring.context_2.5.5
21 ACTIVE org.springframework.bundle.spring.context.support_2.5.5
22 ACTIVE org.springframework.bundle.spring.core_2.5.5
23 ACTIVE org.springframework.bundle.osgi.core_1.2.0.m1
24 ACTIVE org.springframework.bundle.osgi.extender_1.2.0.m1
25 ACTIVE org.springframework.bundle.osgi.io_1.2.0.m1
26 ACTIVE org.springframework.bundle.osgi.web_1.2.0.m1
27 ACTIVE org.springframework.bundle.osgi.web.extender_1.2.0.m1
Fragments=16
28 ACTIVE org.springframework.bundle.spring.web_2.5.5
29 ACTIVE org.springframework.bundle.spring.webmvc_2.5.5
Najlepiej skorzystać z przykładów dystrybuowanych w ramach samego Spring-DM. Musimy je zbudować lokalnie za pomocą Apache Maven 2 (nie udało mi się znaleźć ich dostępnych binarnie w Sieci). W katalogu src Spring-DM wykonujemy polecenie mvn package -Pequinox,samples -Dmaven.test.skip=true.
 jlaskowski@work /cygdrive/c/apps/spring-osgi/src
$ mvn package -Pequinox,samples -Dmaven.test.skip=true
...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] Spring Dynamic Modules ................................ SUCCESS [2.203s]
[INFO] Spring OSGi Mocks ..................................... SUCCESS [8.578s]
[INFO] Spring OSGi IO ........................................ SUCCESS [0.188s]
[INFO] Spring OSGi Core ...................................... SUCCESS [1.343s]
[INFO] Spring OSGi Extender .................................. SUCCESS [0.438s]
[INFO] Spring OSGi Testing Framework ......................... SUCCESS [22.281s]
[INFO] Spring OSGi Web Support ............................... SUCCESS [0.516s]
[INFO] Spring OSGi Web Extender .............................. SUCCESS [0.218s]
[INFO] Spring OSGi Archetype ................................. SUCCESS [1.188s]
[INFO] Spring OSGi Annotations ............................... SUCCESS [0.156s]
[INFO] Spring OSGi Samples ................................... SUCCESS [0.078s]
[INFO] Spring OSGi Samples: Simple Service ................... SUCCESS [0.016s]
[INFO] Spring OSGi Samples: Simple Service Provider .......... SUCCESS [0.062s]
[INFO] Spring OSGi Samples: Simple Service Integration Tests . SUCCESS [0.063s]
[INFO] Spring OSGi Samples: Weather Service .................. SUCCESS [0.000s]
[INFO] Spring OSGi Samples: Weather Service DAO .............. SUCCESS [0.109s]
[INFO] Spring OSGi Samples: Weather Service Extension ........ SUCCESS [0.172s]
[INFO] Spring OSGi Samples: Weather Service Provider ......... SUCCESS [0.109s]
[INFO] Spring OSGi Samples: Weather Service Client ........... SUCCESS [0.125s]
[INFO] Spring OSGi Samples: Weather Service Wiring Bundle .... SUCCESS [0.078s]
[INFO] Spring OSGi Samples: Weather Service Integration Test . SUCCESS [0.125s]
[INFO] Spring OSGi Samples: Simple Web Application ........... SUCCESS [0.000s]
[INFO] Spring OSGi Samples: SimpleWebApp - Log4j Fragment .... SUCCESS [0.438s]
[INFO] Spring OSGi Samples: SimpleWebApp - War Bundle ........ SUCCESS [0.578s]
[INFO] Spring OSGi Samples: SimpleWebApp - Integration Test .. SUCCESS [0.281s]
[INFO] Spring OSGi Samples: OSGi Web Console ................. SUCCESS [0.016s]
[INFO] Spring OSGi Samples: OSGi Web Console - Log4j Fragment SUCCESS [0.359s]
[INFO] Spring OSGi Samples: OSGi Web Console - War Bundle .... SUCCESS [0.719s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 47 seconds
Następnie, w ramach konsoli Equinoksa wdrażamy aplikację Simple Web Application (katalog samples/simple-web-app).

Najpierw instalacja pakunku war-1.2.0-m1.war.
 osgi> install file:c:/apps/spring-osgi/src/samples/simple-web-app/war/target/war-1.2.0-m1.war
[OSGi Console] DEBUG org.springframework.osgi.extender.internal.activator.ContextLoaderListener -
Processing bundle event [INSTALLED] for bundle [org.springframework.osgi.samples.simplewebapp]
[OSGi Console] DEBUG org.springframework.osgi.extender.internal.activator.ContextLoaderListener -
Processing bundle event [INSTALLED] for bundle [org.springframework.osgi.samples.simplewebapp]
Bundle id is 30
[Framework Event Dispatcher] INFO org.springframework.osgi.samples.simplewebapp - BundleEvent INSTALLED
Jak można zauważyć instalacja aplikacji (będącej pakunkiem OSGi) wzbudziła słuchacza org.springframework.osgi.extender.internal.activator.ContextLoaderListener, który odpowiedzialny jest za zestawienie środowiska (kontekstu) springowego dla aplikacji korzystających z/opartych o Spring Framework.

Teraz pozostaje już tylko uruchomić pakunek poleceniem start 30 (może być wymagane wciśnięcie ENTER dwukrotnie - raz, aby zatwierdzić polecenie, a drugi w połowie przetwarzania polecenia start). Z komunikatem
 [Timer-3] INFO org.springframework.osgi.web.deployer.jetty.JettyWarDeployer - 
Successfully deployed bundle [Simple OSGi War (org.springframework.osgi.samples.simplewebapp)]
at [/simple-web-app] on server Jetty-6.1.x
pozostaje jedynie odwiedzić stronę aplikacji - http://localhost:8080/spring-osgi-webapp/.

Działa! Kolejny krok to pomysł na ciekawą aplikację webową demonstrującą siłę środowiska OSGi z Spring-DM, czyli mieszankę funkcjonalności OSGi, Spring Framework i Java EE. Wciąż pamiętam komentarze Daniela (zebrane w Pora na łyk OSGi - rozdział 1. Wprowadzenie). I uwierzyć, że gość stosuje Spring Framework z OSGi od tak dawna. Musi mieć niezłą zabawę czytając kolejne wpisy z moimi poczynaniami ;-)

12 października 2008

pax-runner w akcji - uruchamianie aplikacji webowych jako pakunków OSGi

0 komentarzy
Po tygodniach walki ze Spring Dynamic Modules (Spring-DM) zaczynam dostrzegać wiele problemów, które z pewnością wielu odepchnęło od produktu (a może jest to sposób na zainteresowanie innym produktem - SpringSource dm Server?). Mimo nieustających pytań na forum Spring-DM dotyczących uruchomienia Apache Tomcat 6.0.18 na Spring-DM jedyne, co udało się zestawić do tej pory, to lista pakunków z różnych repozytoriów, które ostatecznie pozwoliły mi na wdrożenie pakunku będącego aplikacją webową, aczkolwiek nie udało mi się jej uruchomić w przeglądarce (cf. Trouble with catalina 6.0.18...).

Kiedy to poraz kolejny przeszukiwałem Sieć, aby odnaleźć jakiekolwiek informacje dotyczących uruchomienia aplikacji webowych jako pakunków na Tomcat 6.0.18 w ramach Spring-DM i Equinox natrafiłem na projekt pax-runner. Wystarczyło poznać kilka opcji (niecałe 15 minut i to wyłącznie ze względu na błąd na Windows opisany w FAQ jako I'm using Pax Runner on DOS/Windows, I have the right command but I'm getting strange errors) i mogłem cieszyć się poprawnie działającą aplikacją webową. Faktycznie, spełniły się cele projektu pax-runner opisane w jego sekcji Overview:

If any of the following is true:
  • You often change from one OSGi platform to another.
  • You don't know what OSGi is, but want to spend half an hour checking it out.
  • You can't be bothered about following the setup and requirements README for the OSGi platform of your choice.
  • You have problem to get the OSGi platform working at all.
then perhaps the Pax Runner can help.


Już dawno nie doświadczyłem tego uczucia, kiedy po kwadransie wszystko działało zgodnie z założeniami. Niesamowite uczucie! Spróbuj, a przekonasz się, jak proste oprogramowanie można udostępniać klientom i to całkowicie za darmo (a wspierane technologie i projekty - OSGi, Spring-DM, Equinox wcale nie należą do najprostszych).

Wystarczy pobrać pax-runner (strona Pax Runner - Download), rozpakować w wybranym katalogu i można zaczynać podboje OSGi dla aplikacji webowych. W dodatku wiele z istotnych ustawień konfiguracyjnych, np. uruchomione pakunki czy uruchomienie Equinoksa z "czystą" konfiguracją, jest od razu zapisywane w pliku konfiguracyjnym - runner/equinox/config.ini, który można użyć już poza środowiskiem pax-runner. Wciąż jestem pod wrażeniem prostoty i użyteczności pax-runner. Wiele parametrów konfiguracyjnych jest ustawionych dokładnie jak możnaby sobie tego życzyć. Cudeńko!

 C:\apps\equinox-springdm\pax-runner-log-profile
> pax-run "--platform=equinox" "--log=DEBUG" "--profiles=war"
______ ________ __ __
/ __ / / __ / / / / /
/ ___/ / __ / _\ \ _/
/ / / / / / / _\ \
/__/ /__/ /__/ /_/ /_/

Pax Runner (0.13.0) from OPS4J - http://www.ops4j.org
-----------------------------------------------------

-> Using config [classpath:META-INF/runner.properties]
-> Installing additional services
-> Installing service [service.obr]
-> Installing handlers
-> Handler [handler.mvn]
-> Handler for protocols [mvn] started
-> Handler [handler.classpath]
-> Handler for protocols [classpath] started
-> Handler [handler.war]
-> Handler for protocols [war, war-i] started
-> Handler [handler.wrap]
-> Handler for protocols [wrap] started
-> Handler [handler.obr]
-> Creating replaceable service for [interface org.osgi.service.obr.RepositoryAdmin]
-> Creating service collection for [interface org.osgi.service.obr.RepositoryAdmin]
-> Added service with reference [[org.osgi.service.obr.RepositoryAdmin]]
-> Related service [org.apache.felix.bundlerepository.RepositoryAdminImpl@1201a25]
-> Service changed [null] -> [org.apache.felix.bundlerepository.RepositoryAdminImpl@1201a25]
-> Handler for protocols [obr] started
-> URL stream handler service available [[org.osgi.service.url.URLStreamHandlerService]]
-> Registering protocols [[mvn]] to service [org.ops4j.pax.url.commons.handler.HandlerActivator$Handler@1bd4722]
-> URL stream handler service available [[org.osgi.service.url.URLStreamHandlerService]]
-> Registering protocols [[obr]] to service [org.ops4j.pax.url.commons.handler.HandlerActivator$Handler@1a73d3c]
-> URL stream handler service available [[org.osgi.service.url.URLStreamHandlerService]]
-> Registering protocols [[classpath]] to service [org.ops4j.pax.url.commons.handler.HandlerActivator$Handler@1f20eeb]
-> URL stream handler service available [[org.osgi.service.url.URLStreamHandlerService]]
-> Registering protocols [[wrap]] to service [org.ops4j.pax.url.commons.handler.HandlerActivator$Handler@1b10d42]
-> URL stream handler service available [[org.osgi.service.url.URLStreamHandlerService]]
-> Registering protocols [[war, war-i]] to service [org.ops4j.pax.url.commons.handler.HandlerActivator$Handler@1f7d134]

-> URL stream handler service extender started
-> Installing provisioning
...
[main] INFO org.mortbay.jetty - jetty-6.1.x
...
osgi> install file:c:\projs\osgi\spring-osgi-webapp\target\spring-osgi-webapp.war
Bundle id is [Framework Event Dispatcher] INFO pl.jaceklaskowski.osgi.spring-osgi-webapp - BundleEvent INSTALLED
8

osgi> start 8
[OSGi Console] DEBUG org.ops4j.pax.swissbox.extender.BundleWatcher - Scanning bundle [pl.jaceklaskowski.osgi.spring-osgi
-webapp]
...
[OSGi Console] INFO org.ops4j.pax.web.service.internal.HttpServiceProxy - Setting context paramters [{webapp.context=pl.
jaceklaskowski.osgi.spring-osgi-webapp}] for http context [org.ops4j.pax.web.extender.war.internal.WebAppHttpContext@15e
2075]
...

osgi> ss

Framework is launched.

id State Bundle
0 ACTIVE org.eclipse.osgi_3.4.0.v20080605-1900
1 ACTIVE org.eclipse.osgi.util_3.1.300.v20080303
2 ACTIVE org.eclipse.osgi.services_3.1.200.v20070605
3 ACTIVE org.ops4j.pax.logging.pax-logging-api_1.1.1
4 ACTIVE org.ops4j.pax.logging.pax-logging-service_1.1.1
5 ACTIVE org.ops4j.pax.web.service_0.5.1
6 ACTIVE org.ops4j.pax.web.jsp_0.5.1
7 ACTIVE org.ops4j.pax.web.extender.war_0.4.0
8 ACTIVE pl.jaceklaskowski.osgi.spring-osgi-webapp_1.0.0
I uruchomienie aplikacji w przeglądarce - http://localhost:8080/pl.jaceklaskowski.osgi.spring-osgi-webapp/index.jsp - działa jak należy.

Dodając do cech pax-runner automatyczne pobieranie zależności (pakunków) z Sieci i mamy niewielkie acz bogate funkcjonalnie narzędzie, które każdy parający się OSGi musi koniecznie posmakować.

Jeśli zastanawiasz się, a gdzie jest miejsce dla Spring-DM i po co on nam, to do zestawiania środowiska springowego dla pakunków nie ma (znanego mi) lepszego narzędzia niż on, a pax-runner udostępnia profil spring-dm-1.0.2. Wystarczy uruchomić i do dzieła!