Pokazywanie postów oznaczonych etykietą glassfish. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą glassfish. Pokaż wszystkie posty

10 marca 2011

Jedynie beanName albo lookup w @EJB dozwolone, a GlassFish 3.1 akceptuje oba równocześnie

2 komentarzy
A to dopiero znalezisko! Właśnie natrafiłem na błąd w GlassFish 3.1 przy obsłudze adnotacji @EJB.

Zgodnie z javadoc dla @EJB:

"Either the beanName or the lookup element can be used to resolve the EJB dependency to its target session bean component. It is an error to specify values for both beanName and lookup."

Stąd należałoby oczekiwać, że uruchomienie poniższego komponentu EJB powinno zakończyć się błędem - zwróć uwagę na adnotację @EJB z atrybutami beanName oraz lookup.
package pl.japila.ejb.test;

import javax.ejb.EJB;
import javax.ejb.Stateless;

import pl.japila.ejb.Hello;

@Stateless
public class TestFacadeEJB implements Hello {

    @EJB(beanName="HelloInEnglish", lookup="java:global/classes/HelloPoPolsku")
    Hello hello;

    @Override
    public String sayHello(String whom) {
        return hello.sayHello(whom);
    }

}
Nic bardziej mylnego! Wdrożenie takiego EJB jest całkowicie legalne w GlassFish i nie zakończy się błędem.

Pytanie uzupełniające: Który z atrybutów ma wyższy priorytet - beanName czy lookup, czyli które będzie brane pod uwagę przy rozwiązywaniu @EJB?

Odpowiedź pozostawiam najbardziej dociekliwym i wytrwałym, którzy przykład uruchomili korzystając z artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz.

A jak to jest w innych serwerach? Sprawdzę jeszcze WAS8 i OpenEJB 3.1.4, a ucieszyłbym się, gdybym dowiedział się od kogoś jak to jest obsłużone w JBoss AS 6 czy Oracle WebLogic Server 11g?

09 marca 2011

Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz

0 komentarzy
Posiłkując się doświadczeniami z Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0 oraz Element beanName w @EJB do rozróżnienia deklaracji ziaren EJB stworzyłem przyczułek do dalszych doświadczeń ze specyfikacjami EJB 3.1 oraz CDI 1.0. Tym razem na warsztat wziąłem zbadanie mechanizmu przekazywania zależności (ang. DI, dependency injection) w EJB 3.x.

Potrzebowałem środowiska, w którym będę mógł uruchomić testy automatycznie bez konieczności zestawiania skomplikowanego środowiska uruchomieniowego. Zaletą takiego podejścia może być chociażby uruchomienie testów w dowolnym momencie, na dowolnym komputerze i przez dowolnego (nawet nowego!) członka zespołu. Starałem się utrzymać minimalny nakład pracy, aby łatwiej było przedstawić problem, z którym się zmagam.

Zainteresowany/-a szczegółami? Zapraszam do lektury mojego artykułu Słabo typizowane DI w EJB 3.x - o beanName w @EJB jeszcze raz. Uwagi bardzo mile widziane.

07 lutego 2011

Uruchomić zadanie co 5 sekund w EJB 3.1 ze @Schedule(second = "*/5", info="Every 5 seconds")?

13 komentarzy
Pomyślałby kto, że uruchomienie zadania w EJB 3.1 co 5 sekund wymaga jedynie stworzenia bezstanowego ziarna sesyjnego z metodą opatrzoną adnotacją @Schedule(second = "*/5", info="Every 5 seconds") i gotowe. Nic bardziej mylnego! Okazuje się, że domyślne wartości dla atrybutów @Schedule to zerowa sekunda, minuta i godzina, więc brak ich określenia sprawi, że kolejne uruchomienie będzie o północy następnego dnia. Można się nieźle przejechać podczas wdrożenia.

Więcej (kompletny projekt i kilka dodatkowych przemyśleń) w artykule Uruchomienie cyklicznego zadania w EJB 3.1 ze @Schedule.

