29 grudnia 2006

JBoss Seam z GlassFish - cóż za bezproblemowe uruchomienie!

0 komentarzy
Świętując opublikowanie artykułu o Eclipse IDE i GlassFish - Tworzenie aplikacji Java EE 5 z Eclipse IDE i GlassFish przypominałem sobie o JBoss Seam. Pamiętam, że obiecywałem sobie kilkakrotnie, że sprawdzę co ma do zaoferowania, szczególnie, kiedy dowiedziałem się, że istnieje możliwość uruchomienia kilku przykładów na GlassFish. Na chwilę przed pójściem spać, zdecydowałem się uruchomić przykład jboss-seam-glassfish.ear. Skoro tyle się pisze o możliwościach Seama, nie sposób było oprzec się pokusie zobaczenia tego na własne oczy. A okazało się niezwykle proste, łatwe i przyjemne. Kilka poleceń i aplikacja uruchomiona.
  1. Rozpoczynamy instalując JBoss Seam 1.1.0 GA i budując przykładową aplikację, która znajduje się w katalogu examples/glassfish. Zbudowanie aplikacji to wykonanie polecenia ant.
    C:\apps\jboss-seam-1.1.0.GA\examples\glassfish>ant
    Buildfile: build.xml

    compile:
    [mkdir] Created dir: C:\apps\jboss-seam-1.1.0.GA\examples\glassfish\build\classes
    [javac] Compiling 23 source files to C:\apps\jboss-seam-1.1.0.GA\examples\glassfish\build\classes
    [javac] Note: Some input files use unchecked or unsafe operations.
    [javac] Note: Recompile with -Xlint:unchecked for details.

    ejb3jar:
    [jar] Building jar: C:\apps\jboss-seam-1.1.0.GA\examples\glassfish\build\jboss-seam-glassfish.jar

    war:
    [war] Building war: C:\apps\jboss-seam-1.1.0.GA\examples\glassfish\build\jboss-seam-glassfish.war

    ear:
    [ear] Building ear: C:\apps\jboss-seam-1.1.0.GA\examples\glassfish\build\jboss-seam-glassfish.ear

    main:

    BUILD SUCCESSFUL
    Total time: 4 seconds
  2. Uruchamiamy GlassFish i bazę danych dostarczaną razem z nim.
    asadmin start-database

    asadmin start-domain domain1
  3. Przystępujemy do instalacji aplikacji wykonując polecenie
    asadmin deploy --host localhost --port 4848 jboss-seam-glassfish.ear
  4. Uruchomienie aplikacji to otwarcie strony http://localhost:8080/jboss-seam-glassfish.

Wiele opisów jakie zawarte są w aplikacji znacznie upraszcza zrozumienie działania JBoss Seam. Krok po kroku wyjaśnione są aspekty Seam - annotacje, konwersacje, itp. Samo rozumienie działania EJB3 i JSF przyczynia się do tego jeszcze bardziej. Z pewnością warto zerknąć na aplikację w trakcie nauki Java EE 5. Dla mnie było warto. Miłego Seamowania!

28 grudnia 2006

Tworzenie aplikacji Java EE 5 z Eclipse IDE i GlassFish

8 komentarzy
Rozczytując się w specyfikacji JSR 220: Enterprise JavaBeans 3.0, a szczególnie w jej wersji uproszczonej (EJB 3.0 Simplified) postanowiłem sprawdzić, co do zaoferowania ma Eclipse IDE. Do tej pory do tworzenia oprogramowania korzystając z Java EE 5 jako zintegrowane środowisko programistyczne (ang. IDE - integrated development environment) zawsze wybierałem NetBeans IDE 5.5 ze względu na jego zaawansowanie we wsparciu dla tej specyfikacji (bądź służbowo IBM Rational Application Developer V7.0). Skoro wymagania Java EE 5 znacznie zmalały, tj. komponenty EJB mogą być (i zazwyczaj są) dystrybuowane jako pliki jar bez dodatkowych elementów (np. /META-INF/ejb-jar.xml) zmieniają się nasze wymagania dla zintegrowanych środowisk programistycznych. Nadeszła pora, aby sprawdzić, co można stworzyć w Java EE 5 korzystając z Eclipse IDE 3.3 i GlassFish v2.

Nie było lekko. Najwięcej czasu zajęło mi zestawienie działającego środowiska - Eclipse i wtyczki. Okazało się w międzyczasie, że nawet najnowsza wersja GlassFish'a ma swoje niedogodności, więc po 2 dniach ciężkich bojów udało mi się w końcu nie tylko zestawić środowisko, ale również opisać je w moim kolejnym artykule - Tworzenie aplikacji Java EE 5 z Eclipse IDE i GlassFish.

Chętnych zapraszam do lektury (i zgłaszania niedociągnięć, jeśli takie się pojawią).

Wracam tym samym do lektury specyfikacji EJB3 Simplified. Udało mi się, w międzyczasie, przeczytać kolejne 3 rozdziały o komponentach sesyjnych i sterowanych komunikatami, jednakże walka z Eclipse nie pozwoliła mi opisać moich wrażeń. W zasadzie nie ma nic nowego, o czym nie pisałbym poprzednio, więc wiele informacji powtórzyłoby się. Teraz, kiedy ujarzmiłem Eclipse czuję, że i najwyższa pora zakończyć lekturę specyfikacji w jej uproszczonej postaci. Najwyższa pora zabrać się za prawdziwy hard-core - EJB Core Contracts and Requirements! ;-)

26 grudnia 2006

Dokończenie rozdziału 3 specyfikacji EJB3 - 3.4 Interceptors

1 komentarzy
Temat interceptorów pozostawiłem sobie na powrót do Warszawy z wyjazdu wigilijnego do rodziny. Wigilia się skończyła, niedługo sylwester. Czas zabawy, więc korzystając z trzeźwego spojrzenia, rozczytuję się w specyfikacji EJB3. Na dziś przypadło mi doczytanie sekcji 3.4 Interceptors.

Termin interceptor pojawia się po raz pierwszy w specyfikacji EJB właśnie w wydaniu 3. Nie jest to jednak pojęcie nowe w świecie programowania. Idea interceptorów została zapożyczona z podejścia programistycznego opartego o aspekty z Aspect-Oriented Programming (AOP). Nie chciałbym rozpisywać się o aspektach, które same w sobie wymagałyby osobnej pozycji w moim dzienniku, ale zrozumienie aspektów to zrozumienie interceptorów, więc kilka słów znacznie pomoże w temacie. Po więcej informacji zapraszam do lektury The AspectJ 5 Development Kit Developer's Notebook.

Aspekt jest pewną funkcjonalnością, która niekoniecznie związana jest z działaniem biznesowym aplikacji. Modelowanie aplikacji oparte o aspekty wprowadza dodatkowy element modularyzacji dostarczając zestaw rozszerzeń (coś na kształt wtyczek) do podstawowej wersji aplikacji. Najczęstszymi przykładami aspektów są funkcjonalności rozbudowujące aplikację (a raczej jej funkcje biznesowe) o funkcje audytowe (ang. logging), bezpieczeństwo, czy obsługę transakcji. Jakkolwiek dwa ostatnie są dostarczane przez serwer aplikacyjny to pierwszy z nich - funkcje audytu - nie istnieje (lub innymi słowy, nie jest częścią specyfikacji Java EE, a jedynie serwera aplikacyjnego, stąd specyficzne dla niego i potraktowane przeze mnie jako nieistniejące).

Po lekturze rozdziału 3.4 Interceptors interceptory wydają się być dla mnie okrojonymi aspektami, tj. możliwości aspektów w dojrzałych szkieletach programistycznych AOP (np. AspectJ) znacznie przewyższają możliwości interceptorów w EJB3.

Czym zatem jest interceptor w sensie specyfikacji EJB3?

Interceptor jest metodą, która przechwytuje wywołanie metody biznesowej (metody z interfejsu biznesowego) lub zdarzenia zwrotnego związanego z etapem życia komponentu (bardzo podobne do nasłuchiwaczy - ang. listeners). Interceptor może być zdefiniowany na klasie komponentu bądź we własnej, dedykowanej klasie interceptora związanej z komponentem. Klasa interceptora to klasa zawierająca interceptory. Zabronione jest, aby klasa interceptora była jednocześnie komponentem EJB. Pojęcie interceptorów związane jest wyłącznie z komponentami sesyjnymi i sterowanymi komunikatami, i nie występuje dla komponentów encyjnych. Istnieje możliwość zdefiniowania interceptora metod biznesowych do wszystkich metod biznesowych komponentu bądź dla dowolnego ich podzbioru.

Klasa interceptora związana jest z klasą komponentu EJB za pomocą annotacji @Interceptors lub w deskryptorze instalacji - ejb-jar.xml. Pojawia się pojęcie domyślnych interceptorów, czyli interceptorów, które związane są ze wszystkimi komponentami sesyjnymi i sterowanych komunikatami zdefiniowanymi w deskryptorze instalacji wraz z definicją samych interceptorów. Brzmi bardzo zagmatwanie i oznaczyłem do dalszego sprawdzenia.

Nie ma ograniczenia dla liczby interceptorów zdefiniowanych dla pojedyńczej klasy komponentu EJB. Kolejność wykonywania interceptorów wyznaczana jest przez kolejność ich deklaracji w klasie komponentu i deskryptorze instalacji (jak ostatecznie tworzona jest kolejność pozostaje do sprawdzenia, choć wydaje się, że najpierw te zadeklarowane przez annotacje, a później przez deskryptor instalacji - choć może...ech..zostawiam to na później). Kolejność wykonywania jest o tyle istotna, że mimo, że interceptory są bezstanowe, to mają one dostęp do zasobów środowiska serwera, do których dostęp ma komponent EJB, więc i drzewa JNDI, w którym możnaby umieszczać informacje (ot, taki niezalecany efekt poboczny - ang. side-effect - wykonania bezstanowego interceptora). Poza tym istnieje również InvocationContext, o którym za moment, a który może służyć do komunikacji między interceptorami.

Klasa interceptora musi posiadać publiczny bezargumentowy konstruktor (dla przypomnienia: kompilator dostarcza go, jeśli nie istnieje żaden inny konstruktor w klasie, więc sprawa bardzo się upraszcza, jesli tylko sami nie będziemy chcieli jej skomplikować ;-)).

Następnie sekcja 3.4 przechodzi do omówienia zasad związanych z interceptorami (jakby tych już wspomnianych było mało). Mowa jest o kontekstach transakcyjnym i bezpieczeństwa, które są identyczne z tymi aktualnie związanymi z wywoływaną metodą biznesową, dla której one są wywoływane, wyjątkach identycznych z tymi zadeklarowanymi w metodach biznesowych, możliwością wywołania innych usług dostępnych dla komponentu EJB, wsparciu dla wstrzeliwania zależności i ostatecznie kończy się na ograniczeniach interceptorów, które są identyczne z ograniczeniami komponentów EJB. Innymi słowy można traktować interceptory jako metody biznesowe komponentu EJB, dla którego zostały zdefiniowane, z tym, że wywoływane są wcześniej, dodatkowo do wywołania metody biznesowej komponentu.

Dalej rozdział przechodzi do prezentacji 2 rodzajów interceptorów:
  • interceptor zdarzenia zwrotnego związanego z etapem życia komponentu (w skrócie interceptor zwrotny) (ang. lifecycle callback interceptor)
  • interceptor metody biznesowej (ang. business method interceptor)
Pierwszy z nich - interceptor zwrotny - jest definiowany przez annotacje @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate bądź deskryptor instalacji i może być metodą klasy komponentu EJB bądź klasą interceptora. Różnica polega na sygnaturze metody reprezentującej interceptor i w przypadku klasy komponentu EJB sygnatura wygląda następująco:

void <NazwaMetody>()

, a dla dedykowanej klasy interceptora jest:

void <NazwaMetody>(InvocationContext)

Metody mogą być dowolnej widoczności (public, protected, private, domyślny). Niedopuszczalne jest deklaracja interceptora zwrotnego jako final lub static (przypomniam, że interceptor to metoda instancji w Javie).

Te same annotacje opisujące interceptor zwrotny (dalej zwane zwrotnymi) są stosowane w klasie komponentu EJB i klasie interceptora (za pomocą annotacji @PostConstruct, @PreDestroy, @PostActivate, @PrePassivate). Ta sama metoda może być udekorowana różnymi annotacjami zwrotnymi.

Zabronione jest wielokrotne użycie tej samej annotacji zwrotnej w danej klasie komponentu.

Drugi z interceptorów - interceptor metody biznesowej - jest definiowany przez annotację @AroundInvoke lub element around-invoke w deskryptorze instalacji dla metod biznesowych (należących do interfejsu biznesowego) komponentów sesyjnego i sterowanymi komunikatami. Jedynie pojedyńcza metoda udekorowana @AroundInvoke może istnieć w klasie komponentu lub w danej klasie interceptora. Zabronione jest, aby metoda udekorowana przez @AroundInvoke była metodą biznesową.

Wywołanie metody biznesowej wyzwala (jest przechwycone przez) metody klasy komponentu udekorowane przez AroundInvoke jak i klasy interceptorów. Wywołanie metody @AroundInvoke musi pociągać za sobą wywołanie metody InvocationContext.proceed() albo związana metoda biznesowa nie zostanie wywołana jak i kolejne metody @AroundInvoke.

Metody @AroundInvoke mają następującą sygnaturę:

public Object <NazwaMetody>(InvocationContext) throws Exception