p.s. Wciąż zastanawiam się nad moim rozdwojeniem językowym - polskojęzycznym (tutaj) i angielskojęzycznym (na http://blog.japila.pl). Głównym motywem był brak interakcji z czytelnikami, co potwierdziła statystyka na blog.japila.pl, gdzie przy 11 wpisach mam 22 komentarze. Inaczej niż tutaj i po cichutku liczę na choć szczątkowy odzew, np. co należałoby usprawnić w artykule, a szczególnie w sekcji dotyczącej testowania. Nie mam lepszego pomysłu na przetestowanie @Schedule niż to, co zaproponowałem w artykule. Dotknął ktoś tego problemu? Jakieś wskazówki na bardziej eleganckie rozwiązanie?

p.s.2. W kolejnych odcinkach dalej o usłudze budzika (ang. timer service) w EJB 3.1. Może jakieś podpowiedzi, np. z jakim kontenerem? Brak traktuję jako zachętę ku IBM WebSphere Application Server V8 lub Apache OpenEJB 3.2.

03 stycznia 2011

NetBeans 7 i Add Embeddable EJB Container, Create JUnit Tests oraz Code Generation in pom.xml

1 komentarzy
W Java EE 5 udostępniono możliwość uruchamiania Java Persistence (JPA) 1.0 poza środowiskiem serwera aplikacyjnego - można przeczytać o tym w moim artykule Java Persistence API w samodzielnej aplikacji.

W Java EE 6, poza JPA 2.0, można jeszcze uruchomić kontener Enterprise JavaBeans (EJB) 3.1 oraz kontener Contexts and Dependency Injection (CDI) 1.0. O tym pierwszym - EJB 3.1 - pisałem w Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, a o drugim - CDI - w Contexts and Dependency Injection (CDI) praktycznie - zestawienie środowiska z JBoss Weld, Arquillian i Apache Maven 2.

Zacząłem drążyć temat EJB 3.1 z NetBeans 7 i całkiem przypadkiem doszukałem się dwóch użytecznych funkcji - Add Embeddable EJB Container oraz Create JUnit Tests. Sprawdźmy je w działaniu zamiast rozwodzić się nad ich użytecznością (albo ich brakiem).

Cmd+Shift+N - Maven > EJB Module, podaj Project Name, np. aaa i Finish. Mamy projekt EJB zarządzany przez Apache Maven.

Cmd+N - Enterprise JavaBeans > Session Bean, wciśnij Next >, wybierz pakiet z listy w Package i Finish. I mamy komponent EJB.

Otworzy się nowa klasa ziarna EJB 3.1. W jej ciele, Ctrl+i i wybierz Add Business Method... i OK. Pojawi się nowa metoda public void businessMethod(). W jej ciele, wpisz sout i wciśnij TAB. Wpisz Witaj! W ten sposób masz gotowe do uruchomienia ziarno EJB z metodą biznesową, której zadaniem jest wyświetlenie Witaj!

Wybierz nowoutworzoną klasę NewSessionBean i z menu pod prawym klawiszem myszki wybierz Tools > Create JUnit Tests.
Pojawi się panel konfiguracyjny klasy testowej.

Zatwierdź przyciskiem ENTER.

Zaraz po tym powinien otworzyć się edytor z właśnie stworzoną klasą testującą z metodą testBusinessMethod(). Usuń linię fail("The test case is a prototype.");, np. przez Cmd+x. Test gotowy.

Uruchomienie testu - Cmd+F6.
-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running pl.jaceklaskowski.jee6.abc.NewSessionBeanTest
businessMethod
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.396 sec <<< FAILURE!

Results :

Tests in error: 
  testBusinessMethod(pl.jaceklaskowski.jee6.abc.NewSessionBeanTest)

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0

------------------------------------------------------------------------
BUILD FAILURE
------------------------------------------------------------------------
Pojawił się błąd? Jak najbardziej oczekiwany (zajrzyj do What's the cause of this exception: java.lang.ClassFormatError: Absent Code? po więcej wyjaśnień).

Nie wiem, co informuje NetBeans 7 o konieczności pojawienia się pomocy, albo jak długo należy czekać na jej pojawienie się, ale dłuższa chwila, dwie i na projekcie pojawi się ikona z żółtym wykrzyknikiem.

Kiedy najedzie się na katalog projektu pojawi się chmurka z wyjaśnieniem powodu, dla którego pojawił się wykrzyknik - Missing Embeddable EJB Container.

Wtedy, pod prawy przyciskiem myszki znajdziemy menu Show and Resolve Problems...

Pojawi się okienko dialogowe, w którym pojawi się Missing Embeddable EJB Container z przyciskiem Add Embeddable EJB Container.
Kiedy wciśniesz przycisk, do projektu dodana zostanie zależność i repozytorium, gdzie się znajduje. Spróbuj.

  org.glassfish.extras
  glassfish-embedded-all
  3.0
  test


  
    http://download.java.net/maven/glassfish/
    http://download.java.net/maven/glassfish/
    default
  
Warto dodać, że zapoznanie się z pom.xml dla tego projektu, to wyzwanie same w sobie. Tyle kombinacji, aby uruchomić wbudowany kontener EJB 3.1 z GlassFish 3.0. Warto dla kogoś, kto chciałby poznać Mavena od podszewki (co w tym przypadku lepiej wykonałby Maven podpierając się Apache Ant przez wtyczkę maven-antrun-plugin).

A tak całkiem przy okazji mojej nauki uruchamiania wbudowanego kontenera EJB 3.1, wyczytałem w STS 70 Maven :: Test Specification: Maven Support Test Specification, że edytor pom.xml ma specjalizowany system podpowiedzi Code Generation in pom.xml. W pom.xml wciskamy kombinację klawiszy Alt+Insert i możemy wybrać jedną z kilku opcji utworzenia sekcji XMLowej.

Dla początkujących, jak znalazł.

30 grudnia 2010

Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0

1 komentarzy
Biorąc pod uwagę liczbę dni do końca roku, ten wpis będzie co najwyżej przedostatnim wpisem na moim blogu, a na pewno ostatnim dotykającym tematu Java EE 6, EJB 3.1 i in.

Korzystając z okazji, chciałbym życzyć Tobie wszystkiego dobrego w nowym roku 2011 i nakłaniam do jeszcze większej aktywności. Nie czekaj, aż powiedzą, ale mów, proponuj, bądź liderem w swojej społeczności. Dla poszukujących natchnienia polecam lekturę wpisu na blogu Damiana Nowaka - Apprenticeship – długa droga ku Software Craftsmanship. Nie wiem, czy to styl pisania Damiana, czy może sama książka, ale tylko takich wpisów życzę nam w nadchodzącym roku. Niech kasa pójdzie w zapomnienie - niech będzie jej tyle, aby nie stanowiła kwestii do rozwiązania - a czas spędzajmy na tworzeniu - nowego i użytecznego oprogramowania, społeczności przez chociażby dzielenie się wiedzą. Nie ważne jaki był (i jeszcze będzie przez kolejne 2 dni) rok 2010, ale ważne, ile możesz zrobić, aby 2011 był jeszcze lepszy. Zalatuje socjotechniką, ale dobre myślenie poprawia mój nastrój, więc może i Twój również, a to może przełożyć się na coś wyjątkowego.

W takim tonie przedkładam Tobie do oceny mój nowy artykuł Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0, w którym...

Rozdział 22. Embeddable Usage specyfikacji Enterprise JavaBeans (EJB) 3.1 opisuje nową cechę specyfikacji, która pozwala na uruchomienie kontenera EJB i zarządzanych przez niego komponentów EJB poza serwerem aplikacyjnym Java EE 6 - jedynie na poziomie środowiska Java SE. W ten sposób autorzy specyfikacji przewidują (a my programiści im wierzymy) uproszczenie procesu testowania, przetwarzania wsadowego (w którym użycie transakcji jest kluczowe) czy użycie EJB w samodzielnych aplikacjach desktopowych. Innymi słowy, mamy wszystko, co oferuje kontener EJB 3.1 bez konieczności uruchamiania pełnego serwera aplikacyjnego Java EE, którego sama konfiguracja uruchomieniowa mogła przyprawić o ból głowy.

Zainteresowanych lekturą nie zatrzymuję już i jeszcze tylko na odchodne dorzucę nieśmiało, aby komentować, pytać i kwestionować. Wszyscy zostaną *odpowiednio* potraktowani :-)

01 grudnia 2010

Java EE 6 webapp development with CDI, GlassFish and NetBeans 7

9 komentarzy
Próbowałem się z NetBeans IDE 7.0 (wersja rozwojowa z dzisiaj) i kiedy sprawdzałem możliwości CDI z przekazywaniem (aka wstrzykiwaniem) zależności do servletu przyszło mi do głowy, aby nagrać moje doświadczenia. Nie są one wyrafinowane, ale chodziło mi raczej o popróbowanie się ze skrinkastami w kwadrans, aby nabrać większej umiejętności w tego typu przekazie niż na samej oprawie czy treści. Chciałem również sprawdzić, czy uda mi się opublikować nagranie na YouTube w formacie 1080p.

Zero podkładu głosowego, zero muzyni, niewiele treści merytorycznej, ale nagranie w Full HD jest. Tym samym 3-minutówka znalazła się na YouTube do oceny publiczności.

Teraz kolej na Ciebie. Zadanie na dziś to obejrzenie filmiku i ocena jego przydatności, a właściwie wskazanie niedoskonałości i tym samym zagwarantowanie sobie bardziej przyzwoitej treści w kolejnych odsłonach.

Zapraszam na swój kanał na YouTube do obejrzenia Java EE 6 webapp development with CDI, GlassFish and NetBeans 7.

p.s. Uruchomiłem ankietę "Temat przewodni na grudzień", której celem jest określenie tematyki, którą chciał(a)byś, abym rozpracowywał w ostatnim miesiącu tego roku - grudniu 2010. Zainteresowanych wyrażeniem swojego zdania zapraszam na blog, gdzie po prawej u góry znajduje się ankieta. Sugestie w postaci odpowiedzi "Inne?!" proszę o rozwinięcie na priv, albo w komentarzu do tego wpisu.

29 listopada 2010

Po wykładzie na PWSZ w Tarnowie

14 komentarzy
O planach związanych z wykładem pisałem w poprzednim wpisie - Wykład akademicki na PWSZ w Tarnowie - 29.11 od 9:30 do 18:00 i jak to w życiu bywa - plany swoje, a życie swoje.

Mając niemałe obawy o zakres merytoryczny wykładu, postanowiłem przelecieć większość z tego, co nazwałbym interesującym wycinkiem mojej wiedzy technicznej, aby choć na moment móc podzielić się czymś nowym z uczestnikami. Sądziłem, że uczestnicy większość tematów mają już za sobą, więc pojawiły się produkty IBM, o których, jeśli słyszano, to niewiele praktycznie i choć one gwarantowały mi możliwość przekazania czegoś niezbadanego. Po ostatnich szkoleniach z IBM WebSphere BPM z programowania i administracji nie miałem złudzeń, że w ostateczności wejdę na niskopoziomowe "rozbieranie" trzewi WPS V7 czy WAS V8. Sądziłem, że coś w końcu będzie wartościowe, aby spędzić kilka chwil i wziąć udział w wykładzie.

Do ostatniej chwili nie byłem pewien, czy dobrze dopasowałem tematykę. Czym bliżej wystąpienia, tym nachodziła mnie większa ochota, aby w niej pomajstrować. Wziąłem kilka książek, aby tam znaleźć coś unikatowego, a jednocześnie wartościowego, zabrałem się za lekturę podręczników, itp. Zacząłem odczuwać tremę przed niewstrzeleniem się w oczekiwania (które mogły być podkręcone moimi wycieczkami w różne strony rozwiązań javowych).

Zaplanowałem całkiem pokaźny bagaż tematyczny (vide poprzedni wpis z harmonogramem) i wszystko miało odbyć się bez nawet najdrobniejszego slajdu, aby ostatecznie okazać się, że z grupy około 50 osób niewiele ponad 3 osoby miały styczność z Javą (!) To było chyba najbardziej dla mnie szokujące. Ja tu zmagałem się z JEE6 i poziomy wyżej, przy SCA i BPEL, a okazało się, że należało zacząć od samego początku - samego poznawania języka Java. Trafiłem do mekki programistów C!

Jako, że przygotowany byłem na wprowadzenie do dostępu do bazy danych, przez JDBC, Hibernate, Spring Framework, Hibernate+Spring Framework, JPA i EJB, w zasadzie byłem gotowy zacząć pierwsze kilka kwadransów na wprowadzenie do Javy - bez wycieczek w programowanie OO. Pozostałem przy prostych konstrukcjach typu wyświetl na ekran, pobierz z ekranu i na tym się skończyło wprowadzenie.

Zabrałem się za dostęp do bazy danych. MySQL sprawowało się znakomicie, a NetBeans IDE (wersja rozwojowa z dnia poprzedniego) całkiem sprawnie uwijała się przy składaniu kolejnych części aplikacji. Tutaj i Java Tutorial się przydał, aby pokazać, w jaki sposób można przejść podobną ścieżkę, którą właśnie przechodziliśmy (gdyby komuś przyszło do głowy odtworzyć nasze wspólne poczyniania samodzielnie). Od czasu do czasu NetBeans IDE czkał zamrażając się na dobre kilkadziesiąt sekund, co złożyłem na braku dostępu do Sieci i jego młodzieńczego wieku (w końcu to wersja rozwojowa). Na moment przełączyłem się do Eclipse IDE, ale i jemy przypomniało się, aby zaktualizować/sprawdzić coś w Sieci i zamarzł. Wróciłem do NetBeans IDE.

Na zakończenie pierwszego bloku wykładów pokazałem coś, co określiłbym - impress me. Skąd wzięło się to cudo? Chcąc dopasować się do oczekiwań uczestników, zapytałem, co jeszcze mógłbym im pokazać i padło "Zaimponuj nam czymś w Javie, co sprawiłoby, że zechcielibyśmy się nią zająć". Od razu zabrałem się za...Clojure.

Pewnie pomyślisz sobie, zwłaszcza jeśli znasz mój poziom znajomości tego języka, że to był najgorszy z możliwych wyborów. Co to, to nie. Zdecydowanie NIE. Ja wręcz uważam, że właśnie tym najbardziej ująłem ich za serce i przy tym właśnie temacie miałem wrażenie zdobyłem ich największą uwagę. Takie odniosłem wrażenie i jeśli jakikolwiek temat miał swoje komentarze, to Clojure był zdecydowanym liderem. Dlaczego? Kwintesencją dobrej prezentacji jest dopasowanie przykładu do tematu. I tak właśnie było z Clojure.

Podczas sesji z Clojure pokazałem, jak interaktywie tworzyć aplikację okienkową, gdzie rozpoczynam od "gołej" aplikacji na bazie JFrame i dodaję kolejne elementy graficzne. Kiedy pierwszy raz wpadłem na ten pomysł, wiedziałem, że to będzie cudo. Na dole miałem terminal z Clojure REPL, na górze właśnie otworzone okienko przyszłej aplikacji okienkowej, a pod nimi Eclipse z odtwarzanym skryptem, w którym widać było wpisywane linie kodu w Clojure. Zamierzam, to nagrać w postaci skrinkastu, więc chwila i sam przekonasz się, o czym się tutaj pisze.

Clojure nie jest tutaj jakimś specjalnym czymś, co sprawiłoby, że jest to możliwe. Po prostu, jako język skryptowy - podobnie jak Groovy, JRuby, Rhino, Scala, Jython - daje możliwość nauki API przez wprowadzanie kolejnych wywołań w czymś ala Clojure REPL i natychmiastowego otrzymywania rezultatów z ich uruchomienia. Możnaby to przyrównać do środowiska ciągłej nauki API. Bajka!

Po przerwie, przeszliśmy przez Hibernate, Spring Framework i tworzenie aplikacji z servletami (obsługa formularza) z niewielkim EJB uruchamianym w ramach aplikacji webowej (nowość JEE6). W zasadzie 7 osobom udało się wytrwać do 18:00, kiedy to punktualnie zakończyłem wykład.

Bardzo pomocny okazał się stoper firmy Apimac, który odmierzał równe 40-tominutówki i późniejsze 10-ciominutowe przerwy. Super rozwiązanie, aby zagwarantować pewność utrzymania czasu przez prowadzącego. Polecam!

Czego mi brakowało podczas tego wykładu, to większego udziału publiczności. Znalazło się kilku bardziej aktywnych, ale ogólnie panowała cisza i trudno było zorientować się, czy temat ciekawił, czy warto byłoby poruszyć inne aspekty i w ogóle sprawić, aby spędzony czas był wartościowy merytorycznie. Nieskromnie powiem, że bardzo ucieszyła mnie moja lekkość w zmianie tematu, tempa i dopasowanie do poziomu, ale wolałbym bardziej skrupulatne zajęcie się pojedynczym tematem, np. JEE6 niż przejściem od Java, Clojure, Hibernate, Spring, servlety i EJB. Trochę przypominało groch z kapustą, aczkolwiek zagwarantowało, że wykład spędziłem nie nudząc się ani na chwilę. Liczę, że uczestnicy również.

Sam Tarnów bardzo spokojny. Akurat dzisiaj spadło sporo śniegu, więc wszystko zasypane, ale i tak udało mi się dostrzec tlące się piękno tego miejsca. Po 18:00 w zasadzie zero otwartych sklepów i niepokojąca cisza na ulicy. Może poza Rynkiem jest inaczej?! Ach, zastanawiam się, dlaczego zegar na Ratuszu wybija połówki, kwadrans przed pełną i pełną godzinę?

p.s. Wykład prowadzony był w ramach programu Unii Europejskiej wspierającej wymianę doświadczeń między praktykami i firmy a uczelniami, z korzyścią dla nowej kadry informatycznej - studentów. Pewnie i na Twojej uczelni jest to możliwe. Wystarczy zapytać. Resztą się zajmę. Pisz na priv z prośbą o szczegóły. Na prawdę warto.

27 listopada 2010

Wykład akademicki na PWSZ w Tarnowie - 29.11 od 9:30 do 18:00

5 komentarzy
W nadchodzący poniedziałek, 29.11 będę na Wydziale Informatyki Państwowej Wyższej Szkoły Zawodowej (PWSZ) w Tarnowie (ul. Eljasza Goldhammera) u Tomasza Potempy i jego studentów, z którym zorganizowaliśmy mój wykład dotyczący tematu Java i okolice. Głównymi odbiorcami mają być studenci 4 roku, którzy kończą semestr z końcem grudnia, aby w styczniu skupić się na pisaniu pracy inżynierskiej.

Jak to ze mną bywa przy tego typu otwartych tematach, pomysłów mam wiele i byłbym rad, o kilka wskazówek pod kątem możliwości czasowych i znaczenia rynkowego poszczególnych tematów. Celem nie jest przekazanie pełnego obrazu danego rozwiązania, ale raczej naszkicowanie możliwości, aby wybrać do dalszego rozpoznania to, co może być interesujące.

Mam do dyspozycji 2 bloki 5-godzinne (w sensie lekcyjnym nie zegarowym, czyli 45 minut). Można założyć, że w każdym bloku będzie to samo, ale to zależy od ogólnego zainteresowania uczestników oraz mojego przekonania o sensowności dalszego brnięcia w temat. Tym samym nie ma gwarancji, że drugi blok będzie odpowiadał merytorycznie pierwszemu.

Zaczynam o godzinie 9:30, aby zakończyć o 18:00 z 1-godzinną przerwą obiadową w okolicach 13:15. Okazuje się, że będzie okazja spotkać się z Tomkiem Łabuzem, którego można było poznać podczas konferencji Javarsovia 2010, podczas której prezentował temat "AOP, ThreadLocal i JPA".

Planuję przeprowadzić autorski cykl tematyczny, którego mottem byłoby "Od prostoty do większej prostoty, tj. w każdym kroku ukrywamy złożoność problemu". Nie planuję prezentować slajdów, a jedynie siedzieć przed komputerem, prezentując budowanie aplikacji i machając rekoma ze wstawkami krasomówczymi.

Konspekt

Środowiska programistyczne i uruchomieniowe, darmowe i komercyjne:
  • NetBeans IDE i Eclipse IDE
  • IBM Rational Application Developer 8 i IBM WebSphere Integration Developer 7
  • GlassFish i IBM WebSphere Application Server 8 
Klient bazodanowy - tradycyjne podłączenie do bazy danych z użyciem JDBC
  • Apache Derby (wbudowane)
  • MySQL
Hibernate - warstwa pośrednia między baza danych a aplikacja
  • ORM - zapytania bliższe programiście nie adminowi bazy danych
Hibernate + Spring Framework
  • zniesienie konieczności zarządzania bytami Hibernate
  • środowisko IoC/DI
Apache Maven - zarządzanie zależnościami projektowymi
  • zniesienie konieczności dbania o zależności poza ich deklarację
  • tworzenie projektu od zera
    • z linii poleceń
    • z IDE (NetBeans IDE)
Leiningen - Maven w Clojure
  • bez XML z językiem Clojure (wrócimy do niego niebawem)
GlassFish (w NetBeans IDE) i WAS 8 - serwer aplikacyjny JEE6 (z RAD8):
  • dostęp do bazy danych (zarządzanie transakcjami)
    • JPA
    • EJB31
  • servlet - obsługa HTTP
  • JSF - budowanie widoku
    • facelets
  • CDI
EJB 3.1
  • Apache OpenEJB
  • Serwer aplikacyjny - GlassFish i WAS8
OSGi - modularność
  • podział projektu na moduły w Apache Maven był podziałem funkcjonalnym (jak OSGi)
  • samodzielna aplikacja
Clojure - język funkcyjny
  • dynamiczne tworzenie aplikacji okienkowej
Service Component Architecture (SCA) i procesy BPEL (WID/WPS)
  • odseparowanie kontraktu (interfejsu) od implementacji
  • odseparowanie szczegółów komunikacyjnych od implementacji
Wyjeżdżam z Tarnowa dopiero we wtorek, więc jeśli ktoś reflektuje na spotkanie, proszę o kontakt.

17 stycznia 2010

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

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

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

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

09 października 2009

Uruchomienie zdalnego klienta EJB wyłącznie w oparciu o interfejs biznesowy (bez implementacji)

2 komentarzy
Właśnie takiego obrotu sprawy sobie życzyłem. Publikuję wyniki moich doświadczeń szerszemu gronu z nadzieją, że komukolwiek zechce się poświęcić trochę czasu na prześledzenie mojego toku myślenia i samych wyników. Tak też było w przypadku mojego, ostatniego artykułu Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3). Jego celem było sprawdzenie zachowania się zdalnej referencji EJB3 podczas niedostępności serwera. Przeoczyłem jednak fakt, że aplikacja kliencka dystrybuowana była nie tylko ze zdalnym interfejsem biznesowym, ale również z jego implementacją jako bezstanowe ziarno sesyjne EJB. Nie długo trzeba było czekać, aby takiemu podejściu zaprotestował Łukasz Lenart:

Jedna uwaga, która ogólnie jest globalna do tego typu przykładów. Mianowicie klientowi dostarczasz nie tylko interfejs ale również implementację jako zależność, przez co używanie serwera aplikacyjnego do zdalnej komunikacji jest zbędnym narzutem. Nigdzie jeszcze nie znalazłem przykładu jak to zrobić bez dostarczania implementacji a tylko sam interfejs. Moje próby potwierdziły tylko, że tego nie da się zrobić w przypadku Glassfisha :-(

Problem, jaki wskazał Łukasz, polegał na dystrybuowaniu zdalnego klienta EJB3 w paczce, która zawierała nie tylko interfejs biznesowy, ale i jego implementację (!) Przyznaję, że nie pomyślałem o takim skonstruowaniu paczki dystrybucyjnej klienta, która nie zawierałaby implementacji komponentu EJB, z którego korzysta. Kiedy przeczytałem komentarz, a szczególnie jego ostatnie zdanie, nie miałem złudzeń czym się zająć.

Ten rodzaj reakcji jest zapewne największym podziękowaniem czytelników - dzielimy się własnymi reakcjami na proponowaną rzeczywistość. W końcu autor mógł nie wiedzieć, że da się lepiej, lub po prostu uważać to za nieistotne. Stwarza się w ten sposób okazję do wymiany doświadczeń w jedną (od autora) i drugą, zwrotną stronę (od czytelników), w której nie ma strony wiodącej (poza stroną inicjującą dyskusję, ale tutaj trudno wskazać, czy sam autor artykułu, czy komentarza nią jest - świetny temat na pracę doktorską z filozofii :-)). Tak czy owak, jest nad czym się pochylić i artykuł spełnia swoją rolę - nie jest jednostronny. Najważniejsze, że przy takim podejściu nikt nie traci, bo ja miałem kolejny temat, a Łukasz et al rozwiązanie. Idziemy tym samym naprzód i kolejne projekty stają jeszcze prostsze technologicznie.

Uwielbiam takie publiczne dywagacje, bo nigdy nie wiadomo z kim przyjdzie mi rozmawiać. W przypadku Łukasza to sprawa jest prosta - dostaje baty w bilarda, więc chciał się odegrać :P Ale nie tylko Łukasz zareagował! Dostałem prywatnie komentarz od Pawła Balczyńskiego, który znalazł błąd w jednym z listingów. Standardowe "U mnie działa" miało przez chwilę zastosowanie, ale fakt faktem błąd był (tylko dlaczego u mnie działało?!). Dzięki Paweł!