Na zakończenie sekcji 3.4 dotyczącej interceptorów opisano klasę javax.interceptor.InvocationContext, który udostępnia kontekst wykonania dla interceptorów (i który wspomniany był kilkakrotnie wcześniej). Identyczna instancja InvocationContext jest przekazywana do każdego interceptora dla danej metody biznesowej lub zdarzenia związanego z etapem życia komponentu i pozwala na przekazywanie informacji między interceptorami.

Najważniejsza z metod w klasie InvocationContext to

public Object proceed() throws Exception

, która powoduje wywołanie kolejnego interceptora bądź, kiedy wywołana przez ostatni z interceptorów, metody biznesowej.

Kolejny rozdział specyfikacji EJB3 za mną - Chapter 3: Enterprise Bean Class and Business Interface

0 komentarzy
Przyznaję, że czym więcej testuję nowości specyfikacji EJB3 tym bardziej zastanawia mnie stopień skomplikowania jej w poprzednich wersjach. Współczuję tym, którzy musieli spędzać dłuuugie godziny nad rozwiązywaniem problemów związanych z niezrozumiałymi konstrukcjami EJB 2.1. Nie sądziłem, że kiedykolwiek doczekam się dnia, kiedy specyfikacja EJB stanie się tak przyjemna. Aż nie chce się wierzyć, że są tacy, którzy chcą, abyśmy....ekhm...chyba się zapomniałem, bo to chyba był tekst pewnego utworu z dawien dawna...więc wracając do tematu, są tacy, którzy twierdzą, że wiele uproszczeń nie weszło do Java EE 5, a które mogły jeszcze bardziej uatrakcyjnić specyfikację. Mimo wszystko dla mnie uproszczeń jest wystarczająca ilość. Poznanie ich z pewnością podniesie mój warsztat programistyczny, nawet jeśli nie przyjdzie mi tych rozwiązań wykorzystywać w projektach komercyjnych jeszcze długo (dostępność produkcyjna serwerów aplikacyjnych Java EE 5 jest jeszcze skromna).

Co wniosła do mojej wiedzy lektura rozdziału 3. Enterprise Bean Class and Business Interface specyfikacji EJB 3.0 Simplified API?

Rozdział 3 omawia te elementy specyfikacji EJB3, które są wspólne dla komponentów sesyjnych (ang. SB - session beans) i sterowanych komunikatami (ang. MDB - message-driven beans). Pojawia się również notka, która stwierdza, bardzo istotną z punktu widzenia osób tworzących rozwiązania oparte o poprzednie wersje specyfikacji EJB 2.1 i poprzednich, że komponenty encyjne nie są już w zasadzie komponentami EJB jak to miało miejsce poprzednio i stąd też osobny dokument na ich temat - Java Persistence API oraz brak omówienia w tym rozdziale.

Część informacji była już omówiona bardzo pobieżnie w poprzednich rozdziałach, stąd niektóre informacje wydają się być znajome (nawet dla nie-praktyków EJB3, którzy jednak śledzili poprzednie moje relacje).

Tworzenie modułu EJB rozpoczyna się od stworzenia interfejsu biznesowego, np.:

package pl.jaceklaskowski.exam.scheduler;

import java.util.List;

import pl.jaceklaskowski.exam.beans.Exam;

public interface ExamScheduler {
List<Exam> getExams();
}

, a następnie realizacji jego przez klasę komponentu EJB (ang. enterprise bean class),np.

package pl.jaceklaskowski.exam.scheduler;

import java.util.ArrayList;
import java.util.List;

import javax.ejb.Stateless;

import pl.jaceklaskowski.exam.beans.Exam;

@Stateless
public class ExamSchedulerBean implements ExamScheduler {

private final List<Exam> exams = new ArrayList<Exam>();

public List<Exam> getExams() {
return exams;
}

}

W przeciwieństwie do poprzednich wersji specyfikacji EJB, rolę aktywującą funkcjonalność modułu EJB stanowią przede wszystkim annotacje jako dodatkowy mechanizm konfiguracji poza osobno utrzymywanym, zewnętrznym deskryptorem instalacji - ejb-jar.xml. Annotacje, jako mechanizm dostarczany przez Java SE, służy do opisu modułu, jego wymagań i zależności od środowiska uruchomieniowego bezpośrednio w klasie komponentu EJB. Jedyną wymaganą annotacją klasy komponentu EJB jest deklaracja typu (jeśli takowa informacja nie została zawarta w deskryptorze instalacji).

Wyróżniamy następujące annotacje typów komponentu:
  • @Stateless - bezstanowy komponent sesyjny
  • @Stateful - stanowy komponent sesyjny
  • @MessageDriven - komponent sterowny komunikatami

Specyfikacja EJB3 określa, że interfejs biznesowy komponentu EJB to dowolny interfejs w Javie poza:
  • java.io.Serializable
  • java.io.Externalizable
  • dowolnym interfejsem z pakietu javax.ejb

które nie biorą udziału w wyznaczaniu interfejsów lokalnych i/lub zdalnych.

Nie ma konieczności implementacji interfejsów javax.ejb.EJBObject czy javax.ejb.EJBLocalObject, jak to miało miejsce w poprzedniej wersji specyfikacji (choć taka możliwość istnieje ze względu na wsteczną zgodność). I komponenty sesyjne i sterowane komunikatami wymagają co najmniej jednego interfejsu biznesowego (gdzie interfejs komponentu sterowanego komunikatami to zazwyczaj wskazanie na rodzaj obsługiwanej usługi, np. javax.jms.MessageListener dla JMS).

Ciekawym stwierdzeniem jest, że klasa główna komponentu nie musi implementować własnego interfejsu biznesowego. Jak dalej napisano, można tak udekorować klasę (bądź skorzystać z konfiguracji poprzez deskryptor instalacji), że interfejs biznesowy będzie realizowany przez inną klasę i będzie on nadal jej interfejsem biznesowym. Trochę to pogmatwane i nie jestem w stanie sobie tego wyobrazić, więc spodziewam się wyjaśnienia w kolejnych rozdziałach.

Skoro klasa komponentu EJB musi posiadać co najmniej jeden interfejs biznesowy (lokalny lub zdalny), to:
  • pojedyńczy interfejs realizowany przez nią zakłada się, że jest interfejsem biznesowym lokalnym chyba, że zadeklarowano inaczej poprzez annotację @Remote na klasie lub interfejsie (lub alternatywnie przez deskryptor instalacji - ejb-jar.xml). Domyślnie zakłada się, że występuje annotacja @Local.
  • Posiadanie więcej niż jednego interfejsu lokalnego czy zdalnego wymaga ich oznaczenia za pomocą annotacji @Local lub @Remote na klasie komponentu lub interfejsie bądź poprzez deskryptor instalacji.
  • Zabronione jest oznaczanie interfejsu biznesowego jednocześnie jako lokalnego i zdalnego, w tym również sytuacja niespójnej deklaracji @Local czy @Remote na klasie komponentu i interfejsie, tj. jeśli annotacja widoczności występuje na interfejsie biznesowym, to jeśli występuje ona również na klasie komponentu to ich wartości muszą być identyczne.
  • Zabronione jest deklarowanie interfejsu biznesowego, który rozszerza javax.ejb.EJBObject lub javax.ejb.EJBLocalObject.

Poniższy przykład ilustruje kilka z wymienionych wyżej wymagań.

package pl.jaceklaskowski.exam.manager;

import java.util.ArrayList;
import java.util.List;
import java.util.Set;

import javax.ejb.Local;
import javax.ejb.Remote;
import javax.ejb.Stateless;

import pl.jaceklaskowski.exam.beans.Exam;
import pl.jaceklaskowski.exam.beans.Note;

@Stateless
@Local(ExamScheduler.class)
@Remote(ExamVerifier.class)
public class ExamControllerBean implements ExamScheduler, ExamVerifier {

private final List<Exam> exams = new ArrayList<Exam>();

public List<Exam> getExams() {
return exams;
}

public Note verify(Exam exam, Set<String> answers) {
return exam.verify(answers);
}
}

Kolejne uproszczenie specyfikacji EJB3 dotyczy wyjątków. Metody interfejsu biznesowego mogą deklarować (poprzez słowo kluczowe throws) dowolne wyjątki aplikacyjne za wyjątkiem java.rmi.RemoteException, który jest opakowywany przez javax.ejb.EJBException przez serwer aplikacyjny, w przypadku problemów niskopoziomowych.

Specyfikacja przechodzi do omówienia interceptorów. Temat zajmuje aż 3 strony specyfikacji, co w porównaniu z poprzednimi tematami w tym rozdziale stanowi solidną dawkę informacji do przyswojenia. Postanowiłem pozostawić sobie przyjemność opisania go w kolejnej relacji po próbie zrozumienia tematu na przykładach.

Rozdział kończy się bardzo krótką wzmianką dotyczącą interfejsów domowych, które...znikają na dobre. Grały one kluczową rolę w poprzedniej wersji specyfikacji EJB 2.1 i poprzednich podczas, gdy teraz mamy do dyspozycji mechanizm wstrzeliwania zależności (realizowanego poprzez annotacje) w przypadku komponentów sesyjnych, a komponenty encyjne tworzy się za pomocą mechanizmu powoływania instancji klasy w Javie, tj. słowa kluczowego new.

Dla przypomnienia, komponenty sterowane komunikatami (MDB), ze względu na swoją specyfikę działania, nie miały interfejsu domowego już w poprzednich wersjach specyfikacji.

24 grudnia 2006

Wigilia i kolejny rozdział specyfikacji EJB3 - Chapter 2: Overview of the EJB 3.0 Simplified API

0 komentarzy
Święta to idealny czas na spędzenie czasu z rodziną i...dokształcanie się. Nie mogłem oprzeć się pokusie, aby nie zapoznać się z kolejnym rozdziałem specyfikacji EJB3 - Chapter 2: Overview of the EJB 3.0 Simplified API. Wyjątkowo krótki acz treściwy rozdział, który w niektórych miejscach, kiedy chciałem przygotować ilustrujące przykłady, zmusił mnie do lektury kolejnych. W zasadzie to jest on rozwinięciem rozdziału 1. i przybliża pewne terminy, które przewijają się przez całą specyfikację. Prezentuje on inne spojrzenie na uproszczenia nowej wersji specyfikacji EJB3.