Zainteresowanych kolejnym doświadczeniem i jego wynikami zapraszam do lektury nowego artykułu Uruchomienie zdalnego klienta EJB wyłącznie w oparciu o interfejs biznesowy (bez implementacji). Teraz oczekuję kolejnej porcji pomysłów na udoskonalenie warsztatu. Komenatrze mile widziane - na priv, albo w komentarzu do tego wpisu.

05 października 2009

Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3)

8 komentarzy
Niedawno dostałem do skrzynki takie pytanie:

(...)Głównie nurtuje mnie "jak długo" po otrzymaniu referencji do ejb mogę go używać (kontener może go przecież spasywować/usunąć albo *** wie, co jeszcze zrobić) - mogę z niego korzystać dowolnie długo/pobierać od nowa co wywołanie metody biznesowej czy jeszcze inaczej?

Początkowo miałem po prostu odpowiedzieć i zapomnieć o temacie. Zdalna referencja jest jedynie pośrednikiem (ang. proxy) między kodem klienta a serwerem i tak na prawdę odpowiada jedynie za komunikację z serwerem bez utrzymywania jakiegokolwiek stanu komponentu EJB. Mimo jasnej dla mnie odpowiedzi, postanowiłem sprawdzić ją w ramach niewielkiego eksperymentu, który miał mi nie tylko zweryfikować samą odpowiedź, ale również dać nową na pytanie, ile czasu potrzeba na zestawienie środowiska do jego przeprowadzenia. Do dyspozycji miałem linię poleceń lub IDE. Z IDE jest o tyle problem, że trudno wybrać to jedyne (w przypadku projektów Java EE wskazywałbym na NetBeans IDE), więc pozostałem przy linii poleceń. Tak się bawiłem, że skończyło się na nowym artykule - Jak długo korzystać z referencji bezstanowego komponentu sesyjnego EJB (na przykładzie EJB 3.0 i GlassFish v3).

Wykorzystałem w nim Apache Maven 2.2.1 i GlassFish v3 b66 do zestawienia projektu wielomodułowego, który posłużył mi za materiał testowy. Jest też kilka miejsc oznaczonych TODO, dla osób, które rozmyślają, jakby tu zaangażować się w naukę technologii javowych praktycznie. Ufam, że lektura dostarczy równie wiele zabawy co i mi. Pochwały/nagany mile widziane.

p.s. Zastanawiam się, czy nie warto rozważyć screencastów (brakuje mi dla tego chwytliwego odpowiednika po polsku). Wink, Camtasia, a może jeszcze coś innego? Pewnie z udziałem NetBeans IDE 6.8 dev, bo w końcu tego typu projekty dobrze się w nim robi. Co o tym sądzicie?

27 września 2009

Java EE 6 i OSGi z FishCAT i "Pro Spring Dynamic Modules for OSGi Service Platforms"

2 komentarzy
Rozpoczął się FishCAT, czyli program testowania najnowszego wydania GlassFish v3 (b65), który ma ocenić gotowość produktu do produkcyjnych wdrożeń. Tym samym moja aktywność wokół Grails zostaje wzbogacona o doświadczenia z GlassFishem.

Z listu powitalnego do FishCAT - [FishCAT] Please start FishCAT testing on b65, Thanks ! - można przeczytać, że:

Here is FishCAT testing schedule. Bugs filed after the ending date may be differed to next release based on
the priority. Hope you will find some time in next to weeks to help us testing.

FishCAT Testing Schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT doc review schedule: 9/25/09 - 10/9/09 (2 weeks)
FishCAT i18n/l10n testing: 9/25/09 - 10/21/09 (4 weeks)


czyli jedynie 2 tygodnie na testowanie produktu przed finalnym wydaniem. Zdaje się, że w tym czasie należy oczekiwać również wielu finalnych wydań specyfikacji wchodzących w skład Java EE 6. Proszę, proszę, to było w końcu rok temu, kiedy na rynku pojawiło się Java EE 5, a tu mamy nową wersję. Ta również ma być jeszcze ciekawsza niż poprzednie. I znowu wyścig serwerów aplikacyjnych o prym w realizacji Java EE 6 się zacznie.

Już od jakiegoś czasu przyglądałem się rozwojowi GF i co mnie najbardziej zachwyciło, to wsparcie dla OSGi. Oczywiście dodając do tego wsparcie Java EE 6 mamy pełen obraz, dlaczego zdecydowałem się na 2-tygodniowe turnee z GlassFishem w roli głównej. Sam udział w programie ma być pretekstem do powrotu do korzeni ze wspomnianymi technologiami, które zostały przesłonięte Grails.

Jako uzupełnienie mojego powrotu do Java EE/OSGi zabrałem się za lekturę "Pro Spring Dynamic Modules for OSGi Service Platform" z Apress. Jakkolwiek książce bliżej do rozwiązań opartych na Spring Framework, a więc bliżej jej do Grails niż GlassFish czy Java EE 6, to wszystkie technologie są tak ze sobą związane, że dotykając jednego trudno nie dotknąć innych.

Na pierwszy rzut oka, najbardziej egzotyczną technologią może wydawać się OSGi, ale właśnie z rozwiązaniami typu Spring-DM, czy GlassFish jego rola sprowadza się do ukrytego gracza, który wspiera infrastrukturę, na której nasze aplikacje są budowane (Spring-DM) i/lub uruchamiane (GlassFish). Właśnie podział na budowane-uruchamiane daje odpowiedź, dlaczego Spring-DM (strona OSGi) ma tak silny związek z GlassFish (strona Java EE 6). I coś co wydaje się być różne i odległe od siebie jest faktycznie nierozerwalne (albo przynajmniej takim powinno być).

Stworzenie aplikacji springowej może być rozbudowane o cechy OSGi z pomocą Spring-DM, a środowiskiem uruchomieniowym może być właśnie GlassFish (który niestety poza wykorzystaniem OSGi wewnętrznie nie daje możliwości skorzystania z niego w ramach wdrażanych aplikacji korporacyjnych). Spring Framework to wyłącznie szkielet aplikacyjny, którego główną cechą jest realizacja podejścia (wzorca?) Inversion of Control przez mechanizm Depenency Injection, który potrzebuje środowiska uruchomieniowego z jego usługami. Serwer aplikacyjny Java EE świetnie uzupełnia ofertę Spring Framework przez dostarczenie wszystkich obowiązkowych usług typu monitor transakcyjny, zarządca utrwalania danych JPA czy infrastruktura bezpieczeństwa.

Jeszcze podczas lektury "Grails in Action" doświadczyłem niesamowitego olśnienia odnośnie różnicy między Inversion of Control (IoC) a Dependency Injection (DI), co zwykłem traktować jako synonimy. Jakież było moje zdumienie, kiedy przeczytałem, że IoC to podejście (wzorzec?) tworzenia aplikacji, gdzie zarządzanie zależnościami oddelegowuje się do kontenera IoC, a DI to jedna z jego realizacji, która polega na przekazywaniu/wstrzykiwaniu owych zależności do komponentu zarządzanego (strona 396). Niestety, nie jestem w stanie wskazać innej realizacji IoC, ale na takie przedstawienie tematu mogę się zgodzić. Niewielka różnica, która często "fall through the cracks" (piękny idiom w j. angielskim, którego nie mogłem nie użyć w ramach pogłębiania mojej znajomości angielskiego).

Sama książka "Pro Spring Dynamic Modules for OSGi Service Platforms" rozpoczyna się, tak jak prawdopodobnie zaczyna się każda książka na ten temat - najpierw wprowadzenie do OSGi, później Spring Framework, dalej Spring Dynamic Modules, aż lądujemy z SpringSource dm Server w jednej dłoni, a jego rozwiązaniami wokół wersjonowania składowych aplikacji, dostępem do danych, aplikacjami webowymi i testowaniem w drugiej. Na razie mam za sobą pierwszy rozdział książki "Introducing OSGi" i mimo jedynie 42 stron na ten temat, warto było. Tak jak można było się tego spodziewać, było tworzenie pakunku OSGi, ale czego nie, to próba zarejestrowania jego funkcjonalności jako usługi (tak, było też wymienione SOA, ale tylko przez chwilę) i udostępnienie jej jako servlet za pomocą HTTP Service. Nie ma wiele rozpisywania się nt. OSGi, ale jest wystarczająco, aby wprowadzić w temat, a sam przykład jest zdecydowanie bardziej zaawansowany niż jego nazwa mogłaby wskazywać - HelloWorld. Jestem niezwykle zadowolony z tego, że zdecydowałem się na tę książkę. Leżała u mnie od lutego (!) Jest to książka drukowana, więc zainteresowani będą musieli odczekać jeszcze kilka tygodni, kiedy wróci do Biblioteki Warszawskiego JUGa.

Przede mną wprowadzenie do Spring Framework przez 60 stron. Już przez głowę przeszło mi, aby przerzucić te strony i zabrać się za kolejny rozdział 3. "Integrating Spring and OSGi". Nie będzie mi łatwo przebrnąć przez niego. Już tyle zostało powiedziane o Springu, a tu jeszcze 60 stron przede mną. Dobrze, że po nim znowu OSGi, a w odwodzie jest testowanie GlassFisha z NetBeans IDE 6.7.1/6.8 i nauka Java EE 6.

29 marca 2008

Trochę lektury o JRuby on Rails z GlassFish i powrót do OSGi - rozdział 4.3 Obiekt Bundle