Do tych już wspomnianych w rozdziale 1. (które opisałem wczoraj) dodać można:
  • Tworzenie modułów EJB nie wymaga tworzenia dodatkowych, specyficznych dla serwera aplikacyjnego, klas przed właściwą ich instalacją na serwerze. Innymi słowy: nie ma konieczności uruchamiania narzędzia dostarczanego przez serwer aplikacyjny generującego klasy pomocnicze dla modułów EJB. Klasy konieczne do uruchomienia modułów EJB tworzone są dynamicznie podczas uruchamiania przez serwer.

  • Nie ma konieczności rozszerzania klas należących do EJB API czy dostarczania klas wymaganych przez specyfikację EJB, np. rozszerzanie (nie wprost) javax.ejb.EnterpriseBean.

    Poniżej znajduje się przykład kompletnego bezstanowego komponentu sesyjnego implementującego biznesowy interfejs lokalny pl.jaceklaskowski.ejb.ExamScheduler.
    package pl.jaceklaskowski.ejb;

    import java.util.ArrayList;
    import java.util.List;
    import javax.ejb.Stateless;
    import javax.interceptor.Interceptors;
    import pl.jaceklaskowski.ejb.interceptor.ParameterLogger;

    @Stateless
    public class ExamSchedulerBean implements ExamScheduler {
    public List<Exam> getExams() {
    List<Exam> exams = new ArrayList<Exam>();
    exams.add(new Exam("Programowanie obiektowe"));
    return exams;
    }
    }
    gdzie pl.jaceklaskowski.ejb.ExamScheduler to:
    package pl.jaceklaskowski.ejb;

    import java.util.List;

    public interface ExamScheduler {
    List<Exam> getExams();
    }
    Instalacja komponentu ExamSchedulerBean to stworzenie pliku jar zawierającego obie klasy i umieszczenie go na serwerze aplikacyjnym. W poprzednich wersjach specyfikacji EJB 2.1 i wcześniejszych, między nimi występował jeszcze krok tworzenia klas specyficznych dla serwera aplikacyjnego. Krok był zależny od zastosowanego serwera, więc próba uruchomienia komponentu EJB wymagała wykonania go narzędziami dostarczanymi przez serwer (i wymagało zdecydowanie więcej wiedzy na temat środowiska poza znajomością samej specyfikacji EJB).

  • Konfiguracja komponentów EJB opiera się na ustandaryzowanych wartościach domyślnych, które można modyfikować poprzez udekorowanie kodu komponentów przez annotacje, bądź alternatywnie za pomocą pliku ejb-jar.xml. Wprowadzono nowy termin związany z konfiguracją komponentów EJB, tj. konfiguracja przez nadpisywanie (ang. configuration by exception), która określa podejście do konfiguracji EJB, gdzie podane są wyłącznie parametry konfiguracyjne nadpisujące wartości domyślne.

    Ważną kwestią jest wyznaczenie ostatecznej wartości parametru EJB. Mamy do dyspozycji (w kolejności ich rosnącej ważności):

    • możliwość pozostania przy konfiguracji domyślnej
    • nadpisania jej annotacjami
    • skorzystanie z deskryptora konfiguracji - ejb-jar.xml.

    Jest to przydatne w trakcie tworzenia aplikacji, gdzie można nadpisywać parametry za pomocą pliku ejb-jar.xml, a podczas produkcyjnej instalacji zaniechać jego dołączania i pozostania przy wartościach annotacji czy domyślnych.

  • Tworzenie komponentów EJB sprowadziło się do stworzenia metod ważnych dla programisty, a nie serwera aplikacyjnego, tj. nie ma konieczności dostarczania metod typu ejbCreate tylko i wyłącznie dla spełnienia wymagań serwera. Jeśli metody nie istnieją, kontener EJB dostarczy własne implementacje w trakcie działania.

  • Dowiązanie do zdalnego interfejsu biznesowego (ang. remote business interface) nie wymaga odszukania interfejsu domowego komponentu EJB, a następnie utworzenia instancji. W EJB3 uproszczono mechanizm dowiązania do pobrania interfejsu zdalnego bezpośrednio.

  • Dowiązania do innych komponentów i zasobów środowiska odbywa się poprzez annotacje (lub deskryptor instalacji). Wystarczy zadeklarować zależność za pomocą annotacji zmiennej prywatnej, która będzie reprezentować zależność, np. fabrykę instancji typu EntityManager (EntityManagerFactory), a kontener EJB poprzez mechanizm wstrzeliwania zależności (ang. dependency injection) zainicjuje zmienną do odpowiedniej wartości. Wyłącznie w pełni skonstruowana (zainicjowana) aplikacja z dostępnymi wszystkimi zależnościami będzie uruchomiona. W przypadku błędów inicjalizacji samych komponentów EJB, bądź powiązań między nimi, bądź ostatecznie części aplikacji deklarującej zależność z komponentami EJB serwer aplikacyjny nie uruchomi aplikacji.
    Załóżmy aplikację przemysłową (ang. enterprise application), która składa się z aplikacji internetowej (która z kolei składa się z servletu) oraz modułu EJB (który składa się z bezstanowego komponentu sesyjnego ExamSchedulerBean zaprezentowanego powyżej). Specyfikacja EJB3 uprościła sposób dostępu (dowiązania) servletu do komponentu EJB w następujący sposób:
    package pl.jaceklaskowski.servlet;

    import java.io.IOException;
    import java.util.List;
    import javax.ejb.EJB;
    import javax.servlet.RequestDispatcher;
    import javax.servlet.ServletException;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;

    import pl.jaceklaskowski.ejb.Exam;
    import pl.jaceklaskowski.ejb.ExamScheduler;

    public class ExecuteEjbServlet extends HttpServlet {

    @EJB
    private ExamScheduler examScheduler;

    protected void service(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
    List<Exam> exams = examScheduler.getExams();
    request.setAttribute("exams", exams);
    RequestDispatcher rd = getServletContext().getRequestDispatcher("/index.jsp");
    rd.forward(request, response);
    }
    }

    Na uwagę zasługuje udekorowanie prywatnej zmiennej instancji examScheduler annotacją @EJB, która za pomocą wykorzystanego interfejsu ExamScheduler wskazuje serwerowi aplikacyjnemu, który komponent EJB jest potrzebny.

  • Wprowadzenie interceptorów (ang. interceptors), które wprowadzają możliwości aspektów (ang. aspects) z Aspect-Oriented Programming (AOP) do świata komponentów EJB, gdzie można zadeklarować wykonanie metody interceptora wraz z wykonaniem metody komponentu EJB.

    Poniżej znajduje się klasa z metodą oznaczoną annotacją @AroundInvoke, za pomocą której wskazuje się metody biorące udział w mechaniźmie interceptorów.
    package pl.jaceklaskowski.ejb.interceptor;

    import java.lang.reflect.Method;
    import javax.interceptor.AroundInvoke;
    import javax.interceptor.InvocationContext;

    public class ParameterLogger {

    @AroundInvoke
    public Object printArgs(InvocationContext ic) throws Exception {
    Object target = ic.getTarget();
    Method m = ic.getMethod();
    Object[] params = ic.getParameters();
    System.out.printf("Parametry wywołania metody %s.%s %n", target.getClass().getName(), m.getName());
    if (params != null) {
    for (Object param: params) {
    System.out.printf("- %s %n", param);
    }
    } else {
    System.out.println("Brak parametrów wejściowych");
    }
    return ic.proceed();
    }
    }
    Wywołanie metody powyższej klasy w komponencie EJB wiąże się z udekorowaniem klasy bądź metody klasy annotacją @Interceptors z obowiązkowym parametrem wskazującym na klasę interceptora.
    package pl.jaceklaskowski.ejb;

    import java.util.ArrayList;
    import java.util.List;
    import javax.ejb.Stateless;
    import javax.interceptor.Interceptors;
    import pl.jaceklaskowski.ejb.interceptor.ParameterLogger;

    @Stateless
    @Interceptors(ParameterLogger.class)
    public class ExamSchedulerBean implements ExamScheduler {
    public List<Exam> getExams() {
    List<Exam> exams = new ArrayList<Exam>();
    exams.add(new Exam("Programowanie obiektowe"));
    return exams;
    }
    }
  • Udostępnienie komponentu EJB jako Usługi Sieciowej (ang. Web Service) wiąże się jedynie z udekorowaniem metod instancji klasy przez annotację @WebMethod.
    package pl.jaceklaskowski.ejb;

    import java.util.List;
    import javax.jws.WebMethod;

    public interface ExamScheduler {

    @WebMethod
    List<Exam> getExams();

    }
  • Łatwość migracji do nowej wersji specyfikacji EJB3.
    Podobnie jak to ma miejsce z innymi rozszerzeniami do Java SE czy Java EE zazwyczaj gwarantuje się ich wsteczną zgodność (dobrym przykładem jest mechanizmu Java Generics i jego wykorzystanie w Java Collections API). Aplikacja korzystająca z komponentów EJB 2.1 i wcześniejszych ma możliwość korzystania z rozwiązań EJB3 i na odwrót.

23 grudnia 2006

Usystematyzowanie nauki EJB 3.0 - Chapter 1: Introduction

0 komentarzy
Jak to w życiu bywa, zazwyczaj przemyślane podejścia mają szansę powodzenia. Czym więcej przemyślanych kroków, tym mniejsze ryzyko porażki. Postanowiłem sprawdzić to w praktyce w celu usystematyzowania mojej znajomości specyfikacji Enterprise JavaBeans 3.0 (EJB3 lub JSR 220) podchodząc do tematu w nowatorski dla mnie sposób. Mój plan polega na założeniu, że będę czytał specyfikację regularnie (najlepiej codziennie) po rozdziale, a wnioski z lektury spisywał i publikował w moim internetowym notatniku (blogu). W ten sposób upiekę dwie pieczenie na jednym ogniu (ang. to kill two birds with one stone), tzn. w usystematyzowany sposób poznam specyfikację i jednocześnie moje przemyślenia/relację wystawię na falę krytyki, która ostatecznie może jedynie udoskonalić moje zrozumienie tematu. Dodatkowo, wierzę, że w ten sposób wiele innych osób skorzysta na tym, szczególnie tych, którzy po kilku stronach specyfikacji, podobnie jak ja...zasypiają (co samo w sobie ma również swoje korzyści). Zakładam, że moja skondensowania wypowiedź będzie wystarczająco krótka, aby nie doprowadzić czytelnika do zaśnięcia. Nie byłoby to jednak zbyt interesujące, gdybym jedynie czytał (i zmuszał czytelnika do tego samego), więc planuję również testować nowozdobytą wiedzę w praktyce - na serwerze aplikacyjnym Glassfish, który jest referencyjną implementacją specyfikacji Java EE 5, której częścią jest EJB3. Można, więc spodziewać się przykładów - krótkich programów, których jedynym celem będzie rozpoznanie technologii, a nie rozwiązywanie problemów biznesowych (innymi słowy: będą to często programy bez większego sensu poza samym wkładem naukowym). Nie tracąc czasu na zbędne elaboraty przystępuję do realizacji mojego planu. Rozpoczynam lekturę od dokumentu EJB 3.0 Simplified API.

Dokument EJB 3.0 Simplified API składa się z 12 rozdziałów, przy czym 12. rozdział jest dodatkiem o historii dokumentu. Znajomość zmian jakie następowały w dokumencie odzwierciedla bolączki z jakimi przyszło zmagać się twórcom specyfikacji, więc jego znajomość jest równie cenna, jak pozostałych. Natomiast, 11. rozdział jest wyłącznie zestawieniem odnośników do dalszych lektur, więc ten nam odpada. Pozostaje 11 rozdziałów do przeczytania.

Cały dokument to 60 stron pisany w dość przystępnej formie. Mam nadzieję, że moje relacje nie sprowadzą się do kopiowania części dokumentu, co jest nielegalne bez zgody autora (i jeśli zdarzy mi się to popełnić, zaraz proszę o przesłanie informacji).

Rozpoczynam od rozdziału Chapter 1: Introduction.

Celem EJB 3.0 jest:
  • uproszczenie tworzenia komponentów EJB, m.in. poprzez uproszczenie EJB API, co zwiększa atrakcyjność specyfikacji
  • zgodność z EJB 2.1, co umożliwia migrację do nowego środowiska bez konieczności przepisywania aplikacji
  • możliwość jednoczesnego korzystania z EJB 2.1 i EJB 3.0
  • wykorzystanie dobrodziejstw nowości Java SE 5 - annotacji, co pozwala na określanie znaczenia klasy/interfejsu w aplikacji bez konieczności utrzymywania zewnętrznych plików, których często trudno było utrzymać aktualne (bez stosowania rozwiązań pomocniczych jak XDoclet - kolejny otwarty projekt, który miał wpływ na specyfikację EJB3)
  • zmniejszenie ilości klas/interfejsów do niezbędnego minimum, czyli powrót do korzeni języka Java, do specyfikacji JavaBeans, która była dostępna od jej pierwszych dni (ech, rzeczy proste zwykle pozostają niezauważane)
  • usunięcie konieczności rozszerzania klas czy implementacji interfejsów, co przywiązywało nasze komponenty EJB 3.0 ze środowiskiem serwera aplikacyjego. Obecnie zwykła klasa realizująca specyfikację JavaBeans - POJO (ang. plain old java object) gra główne skrzypce.
  • uproszczenie konstruowania powiązań między częściami aplikacji za pomocą annotacji, bez konieczności definiowania ich w plikach pomocniczych, np. ejb-jar.xml, web.xml, czy innych.
  • wprowadzenie ustawień domyślnych, które można nadpisywać annotacjami, czy (opcjonalnie) deklaracjami w pliku ejb-jar.xml. W poprzedniej wersji specyfikacji wiele domyślnych ustawień było specyficznych dla serwera aplikacyjnego, co powodowało, że wykorzystana wartość domyślna mogła przyjmować różne wartości dla różnych serwerów.
  • stworzenie JPA (Java Persistence API) dzięki, któremu zdefiniowano ujednoliconą warstwę zarządzania obiektami trwałymi, gdzie dostarcza się sterowników JPA (np. Hibernate) realizujących kontrakt (podobnie jak sterowniki JDBC w stosunku do JDBC).
  • uproszczenie mechanizmu notyfikacji o sytuacjach wyjątkowych w aplikacji

Jednym słowem twórcy specyfikacji nauczyli się oddychać tym samym powietrzem, co projektanci i programiści ze świata rozwiązań otwartych, np. Spring Framework, czy Hibernate i zapożyczyli wiele z rozwiązań. Wpływy tych projektów widać, aż nadto (i stąd moje przekonanie, że Spring Framework+Hibernate nie wprowadza do naszych rozwiązań przemysłowych - tych opartych o standard Java EE 5 - niczego, czego nie byłoby już dostępnego w serwerze aplikacji). Nadeszła ponownie era Java EE.

19 grudnia 2006

Nareczcie egzamin z Java EE 5 i to darmowy! Tylko do 2 stycznia 2007

0 komentarzy
Nie mogłem lepiej trafić z moim egzaminem SCJP 5 i nauką EJB 3.0! Właśnie, całkowicie przypadkiem, natrafiłem na darmowy kurs FREE: Sun Certified Business Component Developer 5.0 Beta Exam. Wystarczy zadzwonić do wybranego przez siebie centrum certyfikacji Prometric i podać kod 311-091 i do 2 stycznia 2007 możemy podejść do certyfikacji z EJB 3.0 za darmo (!) Zastanawiam się tylko komu udało się popracować z EJB3 od 4-6 miesięcy (zaleceniem w opisie egzaminu jest, aby beta takers have 4-6 months experience using EJB 3.0). Chętnie zaczerpnął trochę wiedzy od takiej osoby.

Dla mnie 2 stycznia jest nierealny, ale gdyby komuś zechciało się podejść do egzaminu SCBCD 5 proszę o natychmiastowy kontakt ;-)

Wracam do lektury specyfikacji EJB3 i ewaluacji IBM WebSphere Application Server Version 6.1 Feature Pack for EJB 3.

18 grudnia 2006

Sun Certified Java Programmer (SCJP) 5.0 zdany!

7 komentarzy
Voucher (czyli przepustkę) na egzamin kupiłem bodajże jeszcze w listopadzie 2005 roku w Sun'ie za 500 PLN. Czy to z powodu kończącego się terminu wazności vouchera, czy mojej wewnętrznej determinacji (raczej tego pierwszego) nadeszła pora na podejście do egzaminu Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0 (SCJP 5.0).

Dzisiaj o 11:00 stawiłem się w ABCData na VIII piętrze, gdzie dotarłem walcząc ze schodami po tym jak zdecydowałem się iść, a nie jechać windą. Kiedy dotarłem nie mogłem złapać tchu i to nie z powodu egzaminu (!) Zanim do normy wróciły wszystkie funkcje życiowe, pani wskazała mi na moje stanowisko. Po wstępnej ankiecie, w której miałem ocenić własną znajomość języka Java, przyszła pora na właściwy egzamin. Po około 2 godzinach zobaczyłem przy swoim nazwisku Pass, a następnie dostałem do ręki wydruk z wynikiem.