0 komentarzy
Przeczytałem wczoraj artykuł dotyczący JRuby on Rails z GlassFishem - Rails Powered by the GlassFish Application Server i tylko niepotrzebnie się rozgrzałem. Artykuł wyśmienicie przedstawił zalety zastosowania serwera aplikacji Java EE - GlassFish, aby udostępnić funkcjonalność niedostępną w typowych rozwiązaniach RoR bez wyrafinowanych "sztuczek" administracyjnych - klastrowanie, współdzielenie zasobów, prostsza administracja, w tym aktualizacja aplikacji, możliwość uruchomienia wielu aplikacji RoR na jednej instancji serwera Java EE. Co niestety mnie zmartwiło, to, że kiedy tylko już skończyłem "wstęp" i już nie mogłem doczekać się przykładu z wykorzystaniem usługi oferowanej przez GlassFisha, okazało się, że to, co postrzegałem jako "wstęp" faktycznie było całym artykułem! I po co mi to było?! Tylko się człowiek niepotrzebnie napalił. Nie zamierzam jeszcze rozpoznawać tematu samodzielnie, ale ciekawym czy ktoś z czytających ten wpis ma doświadczenie w tego typu instalacjach, gdzie korzysta się z serwera aplikacji Java EE (zapewne GlassFish jako gem) i korzysta z jego usług w aplikacji RoR. Może jest tak, że osoby z kręgu RoR nie widzą potrzeby zastosowania serwera aplikacji Java EE. Dlaczego? Może chociaż ktoś rozważa taką integrację? Kiedyś pewnie i samemu spróbuję, ale na razie zawieszam temat. Oczywiście artykuł warty uwagi, chociaż należy podejść ze swoimi oczekiwaniami bardzo skromnie. Uaktualniłem w międzyczasie JRuby i popróbowałem się z kilkoma poleceniami, ale zdecydowanie za mało dla wymagających. Na zakończenie artykułu pozwoliłem sobie na skomentowanie go i wysłanie uwag do autorów. Nieoczekiwanie już dzisiaj dostałem od jednego z autorów - Ricka Palkovica - odpowiedź:
 Thanks for your comments on our article "Rails Powered by the GlassFish Application Server."

As you noted, the article really focuses on the use of GlassFish for development and deployment
of JRuby applications, not on how to use JRuby. For information about JRuby on Rails and using
it with a Java code, you might want to read:

"JRuby and the Java Platform" by Monica Powlan
(http://java.sun.com/developer/technicalArticles/scripting/jruby/index.html)

or the JRuby tutorials at http://jruby.codehaus.org/Tutorials

If you're a NetBeans user, you also might want to look at
"How to Work with JRuby in the NetBeans IDE"
(http://wiki.netbeans.org/NetbeansedJRuby)

Also, check out Arun's blog, where he often gives examples with JRuby and NetBeans.
(http://blogs.sun.com/arungupta)
Also, his webcasts, for example "First JRuby App in GlassFish:
(http://download.java.net/javaee5/screencasts/jruby-in-glassfish/)

Hope this helps,
-- Rick
Pewnie, że "helps", ale nie chodziło zupełnie o samo użycie JRuby, ale raczej o jego integrację z Java EE 5, czyli stworzenie aplikacji w ten sposób, że jej część będzie bazowała na RoR, a część na Korporacyjnej Javie. Odkładam temat na (przysłowiowe) później.

Jakby tego było mało lektura Java is losing the battle for the modern Web. Can the JVM save the vendors? dała na zakończenie dużo do myślenia w kontekście przyszłego rozpoznawania tematu JRuby, Ruby on Rails i GlassFish. Nie zamierzam streszczać artykułu tutaj i zachęcam do jego lektury. Wydaje się, że komuś ta Java już się przejadła. Ciekawe czasy.

Po krótkiej przerwie, wracam do OSGi i jego atrakcji. Pod młotek pójdzie rozdział 4.3 o obiekcie Bundle.

Każdy pakunek reprezentowany jest w środowisku uruchomieniowym OSGi przez swojego "partnera" w postaci obiektu org.osgi.framework.Bundle, który posiada unikatowy identyfikator typu long przypisany przez Platformę OSGi. Identyfikator pakunku jest niezmienny przez cały cykl rozwojowy pakunku (wliczając w to wszelkie operacje związane z jego stanem, w tym i jego aktualizację oraz ponowne uruchomienie środowiska OSGi). Odinstalowanie pakunku i jego ponowna instalacja skutkuje utworzeniem nowego identyfikatora. Identyfikatory pakunków są przydzielane w rosnącym porządku. Zarządzanie pakunkiem odbywa się właśnie poprzez obiekt Bundle zazwyczaj przez dedykowany przez Platformę OSGi pakunek zarządczy (Management Agent).

Poza identyfikatorem pakunku wyróżnia się unikatowy identyfikator położenia pakunku w Systemie, który jest przypisywany podczas instalacji i zazwyczaj interpretowany jest jako URL do pliku jar zawierającego pakunek (podkreśla się słowo zazwyczaj, gdyż nie jest to wymagane). Podobnie jak z identyfikatorem pakunku identyfikator położenia nie zmienia się w trakcie cyklu rozwojowego pakunku.

Symboliczna nazwa pakunku (ang. bundle symbolic name) jest nazwą określaną przez dostawcę pakunku poprzez nagłówek Bundle-SymbolicName. Para {wersja pakunku, nazwa symboliczna pakunku} jest unikatowa w ramach Systemu OSGi.

Metoda Bundle.getBundleId() zwraca identyfikator pakunku.

Metoda Bundle.getLocation() zwraca identyfikator położenia pakunku w Systemie.

Metoda Bundle.getSymbolicName() zwraca symboliczną nazwę pakunku, jaką przypisano przez jego dostawcę.

Pakunek może znajdować się w 6 stanach:
  • INSTALLED - pakunek poprawnie zainstalowany w Systemie
  • RESOLVED - wszystkie klasy Java wymagane przez pakunek są dostępne; pakunek jest gotowy do uruchomienia lub właśnie został zatrzymany
  • STARTING - pakunek jest uruchamiany i wywołanie metody start() aktywatora (BundleActivator.start()) jeszcze nie zakończyło się; wykorzystanie polityki uruchomienia może spowodować wstrzymanie pakunku w tym stanie (więcej o tym niebawem)
  • ACTIVE - pakunek został uruchomiony; wykonanie metody start() aktywatora zakończyło się poprawnie
  • STOPPING - pakunek jest zatrzymywany i wywołanie metody stop() aktywatora (BundleActivator.stop()) nie zakończyło się jeszcze
  • UNINSTALLED - pakunek usunięto z Systemu, niemożliwa zmiana stanu
Pakunek powinien wykonywać swoją pracę wyłącznie w stanie STARTING, ACTIVE lub STOPPING. Pakunek w stanie UNINSTALLED nie może zmienić swojego stanu (wymagana jest ponowna instalacja, co w kontekście nowego identyfikatora powoduje, że dla systemu jest to całkowicie inny pakunek). Zmiana stanu jest utrwalana przez Szkielet OSGi aż do odinstalowania (usunięcia) pakunku.

Metoda Bundle.getState() zwraca aktualny stan pakunku.

Jedynie Szkielet OSGi może powoływać obiekty Bundle do życia, które istnieją wyłącznie w ramach Platformy OSGi, który je powołał.

I na koniec krótki przykład dla utrwalenia wiedzy. Różnica między tym przykładem, a poprzednimi leży w dodaniu kilku System.out.println.
 package pl.jaceklaskowski.osgi;

import java.util.logging.Logger;

import org.osgi.framework.Bundle;
import org.osgi.framework.BundleActivator;
import org.osgi.framework.BundleContext;

public class AktywatorPakunku implements BundleActivator {

Logger log = Logger.getLogger(AktywatorPakunku.class.getName());

public void start(BundleContext bundleContext) throws Exception {
log.info("start() wykonano - rozpoczynam pracę");
Bundle bundle = bundleContext.getBundle();
long bundleId = bundle.getBundleId();
String bundleLocation = bundle.getLocation();
String bundleSymbolicName = bundle.getSymbolicName();
System.out.println("------------------------------------");
System.out.println("Charakterystyka aktywowanego pakunku:");
System.out.println(" Identyfikator: " + bundleId);
System.out.println(" Identyfikator położenia: " + bundleLocation);
System.out.println(" Nazwa symboliczna: " + bundleSymbolicName);
System.out.println("------------------------------------");
}

public void stop(BundleContext bundleContext) throws Exception {
log.info("stop() wykonano - czyszczę po sobie");
}

}
Polecenia są identyczne, za wyjątkiem wykonania aktualizacji po tym jak zmieniłem wcięcie w System.out.println.
 jlaskowski@dev /cygdrive/c/apps/felix
$ java -jar bin/felix.jar

Welcome to Felix.
=================

Enter profile name: notatnik

DEBUG: WIRE: 1.0 -> org.osgi.service.packageadmin -> 0
DEBUG: WIRE: 1.0 -> org.osgi.service.startlevel -> 0
DEBUG: WIRE: 1.0 -> org.ungoverned.osgi.service.shell -> 1.0
DEBUG: WIRE: 1.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 1.0 -> org.apache.felix.shell -> 1.0
DEBUG: WIRE: 2.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 2.0 -> org.apache.felix.shell -> 1.0
DEBUG: WIRE: 3.0 -> org.osgi.service.obr -> 3.0
DEBUG: WIRE: 3.0 -> org.osgi.framework -> 0
-> DEBUG: WIRE: 3.0 -> org.apache.felix.shell -> 1.0
ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.3)
[ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.0.2)
-> install file:c:/projs/osgi/spring-osgi-lifecycle/target/spring-osgi-lifecycle-1.0.jar
Bundle ID: 4
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.3)
[ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.0.2)
[ 4] [Installed ] [ 1] Spring OSGi Bundle (1.0)
-> start 4
DEBUG: WIRE: 4.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 4.0 -> pl.jaceklaskowski.osgi.impl -> 4.0
DEBUG: WIRE: 4.0 -> pl.jaceklaskowski.osgi -> 4.0
2008-03-27 13:21:03 pl.jaceklaskowski.osgi.AktywatorPakunku start
INFO: start() wykonano - rozpoczynam pracę
------------------------------------
Charakterystyka aktywowanego pakunku:
Identyfikator: 4
Identyfikator położenia: file:c:/projs/osgi/spring-osgi-lifecycle/target/spring-osgi-lifecycle-1.0.jar
Nazwa symboliczna: pl.jaceklaskowski.osgi.spring-osgi-lifecycle
------------------------------------
-> ps
START LEVEL 1
ID State Level Name
[ 0] [Active ] [ 0] System Bundle (1.0.3)
[ 1] [Active ] [ 1] Apache Felix Shell Service (1.0.0)
[ 2] [Active ] [ 1] Apache Felix Shell TUI (1.0.0)
[ 3] [Active ] [ 1] Apache Felix Bundle Repository (1.0.2)
[ 4] [Active ] [ 1] Spring OSGi Bundle (1.0)
-> stop 4
2008-03-27 13:21:51 pl.jaceklaskowski.osgi.AktywatorPakunku stop
INFO: stop() wykonano - czyszczŕ po sobie
-> start 4
2008-03-27 13:22:03 pl.jaceklaskowski.osgi.AktywatorPakunku start
INFO: start() wykonano - rozpoczynam pracŕ
------------------------------------
Charakterystyka aktywowanego pakunku:
Identyfikator: 4
Identyfikator po-o¬enia: file:c:/projs/osgi/spring-osgi-lifecycle/target/spring-osgi-lifecycle-1.0.jar
Nazwa symboliczna: pl.jaceklaskowski.osgi.spring-osgi-lifecycle
------------------------------------
Tutaj następuje aktualizacja pakunku i sprawdzenie, czy wszystkie identyfikatory są jak poprzednio.
 -> update 4 file:c:/projs/osgi/spring-osgi-lifecycle/target/spring-osgi-lifecycle-1.0.jar
2008-03-27 13:22:50 pl.jaceklaskowski.osgi.AktywatorPakunku stop
INFO: stop() wykonano - czyszczę po sobie
DEBUG: WIRE: 4.0 -> org.osgi.framework -> 0
DEBUG: WIRE: 4.0 -> pl.jaceklaskowski.osgi.impl -> 4.0
DEBUG: WIRE: 4.0 -> pl.jaceklaskowski.osgi -> 4.0
2008-03-27 13:22:50 pl.jaceklaskowski.osgi.AktywatorPakunku start
INFO: start() wykonano - rozpoczynam pracŕ
------------------------------------
Charakterystyka aktywowanego pakunku:
Identyfikator: 4
Identyfikator położenia: file:c:/projs/osgi/spring-osgi-lifecycle/target/spring-osgi-lifecycle-1.0.jar
Nazwa symboliczna: pl.jaceklaskowski.osgi.spring-osgi-lifecycle
------------------------------------
-> shutdown
-> 2008-03-27 13:23:05 pl.jaceklaskowski.osgi.AktywatorPakunku stop
INFO: stop() wykonano - czyszczę po sobie
Pytanie dla wytrwałych: Ile stanów jest w cyklu rozwojowym pakunku? oraz trochę trudniejsze - Jakie stany wyróżnia specyfikacja OSGi w cyklu rozwojowym pakunku? Nagród nie przewiduje się.

10 października 2007

Artykuł o EJB3, Glassfish, Maven2 i NetBeans 6 na netbeans.org

6 komentarzy
Nie mogłem wymarzyć sobie lepszej nagrody w zamian za napisanie artykułu Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0 niż opublikowanie go na pierwszej stronie netbeans.org (!) Jakiś czas temu osoby z zespołu NetBeans zapytały mnie o zgodę na przetłumaczenie artykułu i jego publikację. Nie zastanawiałem się długo, bo i dlaczego miałbym?! Po kilku dniach i drobnych problemach w tłumaczeniu mojego pokrętnego toku myślenia udało się i artykuł znalazł się na netbeans.org. Zainteresowanych wersją angielską zapraszam na Building an EJB 3.0 application using GlassFish v2, Apache Maven 2 and NetBeans IDE 6.0. Pozdrowienia dla załogi NetBeans.

04 października 2007

Kwadrans w Bibliotece z JSF 1.2, EJB 3.0 i JPA

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

19 września 2007

NetBeans IDE 6.0 Beta 1 oraz GlassFish V2 dostępne, ale czy gotowe?

0 komentarzy
Właśnie pojawiła się nowa wersja beta środowiska programistycznego NetBeans IDE 6.0 Beta 1. Rozpoczął się tym samym program NetCAT 6.0 (NetBeans IDE 6.0 Community Acceptance Testing), w którym zdeklarowałem zweryfikować poprawność działania kolejnych kandydatów na finalną wersję NetBeans IDE 6.0 w obszarach j2ee oraz web services (Participants of NetCAT 6.0 program). Jak się później okazało w wersji Beta 1 jest kilka błędów, które dyskwalifikują ją i konieczne jest pobranie wersji następnej, rozwojowej.

Zabawę czas zacząć!

Rozpocznę od stworzenia bardzo prymitywnej aplikacji Java EE 5 z wykorzystaniem jak najmniejszej liczby kroków, a tym bardziej uderzeń w klawiaturę (coś na wzór poprzedniego testu, którego wynikiem był artykuł - Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0).

Tym razem zbuduję bezstanowe ziarno sesyjne EJB, które udostępnia wyłącznie interfejs usługi sieciowej (WS) oraz klienta korzystającego z niej (jakiż inny mógłbym wybrać przykład łączący EJB3 (obecne zainteresowanie) z Web Services w ramach NetBeans IDE 6 tak, aby kontynuować poznawanie EJB3 i sprawdzić działanie NetBeans IDE?!)

Przez serwer rozumiem serwer aplikacyjny zgodny ze specyfikacją Korporacyjnej Javy 5 (Java EE 5).
Przez aplikację korporacyjną rozumiem aplikację tworzoną przy wykorzystaniu elementów Korporacyjnej Javy.

Definiuję nowy serwer, który będzie wymagany przy tworzeniu aplikacji korporacyjnej. Jak miało to miejsce poprzednio wybieram GlassFish'a (ech, jak mi się marzy przedstawienie Apache Geronimo 2.0.1 z wtyczką dla NetBeans IDE 6.0, ale to jeszcze musi trochę poczekać). Serwer pobieram w ramach paczki dystrybucyjnej NetBeans IDE 6.0 Beta 1 bądź jako osobny projekt ze strony GlassFish Project - V2 Final Build (aka b58g Promoted Build). Instrukcje tworzenia nowego serwera można znaleźć we wspomnianym wcześniej artykule.


Zaczynam od stworzenia projektu ziarna - MojPierwszyWsEJB - menu Enterprise > EJB Module, wskazuję na serwer GlassFish (jeśli jest jedynym serwerem to będzie automatycznie wybrany) i zatwierdzam formatkę definiowania projektu.

Tworzę nowy pakiet (menu New > Java Package) - pl.jaceklaskowski.ejbws.

W menu kontekstowym nowego pakietu wybieram New > Session Bean... podaję EJB Name jako MojPierwszyWsEJB i zatwierdzam formatkę.

Jakkolwiek zgodnie z komentarzem w klasie ziarna możnaby skorzystać z menu kontekstowego Web Service > Add Operation to faktycznie takie menu nie istnieje. Zgłosiłem błąd [60cat] No Web Service > Add Operation menu yet the comment in EJB points to it.

Wybieramy Add Business Method i definiujemy bezparametrową metodą metodaBiznesowa. Ostatecznie ziarno wygląda następująco:

package pl.jaceklaskowski.ejbws;

import java.util.logging.Logger;
import javax.ejb.Stateless;

@Stateless
public class MojPierwszyWsEJBBean implements MojPierwszyWsEJBLocal {

Logger logger = Logger.getLogger(MojPierwszyWsEJBBean.class.toString());

public void metodaBiznesowa() {
logger.info("Metoda biznesowa metodaBiznesowa wywołana poprawnie");
}
}

gdzie lokalny interfejs biznesowy wygląda tak:

package pl.jaceklaskowski.ejbws;

import javax.ejb.Local;

@Local
public interface MojPierwszyWsEJBLocal {

void metodaBiznesowa();

}

New > Web Service... z domyślną nazwą NewWebService, w pakiecie pl.jaceklaskowski.ejbws (pole Package) i wybieram opcję Delegate to Existing Session Enterprise Bean ze wskazaniem na wcześniej stworzone ziarno. Finish. Niestety, w tym momencie pojawi się NPE, który zgłosiłem jako [60cat] NPE upon finishing New > Web Service in EJB project. Zamykam okno z komunikatem błędu (przycisk Close). Po pewnym czasie wszystko wraca do normy, tj. pojawia się pozycja MojPierwszyWsEJBBean w węźle Enterprise Beans, chociaż nie potrafię odtworzyć ścieżki poleceń, aby do tego momentu dojść. Tak, czy owak, zamknięcie okna z błędem kończy temat do momentu kolejnego rozwinięcia węzła Enterprise Beans, czego nie planuję zrobić ponownie.

package pl.jaceklaskowski.ejbws;

import javax.ejb.EJB;
import javax.jws.Oneway;
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.ejb.Stateless;

@WebService
@Stateless
public class NewWebService {

@EJB
private MojPierwszyWsEJBLocal ejbRef;

@WebMethod(operationName = "metodaBiznesowa")
@Oneway
public void metodaBiznesowa() {
ejbRef.metodaBiznesowa();
}
}

Zanim wywołam usługę sieciową, instaluję paczkę EJB na serwerze przez wywołanie menu Run. Próba wcześniejszego uruchomienia usługi kończy się komunikatem o niedostępności usługi na serwerze.

Wybieram menu Test Web Service z menu kontekstowego węzła MojPierwszyWsEJB/Web Services/NewWebService.

Wciskam przycisk metodaBiznesowa, która spowoduje wywołanie metody metodaBiznesowa ziarna MojPierwszyWsEJB, o czym można się przekonać w dzienniku zdarzeń GlassFish'a:

Invoking wsimport with http://localhost:8080/NewWebServiceService/NewWebService?WSDL
wsimport successful
Metoda biznesowa metodaBiznesowa wywolana poprawnie

Pomijając 2 błędy znalezione w międzyczasie tworzenie usługi sieciowej na bazie ziarna EJB można uznać za zakończone. Ze względu na błędy zmuszony byłem do zainstalowania wersji rozwojowej NetBeans IDE 6.0 z dnia 18.09.2007 (uwaga: odnośnik wskazuje na ostatnią wersję NetBeans IDE 6.0, więc w trakcie czytania wersja może być już nowsza).

W międzyczasie natrafiłem na artykuł zbliżone do tematu opublikowany na stronach netbeans.org - Getting Started with JAX-WS Web Services in NetBeans IDE 6.0. Zresztą jest ich więcej, m.in. na stronie Web Application Learning Trail oraz Java EE Applications Learning Trail w sekcji NetBeans IDE 6.0 Beta Tutorials.

06 września 2007

Tworzenie aplikacji Java EE 5 z NetBeans IDE 6.0 i GlassFish v2

0 komentarzy
Poprzedni artykuł Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0 przedstawił proces tworzenia aplikacji EJB 3.0 z kilkoma narzędziami wspierającymi tworzenie oprogramowania zgodnego ze specyfikacją Korporacyjnej Javy (Java EE 5). Artykuł uzmysłowił mi potrzebę skrócenia czasu tworzenia aplikacji korporacyjnej do niezbędnego minimum. Postanowiłem iść dalej i spróbować stworzyć aplikację Java EE korzystając wyłącznie z pomocników (ang. wizards) dostarczanych przez NetBeans IDE 6.0. Jako aplikację do utworzenia wybrałem książkę telefoniczną bazując na przykładzie zaczerpniętym z dokumentacji serwera aplikacyjnego Apache Geronimo - Very simple Entity EJB example. Celem było zminimalizowanie koniecznych modyfikacji wykonywanych manualnie na rzecz wykorzystania możliwości środowiska graficznego NetBeans IDE 6.0 oraz technologiczne uatrakcyjnienie przykładu opisanego na wspomnianej stronie (co powinno zostać odzwierciedlone również na niej samej w kontekście użycia Apache Geronimo).

W takim klimacie przyszło mi napisać nowy artykuł Tworzenie aplikacji Java EE 5 z NetBeans IDE 6.0 i GlassFish v2, w którym krok po kroku przedstawiłem proces tworzenia aplikacji Java EE 5 z minimalnym użyciem klawiatury. Jest to pełna aplikacja korzystająca z JSF, EJB3 oraz JPA. Czekam na sugestię rozszerzenia przykładu. Dodatkowo mile widziane podpowiedzi jeszcze bardziej skrócające czas niezbędny do zbudowania aplikacji Java EE 5 z NetBeans IDE 6.0. Chętnie usłyszę o doświadczeniach z innymi IDE.

Pora na zestawienie podobnego 10-minutowego przykładu z Eclipse IDE 3.3 albo jakimś rozszerzeniem Eclipse'a, np. RedHat Developer Studio. Przykład z pewnością uruchomię na Apache Geronimo v2 z wtyczką Geronimo Eclipse Plugin.

03 września 2007

Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0

2 komentarzy
Podczas rozpracowywania tematu potencjalnego błędu w Apache OpenEJB postanowiłem rozpoznać możliwości zestawienia środowiska uruchomieniowego do przeprowadzenia testów z wykorzystaniem jakiegoś IDE oraz Apache Maven 2. Eclipse IDE z wtyczką do m2 nie wspierał projektów złożonych, tj. projekt macierzysty projektu wielomodułowego nie był możliwy do zarządzania z poziomu IDE, więc odpadł na starcie. Postanowiłem spróbować się z IntelliJ IDEA 7.0M2. Po kilku próbach z IntelliJ IDEA jego możliwości również nie przypadły mi do gustu - coś nie tak z zarządzaniem katalogami źródłowymi. Został mi NetBeans IDE 6.0, który mimo początkowej niechęci pamiętając możliwości jego wtyczki Mevenide-NetBeans, okazał się być najlepszym wyborem. A i elementy graficzne zmieniły się na lepsze.

Przemyślenia i poszczególne kroki w zestawieniu środowiska opisałem w artykule Tworzenie aplikacji EJB 3.0 z GlassFish v2, Apache Maven 2 i NetBeans IDE 6.0. Nie jest to doskonałe rozwiązanie, ale jego prostota (mimo pewnej niedoskonałości) bardzo mnie urzekła i postanowiłem je opisać. Na zakończenie artykułu zostawiłem pytanie do rozwiązania. Jeśli są osoby skłonne podzielić się ze mną potencjalnym rozwiązaniem zapraszam do kontaktu.

p.s. Dzięki uprzejmości Marcina Molaka mam możliwość dokończenia lektury artykułów w ostatnim wrześniowym Software Developer's Journal. Już nie mogę doczekać się, aby przeczytać o ASM i JBoss Seam.

10 lipca 2007

Krótka przygoda z ICEFaces 1.6.0, Eclipse 3.3 i wtyczką Glassfish Eclipse Plugin

1 komentarzy
Do niedawna sądziłem, że wsparcie Eclipse IDE przy tworzeniu aplikacji Java EE jest...delikatnie mówiąc...słabsze niż w NetBeans IDE. Co rusz natrafiam jednakże na funkcjonalność Eclipse IDE, które zmienia moje zdanie nt. temat. Pojawiła się właśnie nowa wersja biblioteki ICEfaces 1.6.0 i postanowiłem sprawdzić, ile czasu zajmie mi uruchomienie prostej aplikacji internetowej z nią korzystając z Eclipse IDE 3.3 oraz wtyczki Glassfish.

Rozpoczynam od pobrania ICEfaces 1.6.0 ze strony ICEfaces Downloads.

Początkowo próbowałem namierzyć biblioteki w repozytorium m2, ale nie miałem szczęścia i odpuściłem. Później jeszcze raz próbowałem z wtyczką m2eclipse po zainstalowaniu ICEfaces w lokalnym repozytorium m2, ale w połączeniu z Eclipse i wtyczką Glassfish nie szło mi najlepiej i również odpuściłem.

Otwieram Eclipse IDE 3.3 z zainstalowaną wtyczką dla Glassfish (pracuję z Glassfish v2 b54).

Tworzę dynamiczny projekt aplikacji internetowej (New > Project > Web > Dynamic Web Project) o nazwie icefaces-witajswiecie. W międzyczasie definiuję Glassfish oraz wybieram JavaServer Faces Project Facet


i deklaruję korzystanie z biblioteki JSF przez zaznaczenie opcji Server Supplied JSF Implementation.

Kończę tworzenie projektu przyciskiem Finish.

Jako pierwszy krok dodaję biblioteki wymagane przez projekt ICEfaces opisane w dokumencie ICEfaces Library Dependencies.

Tworzenie strony JSF w Eclipse IDE to tworzenie strony JSP - New > JSP. Eclipse nie dostarcza dedykowanego pomocnika (wizard) dla stron JSF.

Pierwszą stronę nazwałem index.jsp, która będzie przekierowywała na stronę zawierającą elementy ICEfaces.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd" >
<html>
<body>
<jsp:forward page="index.iface" />
</body>
</html>
A skąd to dziwne rozszerzenie - .iface? Jest to rozszerzenie, z którym domyślnie związuje się infrastrukturę JSF dostarczaną przez ICEfaces przez deklarację w deskryptorze aplikacji internetowej WEB-INF/web.xml.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="WebApp_ID" version="2.5">
<display-name>icefaces-witajswiecie</display-name>
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>server</param-value>
</context-param>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.iface</param-value>
</context-param>
<context-param>
<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
<param-value>.jspx</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.synchronousUpdate</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.icesoft.faces.concurrentDOMViews</param-name>
<param-value>true</param-value>
</context-param>
<context-param>
<param-name>com.sun.faces.validateXml</param-name>
<param-value>true</param-value>
</context-param>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>Persistent Faces Servlet</servlet-name>
<servlet-class>com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet>
<servlet-name>Blocking Servlet</servlet-name>
<servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>*.iface</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>/xmlhttp/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Blocking Servlet</servlet-name>
<url-pattern>/block/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>
</web-app>
W deskryptorze aplikacji internetowej zauważyć można definicję kilku dodatkowych servletów, które uaktywniają ICEfaces. ICEfaces jest rozszerzeniem dla JSF (siłą JSF jest właśnie mechanizm umożliwiający jego rozbudowę z czego skorzystał nie tylko ICEfaces, ale również JBoss Seam, RichFaces, MyFaces i wiele innych bibliotek komponentów czy środowisk JSF). Koniecznie należy zarejestrować PersistentFacesServlet (wersja ICEfaces standardowego servletu FacesServlet) oraz BlockingServlet do obsługi asynchronicznych wywołań.

Kolejna strona - index.jspx - jest główną stroną aplikacji.

<?xml version="1.0" encoding="UTF-8"?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html" xmlns:ice="http://www.icesoft.com/icefaces/component" version="2.0">
<jsp:directive.page language="java" contentType="text/html;charset=UTF-8" pageEncoding="UTF-8" />
<f:view>
<html>
<head>
<title>Witaj ICEfaces</title>
</head>
<body>
<h3>Witaj ICEfaces</h3>
<p>Wciśnij przycisk poniżej i obserwuj ikonę stanu w przeglądarce oraz dziennik zdarzeń serwera aplikacyjnego.</p>
<ice:form partialSubmit="true">
<h:commandButton value="Wciśnij mnie" actionListener="#{ranking.zaglosuj}" />
</ice:form>
</body>
</html>
</f:view>
</jsp:root>
Baczne oko zauważy, że cały plik jest dobrze zbudowanym plikiem XHTML, stąd rozszerzenie jspx (domyślne dla dokumentów JSP, które są poprawnymi dokumentami XML). Jest to wymaganie ICEfaces, które nakłada na aplikację tworzenie stron JSP jako poprawnie zbudowanych dokumentów XML.

Strona index.jspx zawiera znaczniki ICEfaces rozpoczynające się nazwą ice.

Ciekawostką Eclipse IDE 3.3 z wtyczką Eclipse WTP 2.0.0 jest mechanizm podpowiedzi dla stron JSF.


Strona index.jspx wykorzystuje zarządzane ziarno JSF ranking. Definicja ziarna odbywa się w pliku faces-config.xml.

<?xml version="1.0" encoding="UTF-8"?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
version="1.2">
<managed-bean>
<managed-bean-name>ranking</managed-bean-name>
<managed-bean-class>pl.jaceklaskowski.icefaces.ranking.beans.Ranking</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
</faces-config>

Podczas edycji deskryptora aplikacji JSF - faces-config.xml - ujawniła się kolejna ciekawa funkcjonalność Eclipse IDE (a właściwie wtyczki Eclipse WTP 2.0.0) - graficzny edytor faces-config.xml.

Edytor posiada wiele widoków podłączonych do zakładek (u dołu zrzutu ekranu powyżej) i jest ciekawym i darmowym dodatkiem podczas tworzenia aplikacji JSF. Jak na kilka chwil z nim przyznaję, że zrobił na mnie pozytywne wrażenie.

Na koniec pozostaje przedstawić zarządzane ziarno JSF - ranking - reprezentowane przez klasę pl.jaceklaskowski.icefaces.ranking.beans.Ranking.

package pl.jaceklaskowski.icefaces.ranking.beans;

import javax.faces.event.ActionEvent;

public class Ranking {
public void zaglosuj(ActionEvent event){
System.out.println("oddano glos");
}
}
Mając wszystko zdefiniowane i gotowe do uruchomienia uruchamiamy aplikację wybierając menu Run As > Run on Server.

Poprawne uruchomienie Glassfisha i samej aplikacji wiąże się z wypisaniem wersji ICEfaces w dzienniku zdarzeń Glassfisha.

[#|2007-07-10T22:09:43.409+0200|INFO|sun-appserver9.1|com.icesoft.faces.application.D2DViewHandler|
_ThreadID=17;_ThreadName=httpWorkerThread-4848-1;|
ICEsoft Technologies, Inc.
ICEfaces 1.6.0
Build number: 15
Revision: 14409
|#]

A otworzenie strony pod adresem http://localhost:8080/icefaces-witajswiecie wita nas w następujący sposób.

Wciskając przycisk Wciśnij mnie można zauważyć, że ikona stanu przeglądarki niedrgnie, natomiast w dzienniku zdarzeń Glassfisha pojawi się następujący wpis:

[#|2007-07-10T22:11:05.049+0200|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|
_ThreadID=24;_ThreadName=httpSSLWorkerThread-8080-1;|oddano glos|#]

Nie jest to wyrafinowana aplikacja JSF z użyciem ICEfaces, ale pozwala na dobry start przy tworzeniu kolejnych bardziej złożonych aplikacji w Eclipse IDE i Glassfish. Warto rozważyć wykorzystanie ICEfaces we własnych projektach korzystających z JSF, gdyż ICEfaces 1.6.0 jest zintegrowane z JBoss Seam 2.0.0.BETA (dostępny po zbudowaniu ze źródeł) oraz wspiera inne biblioteki jak chociażby facelets. Dodatkowo, podobnie jak JBoss Seam, ICEfaces wspiera koncepcję równoległego przetwarzania DOM, a to pozwala na uruchomienie wielu okien i zakładek przeglądarki do pracy z tą samą aplikacją.

Cały projekt dostępny jest jako icefaces-witajswiecie.zip. Wystarczy rozpakować w wybranym miejscu na dysku, zaimportować w Eclipse IDE i uruchomić. Uwag nie zgłaszać autorowi ;-)

01 czerwca 2007

Mój prezent z okazji święta - Aplikacja korporacyjna z JPA w trybie JTA z GlassFish i PostgreSQL

8 komentarzy
A co! Każdemu należy się prezent z okazji święta Dnia Dziecka bez względu na wiek, więc moim prezentem jest spisanie moich przemyśleń nt. tworzeniu aplikacji korporacyjnej z JPA w trybie JTA z GlassFish i PostgreSQL w postaci artykułu Aplikacja korporacyjna z JPA w trybie JTA z GlassFish i PostgreSQL. Jest tam również użycie mechanizmu DataModel wspierającego działanie h:dataTable w JSF, więc dużo dobrego do analizy.

Po powrocie z Ukrainy, gdzie miałem możliwość spotkać się z wykładowcami Kijowskiej Politechniki i w wolnych chwilach podczas przelotów naczytałem się i postanowiłem popróbować się z konfiguracją JPA z transaction-type="JTA" oraz PostgreSQL. W zasadzie to zależało mi na utworzeniu aplikacji, która byłaby przyczółkiem dla utworzenia bardziej zaawansowanej aplikacji korporacyjnej, dzięki której będę mógł rozpocząć poznawać szczegóły specyfikacji Java EE. W kolejnych odsłonach aplikacji będzie można oczekiwać kolejnych usprawnień, jak wykorzystanie komponentu sesyjnego EJB 3.0 jako fasady dla encji i zniwelowania konieczności użycia mechanizmów obsługi transakcji bezpośrednio w kodzie komponentu zarządzanego JSF. Chciałbym uniezależnić się również o środowiska programistycznego IDE, czyli pojawiłby się również Apache Maven 2 czy alternatywni dostawcy JPA. Pora rozpocząć podsumowanie wiedzy odnośnie EJB 3.0 i JPA 1.0 i wreszcie zaspokoić swoje ego certyfikatem Sun Certified Business Component Developer (SCBCD) 5.0. Pamiętam ile mogłem nauczyć się podczas egzaminu SCJP 5 i jak wiele wyszło braków. Sądzę, że SCBCD może spełnić podobną funkcję - pogłębienie wiedzy odnośnie specyfikacji. Jeśli przy tym zdobędę certyfikat, to i dobrze (jest on potrzebny do podejścia do Sun Certified Enterprise Architect (SCEA), a o tym to jeszcze nawet nie myślałem, więc z SCBCD mogłoby być ciekawie. Przy okazji, czy ktoś z czytających rozważa SCEA, albo już posiada to cudeńko?).

Nie mógłbym nie wspomnieć o innej przyczynie spisania przemyśleń odnośnie wykorzystania usług serwera aplikacyjnego Java EE 5. Kilka dni temu otrzymałem list od Piotra Kochańskiego, który zwrócił mi uwagę na pewien niuans w wykorzystaniu JPA i mechanizmu wstrzeliwania zależności. Chodzi o wykorzystanie adnotacji @PersistenceUnit i @PersistenceContext. W zasadzie obie dotyczą tej samej funkcjonalności (tak w wielkim skrócie), ale pierwszy z nich jest stosowany dla przekazania referencji do fabryki PU podczas, gdy drugi jest przekazaniem kontekstu PU. I kiedy dopiszę, że pierwszy jest odporny na wielowątkowość, a drugi nie i że użycie drugiego było w servlecie wszystko powinno być jasne - moja aplikacja nie była odporna na wielowątkowość (!) W dodatku sam o tym niedawno wspominałem w kontekście komponentów zarządzanych JSF, które działają w zasięgu (ang. scope) session oraz application, więc z wielkim zadowoleniem przyjąłem uwagę Piotra. Jakby jeszcze było mało, właśnie dzisiaj natrafiłem na ciekawą wzmiankę o tym w artykule Using Java Persistence with JavaServer Faces Technology. Podsumowaniem mogłoby być stwierdzenie, że z prostotą w Java EE 5 idzie również większa odpowiedzialność i jest to przykład czułego miejsca w naszych aplikacjach korzystających z Korporacyjnej 5-tki. Wielkie dzięki Piotr za wychwycenie błędu! Jak zauważyłem, Piotr również spisuje swoje doświadczenia na stronie Xoft.pl, więc może odwdzięczę mu się tym samym?! ;-)

Wracając do artykułu to wspomnę, że natrafiłem na kilka miejsc, których nie miałem świadomości istnienia.

Jednym z nich był mechanizm DI w przypadku komponentu zarządzanego JSF z serwera aplikacyjnego (adnotacja @PersistenceContext) oraz samego środowiska JSF - plik faces-config.xml. Jeśli w konstruktorze korzystamy z obu elementów to z oczywistych względów DI z serwera nie będzie jeszcze wykonane i możemy być zaskoczeni nieprzyjemnym NullPointerException. Więcej o tym w kolejnych notatkach albo nawet i artykule.

Inną kwestią, która mnie zaskoczyła, było wykorzystanie JPA z JTA i uruchomienie EntityManager.merge po wywołaniu EntityManager.getTransaction. Jest to niemożliwe w konfiguracji JTA i kończy się wyjątkiem Exception Description: Cannot use an EntityTransaction while using JTA. W zasadzie jest to bardzo logiczne, że to monitor transakcyjny serwera aplikacyjnego Java EE zarządza transakcjami, ale możnaby oczekiwać, że...zostawiam dywagacje na później.

I na koniec coś, co oczekuje właściwego nagłośnienia, ale przy święcie nie mógłbym o tym nie wspomnieć - JAVArsovia. Grupa Warszawa JUG przygotowuje się do swojego debiutu jako organizator pierwszej konferencji-warsztatów technologii Java, która odbędzie się na Wydziale MIMUW. Więcej w kolejnej notatce...niebawem. Czas pozbierać wszystkie dane i rozpocząć promocję imprezki. Chciałbym, aby podsumowaniem sobotniej konferencji JAVArsovia był toast na Polach Mokotowskich, ale jak będzie zobaczymy. Prelegenci są, sala jest, chętni również, więc poza plakatem i promocją na forach jest wszystko. Dobrze byłoby rozpoczać promocję właśnie dzisiaj - 1 czerwca 2007. Jeszcze jest kilka godzin ;-)