Przy minimum egzaminacyjnym na poziomie 59% zdobyłem 80%, co pozwoliło mi na pomyślne zdanie egzaminu. I nie ukrywam, że mimo wydawałoby się dużego zaangażowania w różne projekty i technologie Java, nie było lekko. Oj nie było! Czuję dużą ulgę, że mam to już za sobą - 72 pytań w 175 minut wykańcza samo w sobie, a życie analizatora składniowego języka Java nie jest łatwe ;-) O to właśnie chodzi na egzaminie - stać się analizatorem składniowym (!) Przy naszym wykorzystaniu zintegrowanych środowisk (IDE) coraz bardziej na nich polegamy zapominając o konstrukcjach języka (inicjalizacja tabel, średniki, przecinki), różnicach w działaniu podstawowych operatorów (np. & czy |) nie wspominając, że nauka nowości języka w wersji 5 nie należy do łatwych (szczególnie Java Generics, czy Enumy). Zdumiewające dla mnie było nauczenie się działania operatorów % oraz / i znaków ich wyników (dla dociekliwych: % daje w wyniku ujemną liczbę wyłącznie jeśli pierwszy operand jest ujemny, a przy drugim jeśli przynajmniej jeden z operandów).

Z czego się uczyłem? Głównie SCJP Sun Certified Programmer for Java 5 Study Guide (Exam 310-055) by Kathy Sierra and Bert Bates, McGraw-Hill/Osborne © 2006 oraz Whizlabs SCJP 5.0 Preparation Kit. Oczywiście ciągle towarzyszyły mi Java 2 Platform Standard Edition 5.0 API Specification i The Java Language Specification, Third Edition. Tak uzbrojony pozostawało mieć wystarczająco wiele czasu, aby zgłębić niuanse i meandry języka i uzyskać...no cóż...jedynie 80%. Duuużo cierpliwości i wystarczająco dużo snu są wielce pożądane (w ostatnią sobotę nie mogłem się opanować i zabrałem się za ewaluację IBM WAS 6.1 z dodatkiem EJB 3.0 - dobrze, że nie wiedziałem o BEA WLS 10 ;-)).

Każdemu osobiście polecam podejście do egzaminu, bo wiele się nauczyłem i zrozumiałem. Ile to razy nie mogłem uwierzyć w to, co czytam (szczególnie z wątkami oraz kolekcjami, z których ostatecznie i tak wypadłem kiepsko). Promocja typów również była ciekawa oraz kwalifikatory dostępu. Wiele informacji przyswajałem wykonując testy w symulatorze z Whizlabs, bo alternatywnie mogłem wkuwać z książki, a nie bardzo szło mi poznawanie detali Javy bez komputera.

Możnaby zapytać, czy egzamin jest potrzebny? Ja odpowiem: tak. Człowiek uczy się ponownie uczyć rzeczy, które wydaje mu się, że rozumie. I nie widać, aby była różnica, czy dopiero się zaczyna pracę z Javą, czy jest się weteranem. Oba profile mają swoje wady i zalety - pierwszy ma świadomość konieczności nauki nowości w Javie 5, podczas gdy drugiemu może się wydawać, że wystarczy jedynie przeczytać tu i tam i podejść. Obaj muszą przewertować javadoc i specyfikację od deski do deski i duuuużo testować. Przynajmniej takie są moje odczucia. Ja nie należę do cierpliwych i po upływie 2 godzin miałem dosyć. Zaznaczyłem 12 odpowiedzi jako "do sprawdzenia", ale kiedy przyszło mi je sprawdzać po prostu nie chciało mi się, byłem wypruty. Coś tam sprawdziłem, ale bojąc się błędnie wprowadzonych odpowiedzi na sam koniec ostatecznie zarzuciłem temat.

Oficjalny certyfikat w drodze. Zastanawiam się nad kolejnym egzaminem - może SCWCD albo SCBCD, ale z pewnością w ich najnowszej odsłonie dla Java EE 5 (nie mam zamiaru przechodzić męki z EJB 2.1 ponownie).

16 grudnia 2006

IBM WebSphere Application Server Version 6.1 Feature Pack for EJB 3

3 komentarzy
Na ostatnim spotkaniu Warszawa JUG poruszono temat wsparcia dla Java EE 5 w serwerach aplikacyjnych, również i tych komercyjnych, oraz wsparcie samych narzędzi. Moja prezentacja demonstrowała Java EE 5 w wykonaniu NetBeans IDE 5.5, M2 oraz Glassfish v2 i można było stwierdzić, że była zbyt ekstremalna w tym sensie, że większość z czynności wymagała znajomości Java EE i integracji narzędzi. Oczywiście znajomość technologii jest istotna w jej poprawnym zastosowaniu, jednakże z perspektywy czasu stwierdzam, że mogłoby być ciekawiej, jeśli prezentacja dotyczyłaby Java EE z punktu widzenia wsparcia przez narzędzia wspomagające tworzenie aplikacji (był NetBeans IDE, chociaż czułem, że większość pracuje z Eclipse IDE) oraz wsparcia przez produkcyjnie gotowe serwery aplikacyjne. M2 był dobrze odebrany, ale połączenie M2 i Java EE tworzyło temat nie na godzinę, badź dwie, ale na cały dzień (!)

Właśnie wczoraj przeczytałem informację o kolejnym komercyjnym dostawcy (poza Sunem i Oracle) z serwerem aplikacyjnym wspierającym EJB 3.0. Jest to dodatek-rozszerzenie do IBM WebSphere Application Server 6.1. I tutaj już wiadomo, o kim mowa - IBM. Nie ukrywam, że wiele mojego dziennego czasu upływa z produktami IBM i bardzo się ucieszyłem, kiedy po publikacji narzędzia IBM Rational Application Developer (RAD) v7, który oparty jest o Eclipse 3.2.1 (bądź jako rozszerzenie do własnej wersji), pojawia się teraz wsparcie dla EJB 3.0 w serwerze aplikacyjnym. Więcej informacji można znaleźć na stronie IBM WebSphere Application Server Version 6.1 Feature Pack for EJB 3. W nadchodzący poniedziałek podchodzę do egzaminu z Sun Java Certified Programmer 5 (SCJP 5), więc będę wewnętrznie walczył z samym sobą, aby nie spróbować uruchomić tego cacka ;-)

Jakby tego było mało jakimś dziwnym trafem znalazłem się na stronie Eclipse Dali JPA Tools, gdzie dowiedziałem się o rozszerzeniu Eclipse o narzędzia do Java Persistence API. Słyszałem wcześniej o Dali, ale aż do dzisiaj nie sądziłem, że ma to cokolwiek wspólnego z Java EE. W zasadzie to trudno mi sobie przypomnieć, co odpowiedziałbym, kiedy byłbym zapytany o Eclipse Dali. Teraz na pewno nie odpuszczę i korzystając z funkcjonalności Eclipse extension locations pobawię się Dali.

Dodam jeszcze, że projekt Apache OpenEJB 3 również małymi krokami zmierza ku wsparciu EJB 3.0, przez co wierzę, że i Apache Geronimo niedługo zacznie oferować dla niej wsparcie. Niedługo dla mnie oznacza pierwszą połowę nadchodzącego roku (Q107), ale czas pokaże jak będzie. W końcu jest to projekt otwarty, więc wszystko zależy od dostępności czasu osób zaangażowanych w projekt. Jeśli chciał(a)byś pomóc, zapraszam jako programista w obu projektach.

07 grudnia 2006

Relacja z II spotkania Warszawa JUG

4 komentarzy
Kolejne spotkanie Warszawa JUG za nami. Jak mi się relacjonuje było grubo ponad 40 osób, niektórzy skorzy byli doliczyć się koło 50 (!) Ja aż boję się próbować liczyć ;-) Tak czy owak, było to najbardziej ludne spotkanie jakie miałem zaszczyt prowadzić. Wydaje się, że można już mówić o pewnej społeczności użytkowników Java w Warszawie. Interesujące było zobaczyć salę wypełnioną po brzegi - wszystkie miejsca siedzące, stojące i klęczące pozajmowane. Drzwi otwarte, więc i można było zajść posłuchać, tak niezobowiązująco. Generalnie wierzę, że kolejne styczniowe spotkanie będzie równie liczne, więc konieczne należałoby przygotować coś ekstra - raz, że będzie to styczeń, dwa, że temat spotkał się z dużym zainteresowaniem (ok, być może nie był to wielki entuzjazm z odsłuchania prezentacji, ale zauważyć było można większe niż dotychczas zainteresowanie - więcej pytań w trakcie i po spotkaniu).

Samo prowadzenie spotkania było dla mnie nielada novum (i nie do końca udało utrzymać mi się tempo i jego styl). Nowość spotkania polegała na całkowitym braku slajdów. Wszystkie informacje przekazywane były ustnie w ramach wyjaśnienia kroków jakie wykonywałem tworząc aplikację na żywo, całkowicie unplugged. I jak to w zwyczaju bywa przy tego typu prezentacjach, nie obyło się bez wpadek. Ale właśnie one powodują, że spotkanie nabiera rumieńców. Przykład uruchamiałem kilkakrotnie przez spotkaniem, jak i podczas tworzenia artykułu, który był przyczynkiem do niego (Tworzenie aplikacji Java EE 5 z Apache Maven 2 i Glassfish). Wszystko grało. Wystarczyło kopiować uważnie z artykułu i wszystko powinno grać. Ja jednak zaabsorbowany wyłuskiwaniem prostoty tworzenia aplikacji Java EE jak to mam w zwyczaju rozgadałem się, wręcz odjechałem podeskcytowany tematem i nie przekopiowałem dwóch plików. Ostatniecznie, kiedy przyszło do jej uruchomienia i na moją uwagę, że nie ma prawa się nieuruchomić, ku mojemu zdumieniu pojawił się...wyjątek. Nie mogłem uwierzyć własnym oczom. Szczęśliwie klimat wokół pierwszego uruchomienia był bardzo przyjazny, więc obyło się bez gwizdów, pomidorów, czy innych dodatków. Dzięki temu mogłem zaprezentować sposób rozwiązywania problemów podczas tworzenia aplikacji, co sprowadziło się do poprawienia web.xml i faces-config.xml.

Spotkanie trwało 2 godziny i wszyscy wytrwali do samego końca. Było wiele pytań o możliwość zastosowania tej wiedzy w praktyce, na co odpowiedziałem, że nasza wiedza wykracza poza możliwości dostępnego oprogramowania. Nie całkowicie, ale w dużej części. W końcu udało nam się być przygotowanym na nowości w świecie tworzenia aplikacji przemysłowych w Javie. Była wzmianka o kontenerach IoC i annotacjach w Javie, pojawiło się pytanie o JBoss Seam i Tomcat 6, jak i wzmianka o licencji Glassfish, która wygląda na niesprzyjającą uruchamianiu aplikacji komercyjnych na nim. Ogólnie bardzo mi się podobało i zamierzam dalej kontynuować temat.

Kolejne spotkanie Warszawa JUG planowane jest na 9 stycznia 2007. Do zobaczenia!

p.s. Spotkanie było ponownie nagrywane, ale odsłuchawszy poprzedniego nie sądzę, ażebym zdobył się na odwagę i opublikował materiał. Tak wiele błędów prezenterskich, że szkoda psuć sobie opinię wsród tych, którzy sądzą, że spotkania są ciekawą inicjatywą, ale nie mieli okazji jeszcze jej poczuć ;-)

01 grudnia 2006

II spotkanie Warszawskiej Grupy Użytkowników Technologii Java (Warszawa-JUG)

0 komentarzy
I kolejne spotkanie grupy Warszawa JUG. Poniżej zaproszenie jakie rozesłałem na różne fora i grupy. Serdecznie zapraszam.

Warszawska Grupa Użytkowników Technologii Java (Warszawa-JUG) zaprasza na II spotkanie, które odbędzie się we wtorek 05.12.2006 o godzinie 18:00 w sali 5820 na Wydziale MiMUW przy ul. Banacha 2 w Warszawie.

Temat prezentacji: Tworzenie aplikacji Java EE 5 z wykorzystaniem Apache Maven 2

Wiele się zmieniło w specyfikacji Java EE 5 od ostatniej jej wersji. Twórcy specyfikacji, czerpiąc z wielu uproszczeń oferowanych w projektach otwartych, m.in. Spring Framework czy Hibernate, stworzyli bardzo elegancką specyfikację opartą o mechanizmy wstrzeliwania zależności (dependency injection - DI - bądź Inversion of Control - IoC), czy nowość w Javie SE 5 - annotacji. Tworzenie aplikacji Java EE 5 znacząco zostało uproszczone. Można śmiało powiedzieć, że nie ma znaczącej różnicy w sposobie tworzeniach aplikacji desktopowej, a uruchamianej na serwerze aplikacyjnym. Przekonamy się o tym tworząc aplikację Java EE 5 opartą o JavaServer Faces 1.2 i Enterprise JavaBeans 3.0, której wspomaganie projektowe zlecone zostanie Apache Maven 2.

Prezentacja prowadzona będzie przez Jacka Laskowskiego, który jest członkiem grup rozwojowych projektów Apache Geronimo i Apache OpenEJB. Tematyka spotkania została spisana i opublikowana do publicznej krytyki na jego własnym Wiki.

Planowany czas prezentacji to 1 godzina z kolejnymi 30 minutami na dyskusję.

Zapraszam w imieniu Warszawa-JUG!