Lektura EJB3 Simplified za mną i długo wahałem się przed podjęciem kolejnej decyzji o następnej specyfikacji. Zawsze chciałem zajrzeć do EJB Core Contracts and Requirements, ale poza teoretycznym wzmocnieniem swojej wiedzy o EJB3, nie dowiedziałbym się niczego praktycznego, niczego nowego, czego nie dowiedziałem się z EJB3 Simplified. W międzyczasie miałem okazję zajrzeć do Java EE 5 Specification i wciąż oczekiwała mnie specyfikacja JavaServer Faces 1.2. I tak się zastanawiałem, aż kiedy przyszło do napisania aplikacji z użyciem JPA, gdzie nie mogłem poradzić sobie z ustaleniem konfiguracji dla servletu, który korzystał z @PersistenceContext. Do tego doszło zaproszenie do lektury Hibernate. Od Nowicjusza do Profesjonalisty i tak ostatecznie podjąłem decyzję o rozpoczęciu lektury specyfikacji Java Persistence API. Podobnie jak poprzednio z EJB3 Simplified, zamierzam przejść rozdział po rozdziale przez cały dokument, poznając tajniki JPA na bazie GlassFish (z TopLink jako dostawcą JPA), Apache OpenJPA oraz Hibernate.
Zaczynam od rozdziału wprowadzającego - Chapter 1 Introduction.
Dokument jest specyfikacją interfejsu publicznego Java do zarządzania zapisem (utrwalaniem) i mapowaniem danych obiektowych do/z postaci relacyjnej (ang. ORM - object/relational mapping) w Java EE oraz Java SE. I tu pierwsza ważna informacja - wspomniano o dwóch platformach, na których możliwe jest uruchomienie rozwiązań JPA - serwery aplikacyjne oraz najzwyklejsze aplikacje Java nie korzystające z ich usług. Z publikacją Java Persistence API (JPA) umożliwiono twórcom aplikacji Java korzystanie z ustandaryzowanego sposobu mapowania danych z/do bazy relacyjnej (podobnie jak JDBC jest ustandaryzowanym dostępem do bazy danych, tak JPA jest ustandaryzowanym mechanizmem operowania danymi relacyjnymi - przechowywanymi w bazie danych i pobranych za pomocą JDBC).
Wymagane jest, aby kontenery EJB3 obsługiwały JPA.
Wyraźnie zaznaczono wpływ istniejących projektów i specyfikacji na ostateczną postać JPA - Hibernate, TopLink oraz JDO (ang. Java Data Object). Przez wiele lat zarzucano specyfikacji EJB brak wykorzystania interesujących i sprawdzonych rozwiązań z innych projektów, wliczając wciąż mało popularną specyfikację JDO, która nie mogła zdobyć się na sławę równą Hibernate (podobnie jak C++ porównany z Java). Tym razem celem JPA było dostarczenie ustandaryzowanego API, które przybliża cechy wymienionych produktów i specyfikacji do szerszego grona odbiorców.
Lista osób biorących udział w tworzeniu specyfikacji JPA zamyka rozdział 1. (jest na niej wiele osób, które czynnie biorą udział w projektach otwartych, w tym Apache Geronimo oraz Apache OpenEJB).
p.s. Dziś po raz pierwszy doświadczyłem aktywności spamerów na własnej skórze - we własnym notatniku. Ostatnio doświadczyła tego załoga javalobby.org i po tym jak pojawiło się mnóstwo wiadomości z nielegalnymi odnośnikami Google wyłączył ich stronę z indeksowania (Rick na prawdę się tym przejął dedykując wiadomość o tym wydarzeniu i rozsyłając informację do użytkowników JavaLobby). W jeden dzień javalobby.org i mnóstwo artykułów Java zniknęło z Internetu - nie wprost, ale biorąc pod uwagę, że wielu z nas korzysta z Google jako jedynej, slusznej wyszukiwarki, to oznaczało koniec dla Ricka. Wiedząc jakimi reperkusjami to się kończy, szybko wyłączyłem komentarze niezarejestrowanych (i niestety nie wprost rozpocząłem zachęcanie do zapisywania się do usług Google). No cóż - takie życie. Mam nadzieję, że na jakiś czas mam spokój.
29 stycznia 2007
Hibernate. Od Nowicjusza do Profesjonalisty - książka wydawnictwa Power Net
Szykuje się nie lada gratka dla osób na codzień parających się rozwiązaniami opartymi o Hibernate, ale również i tych, którym marzą się projekty z jego wykorzystaniem. Tak przynajmniej brzmi tytuł nowej pozycji na polskim rynku Hibernate. Od Nowicjusza do Profesjonalisty wydawnictwa Power Net. Ktoś niedawno wspomniał o niej na p.c.l.java i co mnie po raz pierwszy uderzyło to domena - http://www.hibernate.pl. Zastanawiałem się, dlaczego wcześniej nie wpadłem na pomysł, aby sprawdzić dostępność tego typu domen (w końcu polska domena dla JBoss też istnieje - bez urazy, ale reklamy nie będzie, chociaż tam również zaglądam).
Kolejnym zaskoczeniem był dla mnie jeden z odnośników na stronie, który prowadził do...mojego artykułu wprowadzającego do Hibernate (!) I co za recenzja - "dobry wstęp po polsku". Od razu mi przypadli do gustu ;-)
To nie był koniec moich przygód z Power Net. Po kilku dniach nie mogłem uwierzyć w to, co mogłem przeczytać w jednej z wiadomości w skrzynce pocztowej.
Jak na początek roku - trzy zaproszenia na wykłady i teraz recenzja - wydaje się, że wystarczy. Pamiętny mojej wizyty na stronie wydawnictwa, długo nie zastanawiałem się przed podjęciem decyzji. W końcu byłem u końca lektury EJB3 Simplified i z niecierpliwością oczekiwałem dnia, kiedy będą mógł zapoznać się ze specyfikacją Java Persistence API (JPA), a kto jak kto, ale Hibernate miał ogromny wpływ na obecny jej kształt. Na uwagę zasługiwał również fakt, że książka dotyczy najnowszej wersji Hibernate 3.2 i spis treści obiecuje nie lada gratkę dla każdego tworzącego rozwiązania oparte o Hibernate, JPA, czy ogólnie chcącego poznać techniki mapowania bytów obiektowych z/do relacyjnych.
Dla uatrakcyjnienia oferty (tak, jakbym jeszcze miał wątpliwości, aby podjąć się wyzwania) wydawnictwo Power Net ufundowało mi książkę całkowicie za darmo! I jak tu się nie zgodzić?! Raz - dokładnego rozpoznania oferty Hibernate (poprzez lekturę książki), dwa - możliwości zrecenzowania nowej pozycji książkowej na polskim rynku wydawnictw informatycznych. Można było zażyczyć sobie lepszego ugruntowania wiedzy o Hibernate? Szczerze w to wątpię.
Kolejnym zaskoczeniem był dla mnie jeden z odnośników na stronie, który prowadził do...mojego artykułu wprowadzającego do Hibernate (!) I co za recenzja - "dobry wstęp po polsku". Od razu mi przypadli do gustu ;-)
To nie był koniec moich przygód z Power Net. Po kilku dniach nie mogłem uwierzyć w to, co mogłem przeczytać w jednej z wiadomości w skrzynce pocztowej.
Jestem z firmy Power Net, która przekształciła się w wydawnictwo. Jedna z pierwszych naszych książek to Hibernate. Od Nowicjusza do Profesjonalisty (w oryginale Beginning Hibernate: From Novice to Professional). Jest to książka do najnowszej wersji Hibernate, czyli 3.2. W USA ukazała się w sierpniu 2006, u nas już w styczniu 2007.
Czy byłaby możliwość zrecenzowania przez Pana naszej książki?Jak na początek roku - trzy zaproszenia na wykłady i teraz recenzja - wydaje się, że wystarczy. Pamiętny mojej wizyty na stronie wydawnictwa, długo nie zastanawiałem się przed podjęciem decyzji. W końcu byłem u końca lektury EJB3 Simplified i z niecierpliwością oczekiwałem dnia, kiedy będą mógł zapoznać się ze specyfikacją Java Persistence API (JPA), a kto jak kto, ale Hibernate miał ogromny wpływ na obecny jej kształt. Na uwagę zasługiwał również fakt, że książka dotyczy najnowszej wersji Hibernate 3.2 i spis treści obiecuje nie lada gratkę dla każdego tworzącego rozwiązania oparte o Hibernate, JPA, czy ogólnie chcącego poznać techniki mapowania bytów obiektowych z/do relacyjnych.
Dla uatrakcyjnienia oferty (tak, jakbym jeszcze miał wątpliwości, aby podjąć się wyzwania) wydawnictwo Power Net ufundowało mi książkę całkowicie za darmo! I jak tu się nie zgodzić?! Raz - dokładnego rozpoznania oferty Hibernate (poprzez lekturę książki), dwa - możliwości zrecenzowania nowej pozycji książkowej na polskim rynku wydawnictw informatycznych. Można było zażyczyć sobie lepszego ugruntowania wiedzy o Hibernate? Szczerze w to wątpię.
25 stycznia 2007
Java EE 5: Resources, Naming, and Injection
Zanim podejdę do lektury kolejnej specyfikacji postanowiłem sprawdzić jedną rzecz, która męczyła mnie od dawna - rodzaje komponentów w Java EE 5, które podlegają obsłudze mechanizmu wstrzeliwania zależności (DI). Pamiętam, że podczas przygotowań do, bądź w trakcie prezentacji EJB3 na spotkaniu Warszawa JUG, zauważyłem, że strony JSP nie korzystają z DI (mimo, że JSP to ostatecznie servlet). Właśnie teraz, po zakończeniu EJB3 Simplified, a przed rozpoczęciem kolejnej części stwierdziłem, że jest to najlepszy moment, w którym powinienem rozwiać wszelkie wątpliwości z tym związane. I...zabrałem się za lekturę rozdziału 5 specyfikacji Java Platform, Enterprise Edition (Java EE) Specification, v5 (co za zbieg okoliczności z tymi 5-tkami) - Chapter 5: Resources, Naming, and Injection.
Rozdział 5 zawiera dokładnie to, czego potrzebowałem, aby w pełni odpowiedzieć na pytanie: Kogo dotyka dobrodziejstwo DI? Z EJB3 Simplified wiem, że dotyczy to każdego typu komponentu EJB, ale co poza tym? Odpowiedzi udziela rozdział 5 specyfikacji Java EE 5. W nim opisano sposób deklarowania i rozwiązywania zależności od zasobów środowiska i parametrów konfiguracyjnych. Jest to zlepek informacji pochodzących z różnych specyfikacji pomocniczych:
W przeciwieństwie do EJB3 Simplified, rozdziały specyfikacji JavaEE są obszerne i zazwyczaj składają się z wielu podrozdziałów. Rozdział 5 - Resources, Naming, and Injection składa się z 54 stron i 13 sekcji, co z pewnością wymaga trochę czasu, aby to przerobić i zrozumieć. Mnie zabrało aż 2 dni i próba zreferowania tematu zawsze kończyła się wycięciem kilku informacji, które z pragmatycznego punktu widzenia nie są istotne (a jeśli są, to i tak przychodzi wtedy pora na zapoznanie się ze specyfikacją bądź dokumentacją produktu - raczej w odwrotnej kolejności).
Dużym udogodnieniem jest uwspólnienie wymagań konfiguracyjnych dla różnych typów komponentów, czyli poznanie adnotacji dla komponentów jednego typu (np. EJB) jest równoznaczne z poznaniem adnotacji dla pozostałych (np. servletów) oraz samego sposób ich użycia.
Wstrzelenie zasobów zależnych sprowadza się do odszukania ich w kontekście nazw JNDI (ang. JNDI naming context), tj. użycie adnotacji jest w tym przypadku jedynie skrótem programistycznym i jest równoznaczne z odszukaniem zasobu w JNDI.
Metody biznesowe komponentu korzystają z elementów/wpisów w środowisku (poza małymi wyjątkami jak metody przechwytujące czy zwrotne). Mogą je pozyskiwać poprzez operacje JNDI bądź skorzystać z metod wyszukujących na obiekcie kontekstu specyficznego dla komponentu (które de facto opakowują bezpośrednie korzystanie z metod JNDI - są ich uproszczeniami, które znoszą obowiązek poznawania szczegółów konfiguracyjnych i metod JNDI). Poza tymi sposobami (które uważam za stosunkowo niskopoziomowe) istnieje mechanizm wstrzeliwania zależności, które umożliwia przekazanie (wstrzelenie) zależności do pola instancji bądź metod modyfikujących (ang. setter) - zauważyłem użycie określenia pole instancji oraz właściwość instancji, gdzie to drugie jest polem instancji z metodą modyfikującą i/lub odczytującą. Dostawca komponentu deklaruje w deskryptorze instalacji lub za pomocą adnotacji wszystkie zasoby środowiska, od których zależy działanie aplikacji. Kontener zarządza kontekstem nazw JNDI i umożliwia ich administrację. Osoba instalująca aplikację ma możliwość inicjowania wartości elementów środowiska, które wskazują na wymagane przez aplikację zasoby środowiska.
Każdorazowe wyszukanie pozycji w przestrzeni nazw java: zwraca nową instancję danego typu z kilkoma drobnymi wyjątkami, gdzie kontener wie, że się nie zmienią (stan obiektu jest niezmienny, singletony, wybrane obiekty współdzielone). Tym samym każdorazowe wstrzelenie zależności poprzez adnotacje jako równoważne wyszukaniu w kontekście komponentu nowej instancji, bądź współdzielonej zgodnie z zasadami wymienionymi powyżej (uwaga na jednostki utrwalania - ang. persistence unit - przy wartości tworzenia schematu drop-create).
Kilka istotnych uwag odnośnie miejsca użycia adnotacji:
Typy komponentów mogących korzystać z DI (to był właśnie powód lektury rozdziału 5!):
Adnotacje mogą być związane z samą klasą. W takim przypadku należy podać nazwę zależnego zasobu. Nie powoduje to faktycznego wstrzelenia zależności, a jedynie deklarację pozycji w kontekście komponentu. Niestety, nie odkryłem jeszcze sytuacji, w której chciałbym skorzystać z tej możliwości - wydaje mi się, że jest to po prostu ukłon w stronę administratora, że korzystamy z takiego zasobu wprost, poprzez operacje JNDI, aby wiedział, co należy dostarczyć w środowisku, tj. serwerze aplikacyjnym, aby komponent działał poprawnie (a może jest to układ do samego siebie, w końcu skoro przekazujemy komponent do wykorzystania, to chcemy, aby błedy typu brak zasobów nie wpływał na stan emocjonalny klienta ;-))
Udekorowanie klas może odbywać się na dowolnym poziomie hierarchi klas komponentu. Nie ma znaczenia, że klasa, z której dziedziczy komponent nie jest komponentem podlegającym DI. DI podlega zasadom widzialności pól i metod w Javie, co oznacza, że wszystko, co widoczne w klasie podlegającej DI może zostać udekorowane (mimo, że fizycznie nie występuje w samej klasie mogącej zażądać DI). Klasa pochodna ma prawo nadpisać adnotacje, tj. zmienić typ wstrzeliwanego zasobu, czy nawet zadeklarować brak DI.
Deklaracja składowej środowiska (zasób bądź zmienna) odbywa się albo za pomocą adnotacji, albo wpisów do deskryptora instalacji. Istotna zmiana w Java EE 5 polega na możliwości zaniechania deskryptora na rzecz domyślnych wartości zależności bądź ich deklaracji i konfiguracji za pomocą adnotacji (ale to juz było wiadomo z EJB3 Simplified). Ta sama składowa może być zadeklarowana poprzez adnotację i deskryptora instalacji (w kolejności ich ważności, czyli wartość z deskryptora jest ważniejsza). Jest to sposób na nadpisanie wartości przez osobę składającą aplikację z komponentów czy administratora (bez konieczności posiadania kodu źródłowego, gdzie zadeklarowano, lub nie, zależności poprzez adnotacje). Nie powinno się korzystać z DI w deskryptorze instalacji do pól lub metod, które nie zostały do tego przeznaczone (czyli możliwa jest, ale nie zalecana, sytuacja, gdzie administrator zmodyfikuje deskryptor instalacji - to mu wolno - i wstrzeli zasób do pola/metody, która nie została przez programistę udekorowana - Ale jazda! Szanujmy administratorów! ;-)).
Reguły rozwiązywania wartości elementu środowiska zadeklarowanego za pomocą adnotacji i nadpisanego przez deskryptor instalacji:
Specyfikacja zawiera obowiązki poszczególnych ról występujących podczas tworzenia aplikacji - dostawcy komponentu, osoby składającej aplikację, administratora i dostawcy serwera aplikacyjnego. W ten sposób opisano wszystkie rodzaje pozycji kontekstu i ich konfigurację względem ról.
Pole lub metoda może być udekorowana przez @Resource. Kontener "rozpakuje" typ opakowujący na jego odpowiednik prosty (ang. Java unboxing). authenticationType i shareable nie mogą być podane (nie mają zastosowania).
Dostawca komponentu deklaruje wpisy środowiska za pomocą adnotacji bądź deskryptora instalacji (env-entry). Zasięg widoczności wpisu jest wyłącznie do komponentu, który go zawiera. Ta sama nazwa wpisu może pojawić się wielokrotnie dla różnych komponentów.
Poza deklaracją elementu środowiska poprzez adnotację (w ten sposób deklarujemy, które pole/właściwość podlega DI) mamy możliwość zadeklarować wstrzelenie wartości elementu środowiska bez konieczności korzystania z adnotacji za pomocą znacznika injection-target (w obszarze znacznika env-entry) - uwaga na programowanie w XML znane i (nie)lubiane z Jelly - administratorzy mają kolejną zabawkę, aby instalacja aplikacji trwała latami.
Istnieje możliwość deklarowania wartości domyślnej w kodzie komponentu.
Istnieje również możliwość wiązania referencji EJB z jednego komponentu do EJB w pliku ejb-jar w deskryptorze instalacji bądź poprzez adnotację.
Adnotacja @EJB przypisywana jest do pola albo metody i jedynie dla dowiązania do komponentu sesyjnego (niby wiadome, ale i tak było to dla mnie duużym zaskoczeniem).
Referencja może być do lokalnego/zdalnego interfejsu domowego (EJB 2.1 i poprzednie) albo do interfejsu biznesowego (EJB 3.0). Jeśli korzysta się z referencji do interfejsu biznesowego (EJB3) wstrzelona zostanie już instancja EJB.
Istnieje możliwość precyzyjnego podania wartości adnotacji (z częściowym wykorzystaniem wartości domyślnych - patrz: konfiguracja przez nadpisywanie).
Mimo, że referencje do EJB są elementami środowiska to env-entry nie ma zastosowania. Korzysta się z adnotacji (kod źródłowy) albo znaczników ejb-ref lub ejb-local-ref (deskryptor instalacji).
Opcjonalny znacznik ejb-link precyzuje położenie zależnego komponentu EJB w aplikacji przemysłowej (ear). Można wykorzystać go do przypisywania nazwy logicznej komponentom o tych samych nazwach.
Pole lub metoda może być udekorowana @Resource. Elementy authenticationType i shareable służą do uszczegółowienia konfiguracji dostępu do zasobów.
Za pomocą adnotacji @Resource, nie ma możliwości zdefiniowania, czy związany zasób służy do odbioru czy wysyłania komunikatów. Służy do tego deskryptor instalacji z pomocą znacznika message-destination-ref.
Wstrzelenie lub udostępnienie zasobu w kontekście jest kontrolowane przez serwer aplikacyjny i mimo zadeklarowania referencje mogą nie istnieć (ale nie doszedłem, które są takimi wrażliwymi typami komponentów).
Możliwe dekorowanie @Resource albo wyszukanie java:comp/TransactionSynchronizationRegistry w JNDI.
Wstrzelenie lub udostępnienie zasobu w kontekście jest kontrolowane przez serwer aplikacyjny i mimo zadeklarowania referencje mogą nie istnieć (ale nie doszedłem, które są takimi wrażliwymi typami komponentów).
Serwer aplikacyjny musi dostarczyć obiekt do każdego typu komponentu poza appletami.
Jednostki zapisu definiowane są w persistence.xml zgodnie z zasadami opisanymi w specyfikacji Java Persistence API (część specyfikacji Enterprise JavaBeans 3.0).
Pole lub metoda może zostać udekorowana adnotacją @PersistenceUnit. Opcjonalnie można podać nazwę jednostki w JNDI za pomocą elementu name. Element unitName wskazuje na nazwę jednostki jak zdefiniowano w persistence.xml.
Deklaracja zależności w deskryptorze instalacji odbywa się poprzez persistence-unit-ref.
Identyczne nazwy jednostek (wykorzystywanych przez różne komponenty) można przypisać do nazw logicznych w deskryptorze instalacji z wykorzystaniem '#' w znaczniku persistence-unit-name.
Jednostki zapisu definiowane są w persistence.xml zgodnie z zasadami opisanymi w specyfikacji Java Persistence API (część specyfikacji Enterprise JavaBeans 3.0).
Pole lub metoda może zostać udekorowana adnotacją @PersistenceContext. Opcjonalnie można podać nazwę jednostki w JNDI za pomocą elementu name. Element unitName wskazuje na nazwę jednostki jak zdefiniowano w persistence.xml. Opcjonalny element type wskazuje na rodzaj kontekstu:
Rozdział 5 zawiera dokładnie to, czego potrzebowałem, aby w pełni odpowiedzieć na pytanie: Kogo dotyka dobrodziejstwo DI? Z EJB3 Simplified wiem, że dotyczy to każdego typu komponentu EJB, ale co poza tym? Odpowiedzi udziela rozdział 5 specyfikacji Java EE 5. W nim opisano sposób deklarowania i rozwiązywania zależności od zasobów środowiska i parametrów konfiguracyjnych. Jest to zlepek informacji pochodzących z różnych specyfikacji pomocniczych:
- Java Metadata (JSR-175 aka adnotacje), która jest częścią Java SE 5 (patrz pakiet: java.lang.annotation)
- Java Naming and Directory Interface (JNDI) - podobnie jak adnotacje, jest częścią Java SE od wersji 1.3 (patrz pakiet: javax.naming)
- Common Annotations 1.0 (JSR-250) opisująca adnotacje wspólne dla technologii Java (nie tylko Java EE)
- Enterprise JavaBeans 3.0 (JSR-220), w której skład wchodzi również specyfikacja Java Persistence API
W przeciwieństwie do EJB3 Simplified, rozdziały specyfikacji JavaEE są obszerne i zazwyczaj składają się z wielu podrozdziałów. Rozdział 5 - Resources, Naming, and Injection składa się z 54 stron i 13 sekcji, co z pewnością wymaga trochę czasu, aby to przerobić i zrozumieć. Mnie zabrało aż 2 dni i próba zreferowania tematu zawsze kończyła się wycięciem kilku informacji, które z pragmatycznego punktu widzenia nie są istotne (a jeśli są, to i tak przychodzi wtedy pora na zapoznanie się ze specyfikacją bądź dokumentacją produktu - raczej w odwrotnej kolejności).
Dużym udogodnieniem jest uwspólnienie wymagań konfiguracyjnych dla różnych typów komponentów, czyli poznanie adnotacji dla komponentów jednego typu (np. EJB) jest równoznaczne z poznaniem adnotacji dla pozostałych (np. servletów) oraz samego sposób ich użycia.
Wstrzelenie zasobów zależnych sprowadza się do odszukania ich w kontekście nazw JNDI (ang. JNDI naming context), tj. użycie adnotacji jest w tym przypadku jedynie skrótem programistycznym i jest równoznaczne z odszukaniem zasobu w JNDI.
Metody biznesowe komponentu korzystają z elementów/wpisów w środowisku (poza małymi wyjątkami jak metody przechwytujące czy zwrotne). Mogą je pozyskiwać poprzez operacje JNDI bądź skorzystać z metod wyszukujących na obiekcie kontekstu specyficznego dla komponentu (które de facto opakowują bezpośrednie korzystanie z metod JNDI - są ich uproszczeniami, które znoszą obowiązek poznawania szczegółów konfiguracyjnych i metod JNDI). Poza tymi sposobami (które uważam za stosunkowo niskopoziomowe) istnieje mechanizm wstrzeliwania zależności, które umożliwia przekazanie (wstrzelenie) zależności do pola instancji bądź metod modyfikujących (ang. setter) - zauważyłem użycie określenia pole instancji oraz właściwość instancji, gdzie to drugie jest polem instancji z metodą modyfikującą i/lub odczytującą. Dostawca komponentu deklaruje w deskryptorze instalacji lub za pomocą adnotacji wszystkie zasoby środowiska, od których zależy działanie aplikacji. Kontener zarządza kontekstem nazw JNDI i umożliwia ich administrację. Osoba instalująca aplikację ma możliwość inicjowania wartości elementów środowiska, które wskazują na wymagane przez aplikację zasoby środowiska.
Współdzielenie zasobów środowiska
Komponenty deklarują zależności, które dostarczone są przez kontener (serwer aplikacyjny) w przestrzeni nazw JNDI komponentu. Instancje wybranego komponentu w ramach pojedyńczego kontenera współdzielą te same składowe środowiska. Nie ma możliwości modyfikowania środowiska podczas działania aplikacji - innymi słowy przestrzeń nazw jest wyłącznie do odczytu.Każdorazowe wyszukanie pozycji w przestrzeni nazw java: zwraca nową instancję danego typu z kilkoma drobnymi wyjątkami, gdzie kontener wie, że się nie zmienią (stan obiektu jest niezmienny, singletony, wybrane obiekty współdzielone). Tym samym każdorazowe wstrzelenie zależności poprzez adnotacje jako równoważne wyszukaniu w kontekście komponentu nowej instancji, bądź współdzielonej zgodnie z zasadami wymienionymi powyżej (uwaga na jednostki utrwalania - ang. persistence unit - przy wartości tworzenia schematu drop-create).
Kilka istotnych uwag odnośnie miejsca użycia adnotacji:
- Pole lub metoda instancji może być dowolnej widoczności (public, private, protected czy domyślnej)
- Poza klientami aplikacyjnymi (ang. application client) pole i metoda nie mogą być static
- W przypadku klientów aplikacyjnych pole i metoda musza być static
- Udekorowane pole nie może być final
- Domyślna nazwa zasobu wyszukiwanego w kontekście podczas wstrzeliwania zależności to sklejenie nazwy pola wraz z pełną nazwą klasy, np. java:comp/env/pl.jaceklaskowski.exams.ExamSchedulerBean/examScheduler, gdzie java:comp/env wyznacza prywatną cześć przestrzeni nazw dla komponentu podlegającemu DI, pl.jaceklaskowski.exams.ExamSchedulerBean jest nazwą klasy, w której następuje DI (w tym przypadku jest to komponent EJB) oraz examScheduler jest nazwą pola instancji
- Adnotacja umożliwia również bezpośrednie podanie nazwy zasobu (atrybut name), pod którą można go odszukać w kontekście, która jest względna do przestrzeni java:comp/env. Podobny mechanizm działa dla właściwości (np. udekorowanie setExamScheduler jest równoznaczne z udekorowaniem pola examScheduler).
Typy komponentów mogących korzystać z DI (to był właśnie powód lektury rozdziału 5!):
- servlety, filtry, metody obsługujące zdarzenia (ang. event handlers)
- JSP - klasy znaczników, metody obsługujące zdarzenia związane z bibliotekami znaczników (ang. tag library event listeners)
- JSF - komponenty zarządzane o zasięgu innym niż none (ang. scoped managed beans)
- JAX-WS - końcówki serwisów (ang. service endpoints), klasy komponentów
- EJB - komponenty i metody przechwytujące (ang. interceptors)
- Klient aplikacyjny (ang. application client) - metoda main oraz metoda zwrotna uwierzytelniająca JAAS
Adnotacje mogą być związane z samą klasą. W takim przypadku należy podać nazwę zależnego zasobu. Nie powoduje to faktycznego wstrzelenia zależności, a jedynie deklarację pozycji w kontekście komponentu. Niestety, nie odkryłem jeszcze sytuacji, w której chciałbym skorzystać z tej możliwości - wydaje mi się, że jest to po prostu ukłon w stronę administratora, że korzystamy z takiego zasobu wprost, poprzez operacje JNDI, aby wiedział, co należy dostarczyć w środowisku, tj. serwerze aplikacyjnym, aby komponent działał poprawnie (a może jest to układ do samego siebie, w końcu skoro przekazujemy komponent do wykorzystania, to chcemy, aby błedy typu brak zasobów nie wpływał na stan emocjonalny klienta ;-))
Udekorowanie klas może odbywać się na dowolnym poziomie hierarchi klas komponentu. Nie ma znaczenia, że klasa, z której dziedziczy komponent nie jest komponentem podlegającym DI. DI podlega zasadom widzialności pól i metod w Javie, co oznacza, że wszystko, co widoczne w klasie podlegającej DI może zostać udekorowane (mimo, że fizycznie nie występuje w samej klasie mogącej zażądać DI). Klasa pochodna ma prawo nadpisać adnotacje, tj. zmienić typ wstrzeliwanego zasobu, czy nawet zadeklarować brak DI.
Deklaracja składowej środowiska (zasób bądź zmienna) odbywa się albo za pomocą adnotacji, albo wpisów do deskryptora instalacji. Istotna zmiana w Java EE 5 polega na możliwości zaniechania deskryptora na rzecz domyślnych wartości zależności bądź ich deklaracji i konfiguracji za pomocą adnotacji (ale to juz było wiadomo z EJB3 Simplified). Ta sama składowa może być zadeklarowana poprzez adnotację i deskryptora instalacji (w kolejności ich ważności, czyli wartość z deskryptora jest ważniejsza). Jest to sposób na nadpisanie wartości przez osobę składającą aplikację z komponentów czy administratora (bez konieczności posiadania kodu źródłowego, gdzie zadeklarowano, lub nie, zależności poprzez adnotacje). Nie powinno się korzystać z DI w deskryptorze instalacji do pól lub metod, które nie zostały do tego przeznaczone (czyli możliwa jest, ale nie zalecana, sytuacja, gdzie administrator zmodyfikuje deskryptor instalacji - to mu wolno - i wstrzeli zasób do pola/metody, która nie została przez programistę udekorowana - Ale jazda! Szanujmy administratorów! ;-)).
Reguły rozwiązywania wartości elementu środowiska zadeklarowanego za pomocą adnotacji i nadpisanego przez deskryptor instalacji:
- Wartość odszukiwana jest w JNDI na podstawie nazwy domyślnej lub podanej explicite
- Typ określony w deskryptorze instalacji musi odpowiadać typowi pola bądź właściwości (tj. parametrowi wejściowemu metody modyfikującej)
- Opis w deskryptorze nadpisuje description z adnotacji
- Miejsce wstrzelenia (jeśli podane) musi wskazywać na udekorowane pole lub metodę modyfikującą
- res-sharing-scope (jeśli podane) nadpisuje shareable z adnotacji (nie zaleca się nadpisywania jej, gdyż może zaburzyć działanie komponentu)
- res-auth (jeśli podane) nadpisuje authenticationType z adnotacji (nie zaleca się nadpisywania jej, gdyż może zaburzyć działanie komponentu)
Specyfikacja zawiera obowiązki poszczególnych ról występujących podczas tworzenia aplikacji - dostawcy komponentu, osoby składającej aplikację, administratora i dostawcy serwera aplikacyjnego. W ten sposób opisano wszystkie rodzaje pozycji kontekstu i ich konfigurację względem ról.
Proste pozycje środowiska (ang. simple environment entries)
Odpowiadają pozycjom, których wartość jest typem opakowującym typ prosty w Javie wraz z java.lang.String (Character, Byte, etc.)Pole lub metoda może być udekorowana przez @Resource. Kontener "rozpakuje" typ opakowujący na jego odpowiednik prosty (ang. Java unboxing). authenticationType i shareable nie mogą być podane (nie mają zastosowania).
Zawsze istnieje możliwość wyszukania pozycji środowiska w java:comp/env.
// konfiguracja wartości pola dostępna administratorowi
@Resource int iloscPoprawnychProb;
Dostawca komponentu deklaruje wpisy środowiska za pomocą adnotacji bądź deskryptora instalacji (env-entry). Zasięg widoczności wpisu jest wyłącznie do komponentu, który go zawiera. Ta sama nazwa wpisu może pojawić się wielokrotnie dla różnych komponentów.
Poza deklaracją elementu środowiska poprzez adnotację (w ten sposób deklarujemy, które pole/właściwość podlega DI) mamy możliwość zadeklarować wstrzelenie wartości elementu środowiska bez konieczności korzystania z adnotacji za pomocą znacznika injection-target (w obszarze znacznika env-entry) - uwaga na programowanie w XML znane i (nie)lubiane z Jelly - administratorzy mają kolejną zabawkę, aby instalacja aplikacji trwała latami.
Istnieje możliwość deklarowania wartości domyślnej w kodzie komponentu.
Referencje do komponentów EJB
Administrator wiąże zależności komponentów od komponentu EJB z jego interfejsem domowym lub instancją. Wiązania następują poprzez logiczne nazwy - referencje EJB.Istnieje również możliwość wiązania referencji EJB z jednego komponentu do EJB w pliku ejb-jar w deskryptorze instalacji bądź poprzez adnotację.
Adnotacja @EJB przypisywana jest do pola albo metody i jedynie dla dowiązania do komponentu sesyjnego (niby wiadome, ale i tak było to dla mnie duużym zaskoczeniem).
Referencja może być do lokalnego/zdalnego interfejsu domowego (EJB 2.1 i poprzednie) albo do interfejsu biznesowego (EJB 3.0). Jeśli korzysta się z referencji do interfejsu biznesowego (EJB3) wstrzelona zostanie już instancja EJB.
Istnieje możliwość precyzyjnego podania wartości adnotacji (z częściowym wykorzystaniem wartości domyślnych - patrz: konfiguracja przez nadpisywanie).
Mimo, że referencje do EJB są elementami środowiska to env-entry nie ma zastosowania. Korzysta się z adnotacji (kod źródłowy) albo znaczników ejb-ref lub ejb-local-ref (deskryptor instalacji).
Opcjonalny znacznik ejb-link precyzuje położenie zależnego komponentu EJB w aplikacji przemysłowej (ear). Można wykorzystać go do przypisywania nazwy logicznej komponentom o tych samych nazwach.
Referencje do fabryki połączeń z zarządcami zasobów (ang. resource manager connection factory)
Faryka połączeń z zarządcami zasobów jest obiektem tworzącym połączenia do zarządcy zasobów (np. javax.sql.DataSource jest fabryką dla java.sql.Connection).Pole lub metoda może być udekorowana @Resource. Elementy authenticationType i shareable służą do uszczegółowienia konfiguracji dostępu do zasobów.
Specyfikacja zaleca, aby fabryki połączeń danego typu były związane z podgałęziami java:comp/env, tj.
@Resource javax.sql.DataSource employeeAppDB;
- java:comp/env/jdbc dla fabryk połączeń JDBC (javax.sql.DataSource)
- java:comp/env/jms dla fabryk połączeń JMS z systemami przesyłania komunikatów (javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory, javax.jms.ConnectionFactory)
- java:comp/env/mail dla połączeń JavaMail (javax.mail.Session)
- java:comp/env/url dla połączeń poprzez URLConnection (java.net.URL)
Referencje kanałów komunikacji (ang. message destination references)
Tutaj nie ma wiele zmian porównując z referencjami fabryk połączeń. Korzystamy z @Resource bez authenticationType oraz shareable (nie mają zastosowania).Za pomocą adnotacji @Resource, nie ma możliwości zdefiniowania, czy związany zasób służy do odbioru czy wysyłania komunikatów. Służy do tego deskryptor instalacji z pomocą znacznika message-destination-ref.
@Resource javax.jms.Queue stockQueue;
Referencje UserTransaction
Niektóre komponenty mają możliwość zarządzania tranzakcją (rozpoczęcie, zatwierdzenie i wycofanie). Do dowiązania do obiektu UserTransaction służy java:comp/UserTransaction albo adnotacja @Resource dla typu userTransaction.Wstrzelenie lub udostępnienie zasobu w kontekście jest kontrolowane przez serwer aplikacyjny i mimo zadeklarowania referencje mogą nie istnieć (ale nie doszedłem, które są takimi wrażliwymi typami komponentów).
@Resource UserTransaction tx;
Referencje do TransactionSynchronizationRegistry
Interfejs TransactionSynchronizationRegistry może być wykorzystywany przez komponenty systemowe jak zarządcy utrwalania stanu (ang. persistence managers) dla EJB lub komponentów aplikacji internetowych.Możliwe dekorowanie @Resource albo wyszukanie java:comp/TransactionSynchronizationRegistry w JNDI.
Wstrzelenie lub udostępnienie zasobu w kontekście jest kontrolowane przez serwer aplikacyjny i mimo zadeklarowania referencje mogą nie istnieć (ale nie doszedłem, które są takimi wrażliwymi typami komponentów).
Referencje do szyn ORB
Wstrzelenie za pomocą @Resource lub odszukanie java:comp/ORB w JNDI.Serwer aplikacyjny musi dostarczyć obiekt do każdego typu komponentu poza appletami.
@Resource ORB orb;
Referencje do jednostek zapisu (ang. persistence unit references)
Udostępnia logiczną nazwę dla fabryki utrwalania stanu komponentów encyjnych.Jednostki zapisu definiowane są w persistence.xml zgodnie z zasadami opisanymi w specyfikacji Java Persistence API (część specyfikacji Enterprise JavaBeans 3.0).
Pole lub metoda może zostać udekorowana adnotacją @PersistenceUnit. Opcjonalnie można podać nazwę jednostki w JNDI za pomocą elementu name. Element unitName wskazuje na nazwę jednostki jak zdefiniowano w persistence.xml.
Specyfikacja zaleca, aby wszystkie jednostki utrwalania były dostępne w poddrzewie java:comp/env/persistence.
@PersistenceUnit
EntityManagerFactory emf;
@PersistenceUnit(unitName="InventoryManagement")
EntityManagerFactory inventoryEMF;
Deklaracja zależności w deskryptorze instalacji odbywa się poprzez persistence-unit-ref.
Identyczne nazwy jednostek (wykorzystywanych przez różne komponenty) można przypisać do nazw logicznych w deskryptorze instalacji z wykorzystaniem '#' w znaczniku persistence-unit-name.
<persistence-unit-name>
../lib/inventory.jar#InventoryManagement
</persistence-unit-name>
Referencje do kontekstów utrwalania (ang. persistence context references)
Udostępnia logiczną nazwę dla kontekstu utrwalania stanu komponentów encyjnych.Jednostki zapisu definiowane są w persistence.xml zgodnie z zasadami opisanymi w specyfikacji Java Persistence API (część specyfikacji Enterprise JavaBeans 3.0).
Pole lub metoda może zostać udekorowana adnotacją @PersistenceContext. Opcjonalnie można podać nazwę jednostki w JNDI za pomocą elementu name. Element unitName wskazuje na nazwę jednostki jak zdefiniowano w persistence.xml. Opcjonalny element type wskazuje na rodzaj kontekstu:
- tranzakcyjny (ang. transaction-scoped) - domyślny
- rozszeżony (ang. extended)
albo
@PersistenceContext
EntityManager em;
Deklaracja w deskryptorze instalacji odbywa się poprzez persistence-context-ref. Istnieje również możliwość zadeklarowania miejsca wstrzelenia zależności poprzez deskryptor instalacji.
@Resource SessionContext ctx;
...
EntityManager em = (EntityManager) ctx.lookup("persistence/InventoryAppMgr");
23 stycznia 2007
Powrót do Polski, wirtualny JUG, Studencki Festiwal Informatyczny w Krakowie i głosowanie o polskie tłumaczenie annotation
Po 2 dniach spędzonych w Wiedniu (Austria) z przyjmnością otworzyłem moją skrzynkę pocztową, w której znalazłem kilka ciekawych wiadomości. Jedną z nich na pewno była inicjatywa założenia wirtualnego JUG, o której pisze na swoim blogu pietruha. Pomysł bardzo mi się spodobał i chciałbym zestawić taką imprezkę w ramach Warszawa JUG (nawet nazwy podobne, jakby stworzone dla siebie ;-)). Zabieram się jutro z samego rana za rozesłanie wiadomości do ludzi od Noc Linuksożerców oraz wierzę, że znajdzie się kilka osób na jdn.pl i Warszawa JUG, którzy pomogą w realizacji pomysłu. Wielkie pomysły rodzą się w wielkich umysłach i pomysł wirtualnego JUGa zdecydowanie zasługuje na miano genialnego. Brawo pietruha!
Druga wiadomość była równie elektryzująca (w pozytywnym tego słowa znaczeniu). Zresztą jej treść sama wyjaśnia mój stan (ufam, że autor zaproszenia nie zechce zdjąć tej części wiadomości z mojego notatnika).
Piszę w imieniu komitetu organizacyjnego Studenckiego Festiwalu Informatycznego w Krakowie, który jest niekomercyjną inicjatywą Naukowych Kół Studenckich czterech największych uczelni tego miasta.
Chciałem spytać, czy zechciałby Pan może uświetnić grono prelegentów naszego festiwalu?
Nie trzeba więcej, aby noc po powrocie do domu była wywrócona do góry nogami. Nie należę do osób lekkiego serca (ang. faint-hearted), ale możliwość uczestniczenia w roli prelegenta na festiwalu jest wyjątkowym wyróżnieniem, które pozytywnie mną wstrząsnęła. Zawsze marzyłem o zaktywizowaniu polskiej społeczności użytkowników technologii Java za pomocą różnego rodzaju spotkań, konferencji, paneli dyskusyjnych, etc., ale nie sądziłem, że będę mógł swoje marzenie realizować z pomocą polskich uczelni. Zaczęło się od warszawskiego MiMUW, następnie zaproszono mnie na Politechnikę Poznańską, a teraz mógłbym uczestniczyć w inicjatywie czterech największych uczelni krakowskich - Akademii Ekonomicznej, Akademii Górniczo-Hutniczej, Politechniki Krakowskiej oraz Uniwersytetu Jagiellońskiego. Czyżby Św. Mikołaj zapomniał o mnie i dopiero teraz wysyła mi prezenty? ;-)
Ostatnia wiadomość, o której chciałem napisać, to napywające do mnie uwagi odnośnie tłumaczeń, jakie stosuje w moim notatniku (aka blogu). Jednym z bardziej kontrowersyjnych słów jest annotation. Moje tłumaczenie - annotacja - wzbudziło wiele uwag o poprawę na adnotacja, z czym nie mogę się zgodzić. Nie pretenduję do miana polskiego tłumacza, więc o wyrażenie opinii poprosiłem społeczność Java na grupie pl.comp.lang.java. Podsumowanie głosowania za 7 dni. Słowo annotation będzie jednym z częściej stosowanym w 2007, więc ujednolicenie jego tłumaczenia znacznie poprawi mój techniczny jezyk. Głosowanie odbywa się w wątku Głosowanie: polskie tłumaczenie słowa annotation.
A tak poza tym, podczas pobytu w Austrii, zabrałem się za lekturę EJB3 Core, ale szybko zanurzyłem się w rozdziale 5. specyfikacji Java EE 5 - Chapter 5: Resources, Naming, and Injection. Zmusiła mnie do tego niewiedza o tym, kto może, a kto nie korzystać z dobrodziejstw wstrzeliwania zależności. Wrażenia dopiero jutro...ekh...już dzisiaj, ale później. Pora spać! (tylko jak tu spać po tym wszystkim?!?!).
Druga wiadomość była równie elektryzująca (w pozytywnym tego słowa znaczeniu). Zresztą jej treść sama wyjaśnia mój stan (ufam, że autor zaproszenia nie zechce zdjąć tej części wiadomości z mojego notatnika).
Piszę w imieniu komitetu organizacyjnego Studenckiego Festiwalu Informatycznego w Krakowie, który jest niekomercyjną inicjatywą Naukowych Kół Studenckich czterech największych uczelni tego miasta.
Chciałem spytać, czy zechciałby Pan może uświetnić grono prelegentów naszego festiwalu?
Nie trzeba więcej, aby noc po powrocie do domu była wywrócona do góry nogami. Nie należę do osób lekkiego serca (ang. faint-hearted), ale możliwość uczestniczenia w roli prelegenta na festiwalu jest wyjątkowym wyróżnieniem, które pozytywnie mną wstrząsnęła. Zawsze marzyłem o zaktywizowaniu polskiej społeczności użytkowników technologii Java za pomocą różnego rodzaju spotkań, konferencji, paneli dyskusyjnych, etc., ale nie sądziłem, że będę mógł swoje marzenie realizować z pomocą polskich uczelni. Zaczęło się od warszawskiego MiMUW, następnie zaproszono mnie na Politechnikę Poznańską, a teraz mógłbym uczestniczyć w inicjatywie czterech największych uczelni krakowskich - Akademii Ekonomicznej, Akademii Górniczo-Hutniczej, Politechniki Krakowskiej oraz Uniwersytetu Jagiellońskiego. Czyżby Św. Mikołaj zapomniał o mnie i dopiero teraz wysyła mi prezenty? ;-)
Ostatnia wiadomość, o której chciałem napisać, to napywające do mnie uwagi odnośnie tłumaczeń, jakie stosuje w moim notatniku (aka blogu). Jednym z bardziej kontrowersyjnych słów jest annotation. Moje tłumaczenie - annotacja - wzbudziło wiele uwag o poprawę na adnotacja, z czym nie mogę się zgodzić. Nie pretenduję do miana polskiego tłumacza, więc o wyrażenie opinii poprosiłem społeczność Java na grupie pl.comp.lang.java. Podsumowanie głosowania za 7 dni. Słowo annotation będzie jednym z częściej stosowanym w 2007, więc ujednolicenie jego tłumaczenia znacznie poprawi mój techniczny jezyk. Głosowanie odbywa się w wątku Głosowanie: polskie tłumaczenie słowa annotation.
A tak poza tym, podczas pobytu w Austrii, zabrałem się za lekturę EJB3 Core, ale szybko zanurzyłem się w rozdziale 5. specyfikacji Java EE 5 - Chapter 5: Resources, Naming, and Injection. Zmusiła mnie do tego niewiedza o tym, kto może, a kto nie korzystać z dobrodziejstw wstrzeliwania zależności. Wrażenia dopiero jutro...ekh...już dzisiaj, ale później. Pora spać! (tylko jak tu spać po tym wszystkim?!?!).
18 stycznia 2007
EJB3 w Poznaniu i Chapter 10 - Metadata Annotations - koniec lektury EJB3 Simplified
Veni, vidi, vici! Poznań rozkopany, padało, więc nie było co podziwiać. Dobrze, że frekwencja dopisała (około 15-20 osób). Prezentacja EJB3 trwała 3 godziny i pozwoliła mi na poznanie kolejnych udoskonaleń EJB3 w praktyce. Ekipa tak się rozgrzała na koniec (zaraz po tym, kiedy się wyspali, kiedy ja opowiadałem), że padały pomysły utworzenia aplikacji tak, że ostatecznie dotknęliśmy @Entity i @PersistenceUnit i przykład się rozwalił ;-) W trakcie podróży doczytałem o wyjątkach aplikacyjnych i systemowych, więc pojawiły się kolejne 2 slajdy. Wydaje mi się, że wypadło nieźle. Coś wspominali o kolejnych wojażach, ale to na razie odłożymy - czas zabrać się za EJB Core Contracts and Requirements (w skrócie EJB3 Core).
Zanim zabiorę się za EJB3 Core, relacja z lektury EJB3 Simplified i jej ostatniego rozdziału Chapter 10 Metadata Annotations.
Patrząc na merytoryczną stronę dokumentu, rozdział 10 jest rozdziałem ostatnim, zamykającym uproszczony opis zmian w EJB3 (następujące po nim rozdziały to bibliografia - Chapter 11 Related Documents - oraz historia zmian - Appendix A Revision History). Mimo, że występuje jako ostatni, zawarte w nim informacje dotyczą bodaj najbardziej rewolucyjnych zmian w specyfikacji EJB3 - annotacji. Pojawiły się one już wcześniej przy opisie poszczególnych typów komponentów (SLSB, SFSB i MDB), jednak w tym rozdziale znajdziemy opis nie tylko tych należących do pakietu javax.ejb, ale również javax.interceptor, javax.annotation i javax.annotation.security (nie znajdziemy tutaj jednak annotacji związanych z Java Persistence API - javax.persistence). Na uwagę może również zwrócić ilość stron rozdziału, aż 10, co ustawia go na I miejscu pod względem objętości.
UWAGA 1: Wszystkie annotacje oznaczone są z Retention=RUNTIME, a więc są dostępne dla mechanizmu refleksji podczas instalacji i uruchomienia komponentów.
UWAGA 2: Elementy value annotacji nie muszą być poprzedzone nazwą parametru value i bezpośrednio definiuje się wartość.
Rozdział rozpoczyna się przedstawieniem annotacji wyznaczających typy komponentów.
Wypadałoby stworzyć tabelę dla uproszczenia prezentacji annotacji - nazwa annotacji, metoda/klasa, parametry, domyślna wartość, znaczenie. Może jednak później ;-)
Annotacje związane z bezstanowym komponentem sesyjnym (ang. SLSB - stateless session bean)
@Stateless - określenie klasy jako bezstanowy komponent sesyjny. Atrybuty:
Annotacje związane ze stanowym komponentem sesyjnym (ang. SFSB - stateful session bean)
@Stateful - określenie klasy jako stanowy komponent sesyjny. Atrybuty:
Określenie metody Init jest jedynie wymagane dla komponentów SFSB, które dostęne są dla klientów EJB 2.1 poprzez interfejsy oznaczone @RemoteHome lub @LocalHome.
Atrybuty:
Atrybuty:
@MessageDriven - związana klasa jest klasą MDB. Atrybuty:
@Remote - dekoruje klasę komponentu lub interfejs biznesowy określająca zdalny interfejs biznesowy komponentu.
@Local - związana z klasą komponentu lub interfejsem biznesowym określająca lokalny interfejs biznesowy komponentu. Konieczny, jeśli klasa komponentu implementuje interfejsy inne niż: java.io.Serializable, java.io.Externalizable lub interfejsy z pakietu javax.ejb.
Atrybuty @Remote i @Local:
Terminy i korzystanie z annotacji jest przeznaczone dla aplikacji migrujących do EJB3 z poprzednich wersji.
@RemoteHome - zdalny interfejs domowy komponentu
@TransactionManagement - określenie, kto odpowiada za zarządzanie transakcją - kontener (ang. CMTD - container-managed transaction demarcation) czy komponent (ang. BMTD - bean-managed transaction demarcation)
Udekorowaniu podlegają klasa komponentu bądź poszczególne metody interfejsu biznesowego (ale wyłącznie metody interfejsu biznesowego). Udekorowanie klasy określa wymaganie transakcyjne dla wszystkich metod interfejsu biznesowego komponentu. Udekorowanie metody interfejsu biznesowego określa stan transakcji wyłącznie dla niej samej. Jeśli udekorowano i klasę i metodę/-y, wtedy wartość annotacji dla metody jest ostateczną wartością dla niej (oczywiście nie wpływa to na konfigurację pozostałych metod).
Atrybuty:
@Interceptors - określenie jednej bądź wielu klas interceptorów. Udekorowaniu podlegają klasa komponentu i metody biznesowe. Atrybuty:
@ExcludeDefaultInterceptors - przypisana do klasy komponentu wskazując, aby wykonanie domyślnych interceptorów (tych zadeklarowanych w deskryptorze instalacji - ejb-jar.xml) dla wszystkich metod biznesowych jest wyłączone. Udekorowanie metody biznesowej to wyłączenie domyślnych interceptorów tylko dla niej.
@ExcludeClassInterceptors - służy do udekorowania metody biznesowej, aby wyłączyć wykonanie interceptorów przypisanych do komponentu (na poziomie klasy komponentu, patrz @Interceptors), ale nie wyłącza interceptorów domyślnych (tych z deskryptora instalacji)
@PostConstruct, @PreDestroy, @PrePassivate, @PostActivate - "annotacje zwrotne" przypisywane do metod dla określenia metod nie-biznesowych wywoływanych podczas zdarzeń z życia komponentu - utworzenia, usunięcia, pasywacji i aktywacji (dwa ostatnie wyłącznie dla SFSB).
Annotacja @Timeout
@Timeout - przypisana do metody komponentów SLSB oraz MDB, która będzie wywoływana po wygaśnięciu ważności zegara (więcej o tym w rozdziale Chapter 18 Timer Service w EJB3 Core).
Annotacje związane z wyjątkami
@ApplicationException - przypisana do klasy wyjątków kontrolowanych (ang. checked exception) i niekontrolowanych (ang. unchecked exception), aby wskazać wyjątki aplikacyjne, które będą przekazane klientowi bezpośrednio bez opakowywania ich w EJBException.
Annotacje należą do pakietu javax.annotation.security i są zaprezentowane dla kompletności specyfikacji.
@DeclareRoles - przypisana do klasy komponentu, aby zadeklarować role wykorzytane przez komponent
@PermitAll - przypisana do metody, która może zostać wywołana przez dowolną rolę w systemie. Jest to ustawienie domyślne. Przypisana do klasy dotyczy wszystkich metod biznesowych komponentu podczas, gdy przypisana do metody dotyczy wyłącznie jej nadpisując wszelkie ustawienia związane z klasą.
@DenyAll - specyfikuje, że żadna z ról nie ma prawa wykonać metody, tj. wykonanie metody jest niemożliwe.
@RunAs - specyfikuje rolę, jaka będzie przypisana z wykonaniem metod (właściwość run-as).
Annotacje związane z referencjami do EJB
@EJB - ustanawia referencję do interfejsu biznesowego lub domowego komponentu.
Annotacje związane z referencjami do zasobów zewnętrznych (innych niż EJB)
@Resource i @Resources należą do pakietu javax.annotation.
@Resource - określa zależność od zewnętrznego zasobu dostępnym w środowisku komponentu.
Zanim zabiorę się za EJB3 Core, relacja z lektury EJB3 Simplified i jej ostatniego rozdziału Chapter 10 Metadata Annotations.
Patrząc na merytoryczną stronę dokumentu, rozdział 10 jest rozdziałem ostatnim, zamykającym uproszczony opis zmian w EJB3 (następujące po nim rozdziały to bibliografia - Chapter 11 Related Documents - oraz historia zmian - Appendix A Revision History). Mimo, że występuje jako ostatni, zawarte w nim informacje dotyczą bodaj najbardziej rewolucyjnych zmian w specyfikacji EJB3 - annotacji. Pojawiły się one już wcześniej przy opisie poszczególnych typów komponentów (SLSB, SFSB i MDB), jednak w tym rozdziale znajdziemy opis nie tylko tych należących do pakietu javax.ejb, ale również javax.interceptor, javax.annotation i javax.annotation.security (nie znajdziemy tutaj jednak annotacji związanych z Java Persistence API - javax.persistence). Na uwagę może również zwrócić ilość stron rozdziału, aż 10, co ustawia go na I miejscu pod względem objętości.
UWAGA 1: Wszystkie annotacje oznaczone są z Retention=RUNTIME, a więc są dostępne dla mechanizmu refleksji podczas instalacji i uruchomienia komponentów.
UWAGA 2: Elementy value annotacji nie muszą być poprzedzone nazwą parametru value i bezpośrednio definiuje się wartość.
Rozdział rozpoczyna się przedstawieniem annotacji wyznaczających typy komponentów.
Wypadałoby stworzyć tabelę dla uproszczenia prezentacji annotacji - nazwa annotacji, metoda/klasa, parametry, domyślna wartość, znaczenie. Może jednak później ;-)
Annotacje związane z bezstanowym komponentem sesyjnym (ang. SLSB - stateless session bean)
@Stateless - określenie klasy jako bezstanowy komponent sesyjny. Atrybuty:
- name - ejb-name dla komponentu (domyślnie niekwalifikowana nazwa klasy, tj. nazwa bez pakietu)
- mappedName - specyficzna dla serwera nazwa, do której należy dowiązać komponent (globalna nazwa JNDI)
- description - opis komponentu
Annotacje związane ze stanowym komponentem sesyjnym (ang. SFSB - stateful session bean)
@Stateful - określenie klasy jako stanowy komponent sesyjny. Atrybuty:
- name - ejb-name dla komponentu (domyślnie niekwalifikowana nazwa klasy, tj. nazwa bez pakietu)
- mappedName - specyficzna dla serwera nazwa, do której należy dowiązać komponent (globalna nazwa JNDI)
- description - opis komponentu
Określenie metody Init jest jedynie wymagane dla komponentów SFSB, które dostęne są dla klientów EJB 2.1 poprzez interfejsy oznaczone @RemoteHome lub @LocalHome.
Atrybuty:
- value - używana przy SFSB dla określenia pojedyńczej metody, z którą annotacja jest związana, kiedy interfejs domowy posiada więcej niż jedną metodę create<METODA>.
Atrybuty:
- retainIfException (domyślnie false) - wskazuje, że komponent powinien pozostać w systemie, jeśli wystąpi wyjątek aplikacyjny podczas wywołania metody.
@MessageDriven - związana klasa jest klasą MDB. Atrybuty:
- name - ejb-name dla komponentu (domyślnie niekwalifikowana nazwa klasy, tj. nazwa bez pakietu)
- mappedName - nazwa specyficzna dla serwera, do której należy dowiązać komponent (np. globalna nazwa JNDI dla kolejki)
- description - opis komponentu
- messageListenerInterface - interfejs komunikacyjny. Musi być podany, jeśli MDB nie implementuje interfejsu lub implementuje więcej niż jeden interfejs inny niż java.io.Serializable, java.io.Externalizable lub dowolny interfejs z javax.ejb.
- activationConfig - właściwości aktywacyjne komponentu (pary propertyName i propertyValue)
@Remote - dekoruje klasę komponentu lub interfejs biznesowy określająca zdalny interfejs biznesowy komponentu.
@Local - związana z klasą komponentu lub interfejsem biznesowym określająca lokalny interfejs biznesowy komponentu. Konieczny, jeśli klasa komponentu implementuje interfejsy inne niż: java.io.Serializable, java.io.Externalizable lub interfejsy z pakietu javax.ejb.
Atrybuty @Remote i @Local:
- value - lista interfejsów biznesowych
Terminy i korzystanie z annotacji jest przeznaczone dla aplikacji migrujących do EJB3 z poprzednich wersji.
@RemoteHome - zdalny interfejs domowy komponentu
- value - nazwa klasy interfejsu (typy Class)
- value - nazwa klasy interfejsu (typu Class)
@TransactionManagement - określenie, kto odpowiada za zarządzanie transakcją - kontener (ang. CMTD - container-managed transaction demarcation) czy komponent (ang. BMTD - bean-managed transaction demarcation)
- value - CONTAINER (domyślnie) lub BEAN
Udekorowaniu podlegają klasa komponentu bądź poszczególne metody interfejsu biznesowego (ale wyłącznie metody interfejsu biznesowego). Udekorowanie klasy określa wymaganie transakcyjne dla wszystkich metod interfejsu biznesowego komponentu. Udekorowanie metody interfejsu biznesowego określa stan transakcji wyłącznie dla niej samej. Jeśli udekorowano i klasę i metodę/-y, wtedy wartość annotacji dla metody jest ostateczną wartością dla niej (oczywiście nie wpływa to na konfigurację pozostałych metod).
Atrybuty:
- value - MANDATORY, REQUIRED (domyślny), REQUIRES_NEW, SUPPORTS, NOT_SUPPORTED, NEVER
@Interceptors - określenie jednej bądź wielu klas interceptorów. Udekorowaniu podlegają klasa komponentu i metody biznesowe. Atrybuty:
- value - klasy interceptorów
@ExcludeDefaultInterceptors - przypisana do klasy komponentu wskazując, aby wykonanie domyślnych interceptorów (tych zadeklarowanych w deskryptorze instalacji - ejb-jar.xml) dla wszystkich metod biznesowych jest wyłączone. Udekorowanie metody biznesowej to wyłączenie domyślnych interceptorów tylko dla niej.
@ExcludeClassInterceptors - służy do udekorowania metody biznesowej, aby wyłączyć wykonanie interceptorów przypisanych do komponentu (na poziomie klasy komponentu, patrz @Interceptors), ale nie wyłącza interceptorów domyślnych (tych z deskryptora instalacji)
@PostConstruct, @PreDestroy, @PrePassivate, @PostActivate - "annotacje zwrotne" przypisywane do metod dla określenia metod nie-biznesowych wywoływanych podczas zdarzeń z życia komponentu - utworzenia, usunięcia, pasywacji i aktywacji (dwa ostatnie wyłącznie dla SFSB).
Annotacja @Timeout
@Timeout - przypisana do metody komponentów SLSB oraz MDB, która będzie wywoływana po wygaśnięciu ważności zegara (więcej o tym w rozdziale Chapter 18 Timer Service w EJB3 Core).
Annotacje związane z wyjątkami
@ApplicationException - przypisana do klasy wyjątków kontrolowanych (ang. checked exception) i niekontrolowanych (ang. unchecked exception), aby wskazać wyjątki aplikacyjne, które będą przekazane klientowi bezpośrednio bez opakowywania ich w EJBException.
- rollback - (domyślnie false) - wskazuje, czy kontener musi wycofać transakcję przy rzuceniu wyjątku przez metodę biznesową.
Annotacje należą do pakietu javax.annotation.security i są zaprezentowane dla kompletności specyfikacji.
@DeclareRoles - przypisana do klasy komponentu, aby zadeklarować role wykorzytane przez komponent
- value - lista ról (typu String)
@PermitAll - przypisana do metody, która może zostać wywołana przez dowolną rolę w systemie. Jest to ustawienie domyślne. Przypisana do klasy dotyczy wszystkich metod biznesowych komponentu podczas, gdy przypisana do metody dotyczy wyłącznie jej nadpisując wszelkie ustawienia związane z klasą.
@DenyAll - specyfikuje, że żadna z ról nie ma prawa wykonać metody, tj. wykonanie metody jest niemożliwe.
@RunAs - specyfikuje rolę, jaka będzie przypisana z wykonaniem metod (właściwość run-as).
Annotacje związane z referencjami do EJB
@EJB - ustanawia referencję do interfejsu biznesowego lub domowego komponentu.
- name - nazwa komponentu, pod którą można go odszukać w środowisku
- beanInterface - interfejs biznesowy lub domowy komponentu
- beanName - wskazuje na nazwę komponentu (domyślną lub tą podaną jako element name w annotacjach @Stateful lub @Stateless lub ostatecznie jako wartość ejb-name w deskryptorze instalacji). Istnieje możliwość wyróżnienia komponentu, jeśli istnieje więcej komponentów realizujących ten sam interfejs biznesowy należących do tego samego pliku jar. Dla komponentów z innego pliku jar należących do tej samej aplikacji przemysłowej podajemy ścieżkę względną względem pliku jar, do którego należy komponent korzystający z @EJB, rozdzieloną '#' od nazwy komponentu.
- mappedName - specyficzna dla serwera nazwa, do której komponent powinien być przypisany. UWAGA na możliwą nieprzenośność.
Annotacje związane z referencjami do zasobów zewnętrznych (innych niż EJB)
@Resource i @Resources należą do pakietu javax.annotation.
@Resource - określa zależność od zewnętrznego zasobu dostępnym w środowisku komponentu.
- name - nazwa zależności, pod jaką jest znana w środowisku
- type - typ fabryki połączeń zarządcy zasobów
- authenticationType - CONTAINER (domyślnie), APPLICATION - kto odpowiada za uwierzytelnienie
- shareable - (domyślnie true) współdzielność połączeń zarządcy zasobów
- mappedName - specyficzna dla serwera nazwa, do której komponent powinien być przypisany. UWAGA na możliwą nieprzenośność.
17 stycznia 2007
Wykład o EJB3 w Instytucie Informatyki Politechniki Poznańskiej
To już jutro! W końcu mogę opublikować coś z czego cieszę się już od 2 tygodni - mam urlop, bilet, więc jesli tylko pociąg nie nawali będę w Poznaniu jutro o 11:30.
Jadę do Poznania do Instytutu Informatyki Politechniki Poznańskiej, gdzie wygłoszę wykład o Enterprise JavaBeans 3.0. Wykład prowadzony będzie na przedmiocie Technologie Programistyczne - Biznesowe Systemy Rozproszone w ramach specjalizacji magisterskiej Technologie Wytwarzania Oprogramowania prowadzonej przez pana dr inż. Dawida Weissa. Nie mogłem wyobrazić sobie lepszego podsumowania lektury specyfikacji EJB3 Simplified, którą właśnie skończyłem (dzisiaj jednak nie zdążę już zrelacjonować jej treści, a jest o czym pisać - annotacje i to nie tylko te z javax.ejb, ale i te z Java EE 5 i jakie jest ich wykorzystanie w EJB3 - ale o tym dopiero jutro).
Wracając do mojego jutrzejszego wykładu o EJB3 to ciekawy wydaje mi się sposób nawiązania kontaktu z Uczelnią. A potęguje to jeszcze fakt, że zaproszenie od Adama Dudczaka dostałem świeżo po tym jak zaproszono mnie jako prelegenta na konferencji DevCon 2007 (pisałem o tym w jednym z wcześniejszych wpisów). Adam zapytał, czy zgodziłbym się przyjechać, ja na taką propozycję nie mogłem się nie zgodzić i oto jadę. Nie mogę się już doczekać, kiedy pojawię się w Poznaniu!
Wykład rozpoczyna się w Centrum Wykładowym Politechniki Poznańskiej o 11:45 w sali nr 6. Serdecznie zapraszam! I to nie tylko studentów Politechniki. Z pewnością znajdzie się miejsce dla wszystkich zainteresowanych!
Jadę do Poznania do Instytutu Informatyki Politechniki Poznańskiej, gdzie wygłoszę wykład o Enterprise JavaBeans 3.0. Wykład prowadzony będzie na przedmiocie Technologie Programistyczne - Biznesowe Systemy Rozproszone w ramach specjalizacji magisterskiej Technologie Wytwarzania Oprogramowania prowadzonej przez pana dr inż. Dawida Weissa. Nie mogłem wyobrazić sobie lepszego podsumowania lektury specyfikacji EJB3 Simplified, którą właśnie skończyłem (dzisiaj jednak nie zdążę już zrelacjonować jej treści, a jest o czym pisać - annotacje i to nie tylko te z javax.ejb, ale i te z Java EE 5 i jakie jest ich wykorzystanie w EJB3 - ale o tym dopiero jutro).
Wracając do mojego jutrzejszego wykładu o EJB3 to ciekawy wydaje mi się sposób nawiązania kontaktu z Uczelnią. A potęguje to jeszcze fakt, że zaproszenie od Adama Dudczaka dostałem świeżo po tym jak zaproszono mnie jako prelegenta na konferencji DevCon 2007 (pisałem o tym w jednym z wcześniejszych wpisów). Adam zapytał, czy zgodziłbym się przyjechać, ja na taką propozycję nie mogłem się nie zgodzić i oto jadę. Nie mogę się już doczekać, kiedy pojawię się w Poznaniu!
Wykład rozpoczyna się w Centrum Wykładowym Politechniki Poznańskiej o 11:45 w sali nr 6. Serdecznie zapraszam! I to nie tylko studentów Politechniki. Z pewnością znajdzie się miejsce dla wszystkich zainteresowanych!
16 stycznia 2007
JBoss AS 4.0.5 z EJB 3.0 RC9 Patch 1 i NetBeans IDE 5.5.1
Po uaktualnieniu NetBeans IDE do wersji 5.5.1 Daily Build (ze względu na błędne działanie wersji 5.5 z GlassFish v2 b31) postanowiłem sprawdzić jak wygląda współpraca z JBoss AS 4.0.5, szczególnie, że i współpraca z JBoss AS się zepsuła po zmianach w konfiguracji serwera w 4.0.5. Dodatkowo, ostatnia próba zaprezentowania JBoss AS z NetBeans, podczas III spotkania Warszawa JUG, zakończyła się totalną klapą, więc tym bardziej interesowały mnie poprawki w nowszej wersji NetBeans IDE dotyczące JBoss AS (tak przy okazji, właśnie pojawiła się nowa wersja NetBeans IDE 6.0 M6, w której włączono większość z funkcjonalności Java EE). Samo uruchomienie JBoss AS nie stanowiło dla mnie czegoś interesującego, ale możliwość uruchamiania projektów Java EE 5 na JBoss AS z rozszerzeniem EJB 3.0 RC9 Patch 1 było niezwykle kuszące (w końcu to i załoga JBoss AS uczestniczyła w pracach grupy standaryzującej EJB3).
Na moją decyzję o instalacji JBoss AS 4.0.5 wpłynęła również notka o JBoss Seam - A Conversation with Seam, którego powoli rozpoznaję na kolejne IV spotkanie Warszawa JUG. Jak się okazało instalacja całego środowiska i aplikacji opisanej w notce poszła nadzwyczaj zgrabnie ( chociaż początkowo miałem problemy z uruchamianiem JBoss AS w NetBeans IDE, aż zauważyłem, że korzystam z profilu all zamiast default, gdzie zainstalowałem łatę EJB3. Straciłem ponad 2 godziny próbując poukładać informacje jakie miałem nt. integracji NB i JBS. Kolejny raz sen przyniósł rozwiązanie!)
Instalacja JBoss AS 4.0.5 z EJB 3.0 RC9 Patch 1 i uruchomienie w NetBeans 5.5.1 Daily Build jest wystarczająco nieskomplikowana, aby spróbować jej bez pomocy JEMS Installer (nie potrafię tego wytłumaczyć, ale nie specjalnie podoba mi się instalacja oprogramowania w ten sposób - przyzwyczaiłem się, że wystarczy rozpakować paczkę dystrybucyjną do wybranego katalogu i można pracować, a próba ukrycia przede mną poszczególnych kroków instalacyjnych zazwyczaj mnie zniechęca). Po kilku minutach można uruchamiać projekty Java EE 5 na JBoss AS.
Na moją decyzję o instalacji JBoss AS 4.0.5 wpłynęła również notka o JBoss Seam - A Conversation with Seam, którego powoli rozpoznaję na kolejne IV spotkanie Warszawa JUG. Jak się okazało instalacja całego środowiska i aplikacji opisanej w notce poszła nadzwyczaj zgrabnie ( chociaż początkowo miałem problemy z uruchamianiem JBoss AS w NetBeans IDE, aż zauważyłem, że korzystam z profilu all zamiast default, gdzie zainstalowałem łatę EJB3. Straciłem ponad 2 godziny próbując poukładać informacje jakie miałem nt. integracji NB i JBS. Kolejny raz sen przyniósł rozwiązanie!)
Instalacja JBoss AS 4.0.5 z EJB 3.0 RC9 Patch 1 i uruchomienie w NetBeans 5.5.1 Daily Build jest wystarczająco nieskomplikowana, aby spróbować jej bez pomocy JEMS Installer (nie potrafię tego wytłumaczyć, ale nie specjalnie podoba mi się instalacja oprogramowania w ten sposób - przyzwyczaiłem się, że wystarczy rozpakować paczkę dystrybucyjną do wybranego katalogu i można pracować, a próba ukrycia przede mną poszczególnych kroków instalacyjnych zazwyczaj mnie zniechęca). Po kilku minutach można uruchamiać projekty Java EE 5 na JBoss AS.
- Rozpocząłem od rozpakowania wersji JBoss AS 4.0.5.GA do wybranego przeze mnie katalogu, np. c:/apps/jboss
- Pobrałem i rozpakowałem łatę EJB 3.0 Preview RC9 Patch 1 do tymczasowego katalogu, z którego rozpocznie się jej właściwa instalacja - uaktualnienie JBoss AS, np. c:/temp/jboss-EJB-3.0_RC9_Patch_1
- Ustawiłem zmienną JBOSS_HOME, tj. set JBOSS_HOME=c:\apps\jboss
- I w katalogu, gdzie rozpakowałem łatę EJB 3.0 dla JBoss AS (u mnie c:/temp/jboss-EJB-3.0_RC9_Patch_1), wykonałem polecenie
ant -f install.xml -Djboss.server.config=default
Należy pamiętać o zmiennej jboss.server.config ponieważ domyślnie wskazuje na profile all (dlaczego wybrałem default nie mam pojęcia - chyba znalazłem zalecenie o korzystaniu profilu default, ale nie mogę sobie teraz tego przypomnieć).
Polecenie kończy się po około 10 sekundach. - Na stronie Migrating From EJB 3.0 RC8 -> RC9 znajdują się dodatkowe wskazania odnośnie instalacji EJB 3.0 RC9 chyba, że łatano profil all (patrz punkt 4). Ja łatałem profil default, więc musiałem pozbyć się dwóch plików z katalogu %JBOSS_HOME%\server\default\deploy:
- ejb3-clustered-sfsbcache-service.xml
- ejb3-entity-cache-service.xml
- Testowe uruchomienie JBoss AS po instalacji łaty EJB 3.0 nie zaszkodzi.
%JBOSS_HOME%/bin/run -config=<konfiguracja JBoss z łatą EJB3>
U mnie config nie był potrzebny, bo domyślnie skrypt startujący zakłada, że będzie uruchomiony profil default (inaczej niż domyślna wartość podczas uruchomienia łaty EJB 3.0 - dziwne, nieprawdaż?).12:58:05,234 INFO [Server] JBoss (MX MicroKernel) [4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339)] Started in 20s:234ms
- Na koniec definicja JBoss AS w NetBeans IDE, co szczęśliwie jest najmniej zajmującą czynnością.
12:53:42,187 ERROR [MainDeployer] Could not create deployment: file:/C:/apps/jboss/server/default/deploy/ejb3-clustered-sfsbcache-service.xml
org.jboss.deployment.DeploymentException: - nested throwable: (java.lang.reflect.UndeclaredThrowableException)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
...
Caused by: java.lang.NoClassDefFoundError: org/jboss/cache/TreeCache
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
...
12:53:42,578 ERROR [MainDeployer] Could not create deployment: file:/C:/apps/jboss/server/default/deploy/ejb3-entity-cache-service.xml
org.jboss.deployment.DeploymentException: No ClassLoaders found for: org.jboss.cache.TreeCache; - nested throwable: (java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.cache.TreeCache)
at org.jboss.system.ServiceConfigurator.install(ServiceConfigurator.java:196)
at org.jboss.system.ServiceController.install(ServiceController.java:226)
...
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.cache.TreeCache
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:212)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:511)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:405)
...
15 stycznia 2007
Pora sprawdzić wiadomości o EJB3 - Enterprise JavaBeans 3.0 Simplified API Quiz
Dzisiaj natknąłem się na egzamin z EJB3 - Enterprise JavaBeans 3.0 Simplified API Quiz. Nie mogłem przejść obojętnie obok możliwości sprawdzenia mojego zrozumienia tematu i po kilku chwilach pojawił się wynik. Znowu owe magiczne 80% (a miałem nadzieję na 100% ;-)).
Owe dwa nietrafione pytania to:
You missed 2.
Your score is 80 percent.
Owe dwa nietrafione pytania to:
- Definicja poprawnych lokalnych interfejsów lokalnych - jakimś cudem dałem się zwieść obecnie zakazanemu interfejsowi EJBLocalObject i dodałem go do tych poprawnych.
- Wyjątki systemowe, które mogą być przechwycone przez klienta, a które są opakowane w javax.ejb.EJBException. Gdzieś mi się on pojawił, ale zobaczywszy pytanie i deklaracje interfejsu od razu odpowiedziałem...niepoprawnie.
14 stycznia 2007
@PostConstruct oraz @PreDestroy znane z EJB3 są również w JSF 1.2!
Przeglądając fora dotyczące tematyki JavaServer Faces (JSF) natrafiłem na pytanie dotyczące działania annotacji @PostConstruct oraz @PreDestroy w...JSF. Niedawno podziwiałem ich wprowadzenie do EJB3, a tu nagle informacja o ich istnieniu w JSF 1.2. Szybka lektura specyfikacji JSF 1.2 rozdziału 5.4 Leveraging Java EE 5 Annotations in Managed Beans i wszystko jasne. Wiele z annotacji, o których istnieniu dowiedziałem się ze specyfikacji EJB3 Simplified, istnieje również w JSF 1.2. Teraz napiszę nawet, że to i logiczne, ale jeszcze dzisiejszego ranka nie byłbym tego taki pewny.
Na moment zapomniałem kompletnie o EJB3 i przeczytałem rozdział 5.4 w specyfikacji JSF 1.2. Co nam dostarczają serwery aplikacyjne Java EE 5? Spójrzmy na to szerzej niż tylko na dwie wspomniane annotacje.
Każdy komponent zarządzany (ang. managed bean) o zasięgu request, session oraz application ma możliwość korzystania z wstrzeliwania zależności (DI). DI wykonywane jest przed udostępnieniem komponentu w aplikacji. Poprawne annotacje, z których można korzystać, to te opisane w specyfikacji Servlet 2.5, tj.:
Podobnie jak to ma miejsce w EJB3, annotacjami można dekorować zmienne instancji lub metody modyfikujące zmienne (ang. setters).
Pierwsze wywołanie metody komponentu zarządzanego w aplikacji spowoduje wykonanie DI (instancje komponentów są tworzone z opóźnieniem - ang. lazy instantiation).
Podrozdział 5.4.1 Managed Bean Lifecycle Annotations omawia wspomniane annotacje @PostConstruct oraz @PreDestroy. Jedynie metody komponentów o widoczności (zasięgu) request, session oraz application udekorowane annotacjami będą wywoływane.
Metoda @PostConstruct będzie wywoływana po stworzeniu instancji komponentu, po DI, ale przed udostępnieniem komponentu w danym zasięgu (czyli przed wykonaniem jego metod).
Metoda @PreDestroy wywoływana jest przed usunięciem instancji komponentu zarządzanego.
Wyłącznie metody spełniające poniższe kryteria mogą być udekorowane @PostConstruct oraz @PreDestroy:
Wystarczy zadeklarować komponent Quiz w faces-config.xml:
i uruchomienie aplikacji z komponentem uwidacznia się w GlassFish v2 b31 tak:
Świadomie użyłem nazw metod - init() oraz destroy(). Zbyt często pojawiają się one w moich komponentach, aby ich zbieżność nie sugerowała możliwego zastosowania. Najwyższa pora na projekt z Java EE 5 w tle ;-)
Dodatkowo doszukałem się informacji o @PostConstruct i @PreDestroy w dokumentacji JBoss Seam - Chapter 5. Events, interceptors and exception handling. Na szczególną uwagę zasługuje sekcja 5.2. Seam interceptors, a właściwie jej zakończenie, gdzie napisano:
You can even use Seam interceptors with JavaBean components, not just EJB3 beans!
Na moment zapomniałem kompletnie o EJB3 i przeczytałem rozdział 5.4 w specyfikacji JSF 1.2. Co nam dostarczają serwery aplikacyjne Java EE 5? Spójrzmy na to szerzej niż tylko na dwie wspomniane annotacje.
Każdy komponent zarządzany (ang. managed bean) o zasięgu request, session oraz application ma możliwość korzystania z wstrzeliwania zależności (DI). DI wykonywane jest przed udostępnieniem komponentu w aplikacji. Poprawne annotacje, z których można korzystać, to te opisane w specyfikacji Servlet 2.5, tj.:
- @Resource
- @Resources
- @EJB
- @EJBs
- @WebServiceRef
- @WebServiceRefs
- @PersistenceContext
- @PersistenceContexts
- @PersistenceUnit
- @PersistenceUnits
Podobnie jak to ma miejsce w EJB3, annotacjami można dekorować zmienne instancji lub metody modyfikujące zmienne (ang. setters).
Pierwsze wywołanie metody komponentu zarządzanego w aplikacji spowoduje wykonanie DI (instancje komponentów są tworzone z opóźnieniem - ang. lazy instantiation).
Podrozdział 5.4.1 Managed Bean Lifecycle Annotations omawia wspomniane annotacje @PostConstruct oraz @PreDestroy. Jedynie metody komponentów o widoczności (zasięgu) request, session oraz application udekorowane annotacjami będą wywoływane.
Metoda @PostConstruct będzie wywoływana po stworzeniu instancji komponentu, po DI, ale przed udostępnieniem komponentu w danym zasięgu (czyli przed wykonaniem jego metod).
Metoda @PreDestroy wywoływana jest przed usunięciem instancji komponentu zarządzanego.
Wyłącznie metody spełniające poniższe kryteria mogą być udekorowane @PostConstruct oraz @PreDestroy:
- metoda musi być bezargumentowa
- zwracany typ z metody musi być void
- nie możliwa jest deklaracja kontrolowanych wyjątków (ang. checked exception)
- metoda może być dowolnej widoczności - public, protected, private lub default (aka package private)
- @PostConstruct spowoduje brak dostępności komponentu dla aplikacji, więc metody na nim nie będą mogły być wywołane
- @PreDestroy ignoruje ich pojawienie się (serwer aplikacyjny może odnotować wyjątek)
package pl.jaceklaskowski.jsf12;
import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
public class Quiz {
public Quiz() {
System.out.println("Konstruktor Quiz.<init>() wykonany");
}
@PostConstruct
protected void init() {
System.out.println("init() wykonane");
}
public String businessMethod() {
System.out.println("businessMethod() wykonane");
return "success";
}
@PreDestroy
protected void destroy() {
System.out.println("destroy() wykonane");
}
}
Wystarczy zadeklarować komponent Quiz w faces-config.xml:
<managed-bean>
<managed-bean-name>quiz</managed-bean-name>
<managed-bean-class>pl.jaceklaskowski.jsf12.Quiz</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
i uruchomienie aplikacji z komponentem uwidacznia się w GlassFish v2 b31 tak:
Konstruktor Quiz.<init>() wykonany
init() wykonane
businessMethod() wykonane
destroy() wykonane
Świadomie użyłem nazw metod - init() oraz destroy(). Zbyt często pojawiają się one w moich komponentach, aby ich zbieżność nie sugerowała możliwego zastosowania. Najwyższa pora na projekt z Java EE 5 w tle ;-)
Dodatkowo doszukałem się informacji o @PostConstruct i @PreDestroy w dokumentacji JBoss Seam - Chapter 5. Events, interceptors and exception handling. Na szczególną uwagę zasługuje sekcja 5.2. Seam interceptors, a właściwie jej zakończenie, gdzie napisano:
You can even use Seam interceptors with JavaBean components, not just EJB3 beans!
EJB defines interception not only for business methods (using @AroundInvoke), but also for the lifecycle methods @PostConstruct, @PreDestroy, @PrePassivate and @PostActive. Seam supports all these lifecycle methods on both component and interceptor not only for EJB3 beans, but also for JavaBean components (except @PreDestroy which is not meaningful for JavaBean components).
Zastanawiam się jaki to ma związek z wymaganiem odnośnie komponentów zarządzanych w JSF 1.2 (na których JBoss Seam opiera swoje działanie)? Czyta się to tak, jakby korzystanie z annotacji @PostConstruct oraz @PreDestroy to była wyłącznie cecha Seama, a co się właśnie dowiedziałem i JSF 1.2 to ma. Oczywiście udostępnienie annotacji dla dowolnych komponentów JavaBeans (POJO), to więcej niż dla komponentów EJB3, czy JSF1.2, ale nie potrafię wyobrazić sobie sytuacji, w której chciałbym korzystać z annotacji poza "uaktywnieniem" komponentów jako będące komponentami EJB3, albo JSF1.2. W przypadku EJB3 to jedynie dodanie kolejnej annotacji (@Stateless, @Stateful, @MessageDriven). Dla JSF 1.2 sprawa się lekko komplikuje, bo wymagana jest deklaracja komponentu w pliku konfiguracyjnym faces-config.xml (chyba, że i tym razem pojawiło się kolejne udoskonalenie w specyfikacji, o którym nie wiem). Tak, czy owak, czy to tak wiele? Czy rzeczywiście JBoss Seam udostępnia coś nadzwyczajnego?! Chyba na wieczór podwyższył mi się poziom krytyki dla JBoss Seam. Pora iść spać!
13 stycznia 2007
Chapter 8 - Enterprise Bean Context and Environment i Chapter 9 - Compatibility and Migration przeczytane!
I kolejne rozdziały specyfikacji EJB3 Simplified przeczytane! Czyta się je wyjątkowo sprawnie - odpowiedni styl pisania o wszystkich uproszczeniach w EJB3 korzystnie wpływa na jej lekturę. Tym razem kolejne dwa rozdziały poszły pod młotek - Chapter 8 Enterprise Bean Context and Environment oraz Chapter 9 Compatibility and Migration. W zasadzie wszystko już było w poprzednich rozdziałach - pojawiło się trochę detali (sposób na odsianie kilku delikwentów na egzaminie SCBCD).
Chapter 8 Enterprise Bean Context and Environment
Komponent EJB posiada dostęp do prywatnego kontekstu wykonania - stanu środowiska w danej chwili.
Pierwszy raz pojawia się DI poprzez udekorowanie metody modyfikującej właściwość komponentu (ang. setter),
która jest alternatywą dla DI dla bezpośredniego dostępu do pola instancji.
Korzystanie z DI poprzez metodę modyfikującą znacząco poprawia możliwość testowania komponentu poza specjalizowanym środowiskiem DI. Temat poruszony był na ostatnim III spotkaniu Warszawa JUG, gdzie zapytano o wychwalaną przeze mnie prostotę testowania komponentów EJB. Skorzystanie z metody modyfikującej rozwiązuje problem, ponieważ wystarczy przed testowaniem zainicjować komponent, co w przypadku prywatnego pola instancji nie jest zadaniem trywialnym. W zasadzie skłaniam się ku stwierdzeniu, że dekorowanie pól instancji wpływa negatywnie na testy i na chwilę obecną nie jest przeze mnie rekomendowane - stosujemy wyłącznie dekorowanie metod nie pól.
Wracając do rozdziału, do interfejsu javax.ejb.EJBContext dodano metodę lookup, która może posłużyć jako sposób dowiązania do zasobów zewnętrznych, bądź ostatecznie można korzystać z JNDI.
Komponent deklaruje zależności od zasobów zewnętrznych poprzez annotacje (w tym kontekście nazywane annotacjami zależności - ang. dependency annotation). Annotacja służy do wskazania miejsca wstrzelenia zależności, typ zależności, nazwę, pod którą kontener może odszukać zależność w kontekście wykonania i inne cechy charakterystyczne dla zależnego zasobu.
Podano dwa rodzaje annotacji @EJB oraz @Resource. Brak jakichkolwiek argumentów dla annotacji instruuje serwer, że dalsze informacje będą pobrane z kontekstu z jakim są związane, tj. klasy, zmiennej klasy bądź metody.
Dekorowaniu podlegają klasa komponentu, zmienne instancji lub metody.
Dla przypomnienia: DI zachodzi po skonstruowaniu instancji komponentu, przypisaniu jej kontekstu - EJBContext, a przed wywołaniem pierwszej metody biznesowej.
Annotacja @EJB może definiować następujące informacje o wyszukiwanym komponencie:
Nazwa i typ zasobu wyznaczane są poprzez nazwę i typ zmiennej bądź metody, z którą związana jest annotacja.
Wszystko, co dostępne w JNDI - jest do wstrzelenia poprzez annotację. Wszystkie zależne zasoby muszą być dostępne w prywatnym kontekście wykonania (java:comp/env).
Równoważnie, można skorzystać z EJBContext.lookup(String name), gdzie name jest dokładnie nazwą podawaną w @EJB lub @Resource dla argumentu name (przy jego braku znaczenie ma nazwa zmiennej bądź metody modyfikującej, do której się ona odnosi).
Chapter 9 Compatibility and Migration
Pierwsza ważna informacja dla osób aktualnie zaangażowanych w projekty oparte o EJB 2.1, a pracujące w środowisku wspierającym EJB 3.0 - Wasza aplikacja musi pracować bez żadnych zmian związanych z EJB 3.0 (chyba, że wyspecyfikowano jakiekolwiek w RELEASE NOTES, czy podobnie, ale wtedy trudno będzie uzyskać takiemu serwerowi miano zgodności z EJB 3.0).
Nie opisując szczegółów rozdziału nie zauważyłem żadnych obostrzeń w tworzeniu aplikacji Java EE 5 jednocześnie z elementami EJB 2.1 i EJB 3.0. Klienci aplikacyjni również nie są zobowiązani do migracji do nowszej wersji specyfikacji, jeśli ich komponenty EJB korzystają z niej (przypominam, że interakcja między światem zewnętrznym a komponentami zawsze odbywa się poprzez obiekty pośrednie - ang. proxy objects/beans).
Chapter 8 Enterprise Bean Context and Environment
Komponent EJB posiada dostęp do prywatnego kontekstu wykonania - stanu środowiska w danej chwili.
Pierwszy raz pojawia się DI poprzez udekorowanie metody modyfikującej właściwość komponentu (ang. setter),
@EJB
public void setInterfejsBiznesowyXYZ(InterfejsBiznesowyXYZ interfejsBiznesowyXYZBean) {
this.interfejsBiznesowyXYZBean = interfejsBiznesowyXYZBean;
}
która jest alternatywą dla DI dla bezpośredniego dostępu do pola instancji.
@EJB
private InterfejsBiznesowyXYZ interfejsBiznesowyXYZBean;
Korzystanie z DI poprzez metodę modyfikującą znacząco poprawia możliwość testowania komponentu poza specjalizowanym środowiskiem DI. Temat poruszony był na ostatnim III spotkaniu Warszawa JUG, gdzie zapytano o wychwalaną przeze mnie prostotę testowania komponentów EJB. Skorzystanie z metody modyfikującej rozwiązuje problem, ponieważ wystarczy przed testowaniem zainicjować komponent, co w przypadku prywatnego pola instancji nie jest zadaniem trywialnym. W zasadzie skłaniam się ku stwierdzeniu, że dekorowanie pól instancji wpływa negatywnie na testy i na chwilę obecną nie jest przeze mnie rekomendowane - stosujemy wyłącznie dekorowanie metod nie pól.
Wracając do rozdziału, do interfejsu javax.ejb.EJBContext dodano metodę lookup, która może posłużyć jako sposób dowiązania do zasobów zewnętrznych, bądź ostatecznie można korzystać z JNDI.
Komponent deklaruje zależności od zasobów zewnętrznych poprzez annotacje (w tym kontekście nazywane annotacjami zależności - ang. dependency annotation). Annotacja służy do wskazania miejsca wstrzelenia zależności, typ zależności, nazwę, pod którą kontener może odszukać zależność w kontekście wykonania i inne cechy charakterystyczne dla zależnego zasobu.
Podano dwa rodzaje annotacji @EJB oraz @Resource. Brak jakichkolwiek argumentów dla annotacji instruuje serwer, że dalsze informacje będą pobrane z kontekstu z jakim są związane, tj. klasy, zmiennej klasy bądź metody.
Dekorowaniu podlegają klasa komponentu, zmienne instancji lub metody.
Dla przypomnienia: DI zachodzi po skonstruowaniu instancji komponentu, przypisaniu jej kontekstu - EJBContext, a przed wywołaniem pierwszej metody biznesowej.
Annotacja @EJB może definiować następujące informacje o wyszukiwanym komponencie:
- beanInterface - dowolny interfejs komponentu - lokalny/zdalny interfejs biznesowy (dla zgodności z EJB 2.1 również lokalny/zdalny interfejs domowy)
- beanName - równoważne ejb-name komponentu zależnego
- mappedName - zgodnie z JavaDoc to specyficzna dla produktu nazwa komponentu EJB - nic mi to nie mówi, niestety (i tak nie jest to przenośne)
- name - nazwa pod jaką widnieje komponent zależny w prywatnym kontekście wykonania komponentu (java:comp/env)
- authenticationType - typ uwierzytelnienia - APPLICATION, CONTAINER (domyślna wartość)
- description - opis
- mappedName - podobnie jak w @EJB - nieprzenośnie, więc nie ma się co tym przejmować
- name - nazwa pod jaką widnieje zasób w prywatnym kontekście wykonania komponentu (java:comp/env)
- shareable - false/true (domyślna wartość) - czy jest współdzielona między komponentami
- type - typ zasobu
@Resource(name="myDB", description="Baza danych pracowników", authenticationType=APPLICATION)
DataSource customerDB;
@EJB(name="mojaNazwaKomponentu", beanInterface=pl.jaceklaskowski.mojaapp.InterfejsBiznesowyWersja2)
InterfejsBiznesowy interfejsBiznesowyBean;
@EJB(name="komponentXYZ")
public void setCustomerManager(CustomerManager customerManager) {
this.customerManager = customerManager;
}
Nazwa i typ zasobu wyznaczane są poprzez nazwę i typ zmiennej bądź metody, z którą związana jest annotacja.
Wszystko, co dostępne w JNDI - jest do wstrzelenia poprzez annotację. Wszystkie zależne zasoby muszą być dostępne w prywatnym kontekście wykonania (java:comp/env).
Równoważnie, można skorzystać z EJBContext.lookup(String name), gdzie name jest dokładnie nazwą podawaną w @EJB lub @Resource dla argumentu name (przy jego braku znaczenie ma nazwa zmiennej bądź metody modyfikującej, do której się ona odnosi).
Chapter 9 Compatibility and Migration
Pierwsza ważna informacja dla osób aktualnie zaangażowanych w projekty oparte o EJB 2.1, a pracujące w środowisku wspierającym EJB 3.0 - Wasza aplikacja musi pracować bez żadnych zmian związanych z EJB 3.0 (chyba, że wyspecyfikowano jakiekolwiek w RELEASE NOTES, czy podobnie, ale wtedy trudno będzie uzyskać takiemu serwerowi miano zgodności z EJB 3.0).
Nie opisując szczegółów rozdziału nie zauważyłem żadnych obostrzeń w tworzeniu aplikacji Java EE 5 jednocześnie z elementami EJB 2.1 i EJB 3.0. Klienci aplikacyjni również nie są zobowiązani do migracji do nowszej wersji specyfikacji, jeśli ich komponenty EJB korzystają z niej (przypominam, że interakcja między światem zewnętrznym a komponentami zawsze odbywa się poprzez obiekty pośrednie - ang. proxy objects/beans).
Eclipse IDE 3.3M4 i tworzenie oprogramowania Java EE - uaktualnienie artykułu
Udało się! W końcu doczekałem się nowszych wydań niezbędnych wtyczek dla Eclipse IDE 3.3M4 tak, że możliwe jest tworzenie aplikacji Java EE . Uaktualniłem artykuł Tworzenie aplikacji Java EE 5 z Eclipse IDE i GlassFish o właściwe wersje. Mogę zatem spokojnie usunąć poprzednią wersję i pracować z jedyną słuszną 3.3M4! (a jest co w niej podziwiać, np. Ctrl-Shift-t i wpisanie IOOBE jest niesamowite).
Należy pamiętać, że każdorazowe uaktualnienie wtyczek wiąże się z uruchomieniem Eclipse IDE z opcją -clean (tj. eclipse -clean), aby nie było takich "kwiatków" jak:
Należy pamiętać, że każdorazowe uaktualnienie wtyczek wiąże się z uruchomieniem Eclipse IDE z opcją -clean (tj. eclipse -clean), aby nie było takich "kwiatków" jak:
java.lang.RuntimeException: java.lang.LinkageError: loader constraints violated when linking org/w3c/dom/Node class
at org.eclipse.wst.common.project.facet.ui.ModifyFacetedProjectWizard.performFinish(ModifyFacetedProjectWizard.java:306)
at org.eclipse.wst.web.ui.internal.wizards.NewProjectDataModelFacetWizard.performFinish(NewProjectDataModelFacetWizard.java:307)
at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:695)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:367)
at org.eclipse.jface.dialogs.Dialog$3.widgetSelected(Dialog.java:638)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3465)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3079)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:820)
at org.eclipse.jface.window.Window.open(Window.java:796)
at org.eclipse.ui.actions.NewProjectAction.run(NewProjectAction.java:116)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:545)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:490)
at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3465)
Jeśli GlassFish v2 to NetBeans IDE 5.5.1
Wszystko zaczęło się od informacji jaką znalazłem we wpisie All good things come to an end...., gdzie przeczytałem, że NetBeans (NB) 5.5 był rozwijany dla GlassFish (GF) v1, a możliwość pracy z GF v2 była jedynie szczęśliwym przypadkiem. Oczywiście od wersji GF v2b26 rozpoczęły się problemy i ostatnia moja próba zademonstrowania aplikacji Java EE podczas III spotkania Warszawa JUG, którą zbudowałem w NB i próbowałem uruchomić na GF v2b30 zakończyła się znajomym stosem wywołań (ang. stack trace).
Nie dawało mi to spokoju i przeświadczony brakiem funkcjonalności tworzenia aplikacji Java EE w NetBeans 6.0 nawet nie próbowałem ich integracji (nie wiedziałem o istnieniu wersji 5.5.1). Po prostu założyłem, że nie działają i nie chciałem tracić czasu. Kilka dni temu wyczytałem, gdzieś, że tak jednak nie jest. Pobrałem NB 6.0 Daily Build, zainstalowałem i...po chwili mogłem uruchomić aplikację, którą miałem uruchomić na spotkaniu Warszawa JUG (!)
Podczas uruchomienia aplikacji dowiedziałem się kolejnej rzeczy o DI (ang. dependency injection) - wstrzeliwaniu zależności - w Java EE 5. Nie ma możliwości udekorowania strony JSP tak, aby mogła korzystać z DI, np. do wstrzelenia EJB. Sądziłem, że skoro JSP to ostatecznie servlet to i DI będzie działało. Myliłem się. Nie znalazłem jeszcze niczego w specyfikacji EJB3, Java EE 5, czy JSP 2.1, co potwierdziłoby takie działanie. Zdobyłem się na własną interpretację - strona JSP staje się servletem jako wynik wywołania JspServlet, który domyślnie przypisany jest do rozszerzenia *.jsp. W ten sposób wszystkie pliki jsp w aplikacji internetowej trafiają do servletu JspServlet, a po transformacji do servletu wywoływana jest metoda service(). W ten sposób kontener już nie uczestniczy w przetwarzaniu zlecenia i stąd brak DI.
Wracając do współpracy NB z GF, we wspomnianym wpisie (All good things come to an end....) dowiedziałem się o istnieniu wsparcia dla GFv2 w NB 5.5.1. W komentarzu do tego wpisu pojawił się namiar na kolejny - NetBeans Version for WSIT in GlassFish, który dokładnie opisywał ostatnią dostępną konfigurację - NB 5.5.1 Daily Build oraz GF v2b31. Pobrałem, zainstalowałem i działa!
Kilka cennych informacji o współpracy NB z GF na GlassFish Project - NetBeans IDE integration.
Ogłoszenie integracji między GF v2 a NB 5.5.1 również na Use NetBeans 5.5.1 when working with GlassFish v2. Wydaje się być najwłaściwszym miejscem, od którego powinienem zaczać, które z kolei wymienia wyżej wymienione wpisy.
Nie dawało mi to spokoju i przeświadczony brakiem funkcjonalności tworzenia aplikacji Java EE w NetBeans 6.0 nawet nie próbowałem ich integracji (nie wiedziałem o istnieniu wersji 5.5.1). Po prostu założyłem, że nie działają i nie chciałem tracić czasu. Kilka dni temu wyczytałem, gdzieś, że tak jednak nie jest. Pobrałem NB 6.0 Daily Build, zainstalowałem i...po chwili mogłem uruchomić aplikację, którą miałem uruchomić na spotkaniu Warszawa JUG (!)
Podczas uruchomienia aplikacji dowiedziałem się kolejnej rzeczy o DI (ang. dependency injection) - wstrzeliwaniu zależności - w Java EE 5. Nie ma możliwości udekorowania strony JSP tak, aby mogła korzystać z DI, np. do wstrzelenia EJB. Sądziłem, że skoro JSP to ostatecznie servlet to i DI będzie działało. Myliłem się. Nie znalazłem jeszcze niczego w specyfikacji EJB3, Java EE 5, czy JSP 2.1, co potwierdziłoby takie działanie. Zdobyłem się na własną interpretację - strona JSP staje się servletem jako wynik wywołania JspServlet, który domyślnie przypisany jest do rozszerzenia *.jsp. W ten sposób wszystkie pliki jsp w aplikacji internetowej trafiają do servletu JspServlet, a po transformacji do servletu wywoływana jest metoda service(). W ten sposób kontener już nie uczestniczy w przetwarzaniu zlecenia i stąd brak DI.
Wracając do współpracy NB z GF, we wspomnianym wpisie (All good things come to an end....) dowiedziałem się o istnieniu wsparcia dla GFv2 w NB 5.5.1. W komentarzu do tego wpisu pojawił się namiar na kolejny - NetBeans Version for WSIT in GlassFish, który dokładnie opisywał ostatnią dostępną konfigurację - NB 5.5.1 Daily Build oraz GF v2b31. Pobrałem, zainstalowałem i działa!
Kilka cennych informacji o współpracy NB z GF na GlassFish Project - NetBeans IDE integration.
Ogłoszenie integracji między GF v2 a NB 5.5.1 również na Use NetBeans 5.5.1 when working with GlassFish v2. Wydaje się być najwłaściwszym miejscem, od którego powinienem zaczać, które z kolei wymienia wyżej wymienione wpisy.
09 stycznia 2007
III spotkanie Warszawa JUG za nami - następne 6 lutego
Co spotkanie to kolejna niespodzianka. Przyszedłem na spotkanie na około 5 minut przed 18-tą i prawie zamarłem, kiedy zobaczyłem tłum oczekujących ludzi. Na prawdę wydawało mi się jakoś tłumnie! Albo miałem dość podchodzenia pod schody, albo trema przez prezentacją, ale wydawało mi się, że nie pomieścimy się w sali. Sądzę, że mogło być około 40 osób i jak tak pomyśleć to w zasadzie tego należało się spodziewać po tak chodliwym temacie jak Enterprise JavaBeans 3.0. Pojawiło się wiele nowych osób, które wydają się być zainteresowane inicjatywą i pojawiają się głosy zainteresowane prowadzeniem prezentacji. Widać, że następne spotkania mają szanse powodzenia. 6 lutego następne spotkanie i kręcę się koło JBoss Seam. Mam go od miesięcy na mojej liście do zweryfikowania, więc tym razem konieczność zaprezentowania go na IV spotkaniu może być dobrym bodźcem. Na spotkaniu pojawiło się kilka pytań dotyczących zastosowania różnych komponentów (SFSB vs encje) do zamodelowania funkcjonalności biznesowych. Pojawiło się kilka głosów o braku skalowalności SFSB, więc odczuć było można, że nie są one zalecane i lepiej ich unikać. Może stworzenie kilku przykładowych aplikacji pomoże rozwiązać kwestie zastosowania komponentów EJB? Ostatnio pojawił się Java Pet Store 2.0 Reference Application, Early Access dla Java EE 5, więc analiza aplikacji na pewno przyniesie kilka odpowiedzi. Ufam również, że i Seam może pomóc skoro ukrywa kwestie implementacyjne.
Wracam do lektury specyfikacji. Na dzisiaj zaplanowałem Chapter 8 Enterprise Bean Context and Environment.
Wracam do lektury specyfikacji. Na dzisiaj zaplanowałem Chapter 8 Enterprise Bean Context and Environment.
Kolejne rozdziały specyfikacji EJB3 Simplified - Chapter 6 Message-Driven Beans oraz Chapter 7 Persistence
Wydawałoby się, że czytanie specyfikacji Java EE nie może być przyjemne. Tylko Ci tak twierdzą, którzy nigdy tego nie robili. Dla przykładu: wczoraj przeczytałem 2 rozdziały EJB3 Simplified - Chapter 6 Message-Driven Beans oraz Chapter 7 Persistence. Czy to dużo? Wydawać by się mogło, że tak, ale w sumie oba mają nie więcej niż...3 strony (!) Autorzy specyfikacji wzięli sobie do serca tytuł tej części specyfikacji EJB3 - Simplified. Dodać należy, że Java Persistence ma swoją odrębną specyfikację wynikającą z jej odmienności w stosunku do innych komponentów, więc rozdział 7 to tak na prawdę odwołanie do lektury EJB3 Core.
O czym, więc napisano w kontekście komponentu sterowanego komunikatami (ang. MDB - message-driven bean)?
W przeciwieństwie do komponentów sesyjnych, MBD wymaga, aby interfejs biznesowy był interfejsem wyznaczającym obsługiwany typu komunikacji, np. JMS przez javax.jms.MessageListener.
MDB musi implementować interfejs związany z obsługiwanym typem komunikacji bądź wskazać interfejs poprzez annotację @MessageDriven bądź deskryptor instalacji.
Klasa staje się komponentem MDB po udekorowaniu annotacją @MessageDriven lub poprzez definicję w deskryptorze instalacji. Koniec z implementacją interfejsu javax.ejb.MessageDrivenBean.
Metody zwrotne związane z cyklem życia komponentu MDB - wspierane zdarzenia to:
Podobnie jak w przypadku komponentów sesyjnych, @PostConstruct wywoływane jest po stworzeniu instancji komponentu i DI, ale przed wywołaniem pierwszej metody biznesowej (co w przypadku MDB jest wywołaniem metody interfejsu wyznaczającego typ obsługiwanej komunikacji).
@PostConstruct oraz @PreDestroy wykonywane są w nieokreślonym kontekście transakcyjnym i bezpieczeństwa.
Podobnie jak w komponentach sesyjnych, DI następuje przed wywołaniem metod interfejsu komunikacyjnego bądź metod zwrotnych.
Podobnie jak w komponentach sesyjnych, interceptor @AroundInvoke jest dostępny dla MDB i definiowany jest bezpośrednio w klasie komponentu lub interceptorze i dołączany jest do wykonania metody interfejsu biznesowego.
W skrócie, poznanie zachowania komponentu SFSB pozwala na zapoznanie się z tematem zachowania pozostałych komponentów, w tym i MDB, stąd wiele zawartych tu informacji różni się wyłącznie asynchronicznym zachowaniem się MDB i zależnością między interfejsem biznesowym MDB, a interfejsem usługi komunikatów.
Do zobaczenia na spotkaniu!
O czym, więc napisano w kontekście komponentu sterowanego komunikatami (ang. MDB - message-driven bean)?
W przeciwieństwie do komponentów sesyjnych, MBD wymaga, aby interfejs biznesowy był interfejsem wyznaczającym obsługiwany typu komunikacji, np. JMS przez javax.jms.MessageListener.
MDB musi implementować interfejs związany z obsługiwanym typem komunikacji bądź wskazać interfejs poprzez annotację @MessageDriven bądź deskryptor instalacji.
Klasa staje się komponentem MDB po udekorowaniu annotacją @MessageDriven lub poprzez definicję w deskryptorze instalacji. Koniec z implementacją interfejsu javax.ejb.MessageDrivenBean.
Metody zwrotne związane z cyklem życia komponentu MDB - wspierane zdarzenia to:
- tworzenie
- usuwanie
- @PostConstruct
- @PreDestroy
Podobnie jak w przypadku komponentów sesyjnych, @PostConstruct wywoływane jest po stworzeniu instancji komponentu i DI, ale przed wywołaniem pierwszej metody biznesowej (co w przypadku MDB jest wywołaniem metody interfejsu wyznaczającego typ obsługiwanej komunikacji).
@PostConstruct oraz @PreDestroy wykonywane są w nieokreślonym kontekście transakcyjnym i bezpieczeństwa.
Podobnie jak w komponentach sesyjnych, DI następuje przed wywołaniem metod interfejsu komunikacyjnego bądź metod zwrotnych.
Podobnie jak w komponentach sesyjnych, interceptor @AroundInvoke jest dostępny dla MDB i definiowany jest bezpośrednio w klasie komponentu lub interceptorze i dołączany jest do wykonania metody interfejsu biznesowego.
W skrócie, poznanie zachowania komponentu SFSB pozwala na zapoznanie się z tematem zachowania pozostałych komponentów, w tym i MDB, stąd wiele zawartych tu informacji różni się wyłącznie asynchronicznym zachowaniem się MDB i zależnością między interfejsem biznesowym MDB, a interfejsem usługi komunikatów.
Do zobaczenia na spotkaniu!
07 stycznia 2007
Chapter 5 - Stateful Session Beans oraz lektura książki Enterprise JavaBeans 3.0 wyd. 5 z O'Reilly
Pisałem wczoraj o konieczności zakasania rękawów i tak je zakasałem, że miałem je po same barki i...udało mi się znaleźć trochę czasu na lekturę 2 rozdziałów z 5. wydania książki Enterprise JavaBeans 3.0 z O'Reilly autorstwa Bill Burke i Richard Monson-Haefel. Pierwszego znamy z grupy tworzącej serwer aplikacyjny JBoss AS, a drugi to bodajże pierwszy z autorów, któremu udało się opisać EJB w niezwykle przystępny sposób (dla dociekliwych dodam, że Richard był założycielem projektu Apache OpenEJB - kontenera EJB - jeszcze w czasach finansowania projektu przez Intalio i później na SourceForge).
Muszę przyznać, że Bill wie o czym pisze, co zresztą zostało zauważone we wstępie napisanym przez koordynatora grupy standaryzującej EJB3 - Linda DeMichiel. Pierwsze dwa rozdziały zdają się wskazywać, że lektura książki upraszcza zrozumienie specyfikacji EJB3 i jakkolwiek do końca daleko, to skłaniam się ku ocenie, że książkę warto mieć na swojej półce.
Z wielkim zainteresowaniem wysłuchałbym opinii osób, którzy ją przeczytali i zechcieliby podzielić się swoimi wrażeniami, a może nawet i zarekomendowali dalsze kroki czytelnicze i praktyczne?!?!
Mimo zainteresowania książką, dla uatrakcyjnienia weekendu kontynuuję czytanie specyfikacji EJB3 Simplified (w końcu na niej zamierzam oprzeć egzamin na javaBLACKbelt). Tym razem przyszła kolej na rozdział 5: Stateful Session Beans. Zobaczmy co można, a czego nie można w SFSB (ang. stateful session bean)?
Muszę przyznać, że Bill wie o czym pisze, co zresztą zostało zauważone we wstępie napisanym przez koordynatora grupy standaryzującej EJB3 - Linda DeMichiel. Pierwsze dwa rozdziały zdają się wskazywać, że lektura książki upraszcza zrozumienie specyfikacji EJB3 i jakkolwiek do końca daleko, to skłaniam się ku ocenie, że książkę warto mieć na swojej półce.
Z wielkim zainteresowaniem wysłuchałbym opinii osób, którzy ją przeczytali i zechcieliby podzielić się swoimi wrażeniami, a może nawet i zarekomendowali dalsze kroki czytelnicze i praktyczne?!?!
Mimo zainteresowania książką, dla uatrakcyjnienia weekendu kontynuuję czytanie specyfikacji EJB3 Simplified (w końcu na niej zamierzam oprzeć egzamin na javaBLACKbelt). Tym razem przyszła kolej na rozdział 5: Stateful Session Beans. Zobaczmy co można, a czego nie można w SFSB (ang. stateful session bean)?
- Business interfejs to zwykły interfejs w Javie, zero EJBObject czy EJBLocalObject
- Koniec z interfejsem domowym do pobrania referencji do SFSB - DI albo JNDI wystarczy
- Annotacja @Stateful lub definicja w deskryptorze instalacji. Nie ma potrzeby implementować javax.ejb.SessionBean lub java.io.Serializable. Ale...można implementować SessionBean (wsparcie dla kodu z poprzednich wersji EJB, gdzie była taka konieczność) oraz mimo, że Serializable jest interfejsem-znacznikiem, który wskazuje na możliwość zapisu stanu obiektu w Javie, to kontener EJB musi obsłużyć pasywację i aktywację stanowych komponentów sesyjnych pomimo braku jego użycia (gdzieś czytałem, że jest to dobra praktyka korzystanie z interfejsu - zresztą, to nie boli ;-)).
- Pojawia się interfejs SessionSynchronization, jednak ze wskazaniem, że opis znajduje się w części specyfikacji EJB Core.
- Metody zwrotne związane z cyklem życia komponentu - wspierane zdarzenia to:
- tworzenie
- niszczenie (usuwanie)
- aktywacja
- pasywacja
- @PostConstruct
- @PreDestroy
- @PostActivate
- @PrePassivate
- Wstrzeliwanie zależności odbywa się przed wykonaniem metod biznesowych i metod zwrotnych.
- SFSB wspiera interceptory @AroundInvoke określone na klasie komponentu bądź w klasie interceptora. Dotyczą wyłącznie wywołań metod biznesowych.
- Wyjaśniono zależność między metodami interfejsu SessionSynchronization - afterBegin i beforeCompletion - a interceptorami @AroundInvoke. Kolejność wywoływania metod to:
- SessionSynchronization.afterBegin
- @AroundInoke
- SessionSynchronization.beforeCompletion
- W rozdziale znajduje się przykład SFSB z wstrzeleniem SessionContext, który za pomocą metody zwrotnej @PostConstruct i @PostActivate oraz @PreDestroy i @PrePassivate zarządza gniazdem (ang. socket). Komponent zawiera metodę @Remove oraz @AroundInvoke.
- Z punktu widzenia klienta dostęp do SFSB odbywa się poprzez DI albo JNDI. Każdorazowe pozyskanie komponentu za pomocą JNDI wiąże się z pobraniem nowej instancji komponentu. Nie napisano (tj. nie znalazłem), co będzie w sytuacji, kiedy pozyskanie SFSB odbywa się przy pomocy DI (prawdopodobnie, jak możnaby przypuszczać, mamy wtedy utrzymywanie tej samej instancji).
Kiedy SFSB jest wstrzelone (DI) do kontekstu klienta lub pozyskane przez JNDI, stworzona instancja komponentu jest zainicjowana z punktu widzenia JVM, ale niekoniecznie z punktu widzenia biznesowego, aż do wywołania metody "create", gdzie cały stan komponentu zostanie utworzony (do sprawdzenia, o co tak na prawdę chodzi - nie pamiętam, aby była mowa o jakiejkolwiek metodzie create. Może chodzi o @PostConstruct?).
Ach, następnie opisano scenariusz, gdzie komponent dostarcza metodę biznesową do inicjalizacji biznesowej komponentu (ala create). - Annotacja @Remove służy do oznaczenia metody biznesowej SFSB, której wykonanie wskaże kontenerowi moment usunięcia instancji (jak doczytałem w Java EE API - annotacja dostarcza parametr retainIfException, który jeśli przyjmuje wartości true, określa, że SFSB nie będzie usunięty przez kontener, gdy metoda zakończy się wyjątkiem).
Dla zobrazowania tematu zaprezentowano przykład, komponentu modelującego koszyk (ShoppingCartBean) z metodą startToShop (inicjującą komponent biznesowo), addToCart (typowa metoda biznesowa) oraz finishShopping (oznaczona annotacją @Remove, której pomyślne bądź w tym przypadku niepomyślne zakończenie wskazuje kontenerowi moment dozwolonego usunięcia komponentu).
Zdefiniowano następujące annotacje do wskazania metod zwrotnych w komponencie bądź w samej klasie interceptora:
Podobnie jak to ma miejsce dla SLSB, @PostConstruct wywoływane jest po stworzeniu nowej instancji komponentu, po wstrzeleniu zależności, ale przed wywołaniem pierwszej metody biznesowej. @PreDestroy wywoływane jest po zakończeniu wykonania metod oznaczonych @Remove (ciekawostką jest opisanie działania annotacji @PreDestroy w rozdziale o SLSB i SFSB - w poprzednim napisano, że metoda @PreDestroy wywoływana jest przy usuwaniu instancji komponentu SLSB, a teraz napisano dokładniej, kiedy takie zdarzenie jest generowane - po poprawnym wywołaniu metod @Remove).
@PostConstruct i @PreDestroy wywoływane są w nieokreślonym kontekście transakcji i bezpieczeństwa.
Wykonanie metod @PrePassivate i @PostActivate opisano jako identyczne z wykonaniem metod ejbActivate i ejbPassivate w EJB 2.1 oraz wskazano na dokładniejsze wyjaśnienie w specyfikacji EJB Core.
Chapter 4 - Stateless Session Beans za mną
Wracam do lektury specyfikacji EJB 3 Simplified. Tym razem przyszła pora na rozdział 4 o bezstanowych komponentach sesyjnych (ang. stateless session bean - SLSB). Rozdział bardzo krótki, bo i skomplikowanie tworzenia SLSB znacznie zmalało. W międzyczasie, na półce pojawiły się kolejne, nowe pozycje o EJB3, więc muszę zakasać rękawy. Na wtorkowym spotkaniu Warszawa JUG będzie idealna sposobność zweryfikowania wiedzy ;-)
Co napisano o SLSB w rozdziale 4 specyfikacji?
Co napisano o SLSB w rozdziale 4 specyfikacji?
- Interfejs biznesowy SLSB to zwykły interfejs w Javie (koniec z EJBObject czy EJBLocalObject, czyli innymi słowy włączania się do hierarchii klas) Nie ma konieczności definicji interfejsu dla usługi sieciowej (ang. Web Service) - służą do tego annotacje @WebMethod dla metod oraz @WebService dla komponentu, który jest punktem styku usługi (ang. web service endpoint). Annotacje są częścią specyfikacji JSR-181.
- Koniec z pojęciem interfejs domowy. Dostęp do komponentu poprzez DI (ang. dependency injection) albo JNDI bezpośrednio poprzez interfejs biznesowy.
- Annotacja @Stateless lub wpis do deskryptora instalacji (koniec z javax.ejb.SessionBean)
- Kontener informuje komponent o zdarzeniach w życiu komponentu - utworzenia i usunięcia - za pomocą metod zwrotnych komponentu oznaczonych annotacją @PostConstruct oraz @PreDestroy, odpowiednio.
@PostConstruct wywołane zostanie po pełnym skonstruowaniu komponentu, łącznie z wstrzeleniem zależności, a przed wywołaniem pierwszej metody biznesowej. Instancja komponentu podczas wywołania metod udekorowanych @PostConstruct oraz @PreDestroy nie związana jest z żadną transakcją oraz kontekstem bezpieczeństwa.
Metody udekorowane przez annotacje @PostActivate oraz @PrePassivate są ignorowane (nie mają racji bytu w przypadku bezstanowego komponentu sesyjnego). - Wstrzeliwanie zależności wykonane jest przed wywołaniem dowolnej metody biznesowej.
- Interceptory @AroundInvoke są wspierane dla wywołań metod biznesowych. Deklaracja interceptorów odbywa się poprzez deklarację na klasie komponentu albo w klasie interceptora. W specyfikacji zaprezentowano przykład klasy komponentu z zadeklarowanymi interceptorami - AccountAudit (odnotowywanie poprawnego wykonywania metody biznesowej), Metrics (śledzenie czasu wykonania metody biznesowej) oraz CustomSecurity (weryfikacja uprawnień wykonania metody biznesowej).
- Klient pozyskuje referencję do interfejsu biznesowego komponentu przez DI albo JNDI.
06 stycznia 2007
III spotkanie Warszawskiej Grupy Użytkowników Technologii Java (Warszawa JUG)
Warszawska Grupa Użytkowników Technologii Java (Warszawa JUG) zaprasza na III spotkanie, które odbędzie się w nadchodzący wtorek 09.01.2007 o godzinie 18:00 w sali 5820 na Wydziale MiMUW przy ul. Banacha 2 w Warszawie.
Temat prezentacji: Co nowego i dobrego w Enterprise JavaBeans 3.0
Najnowsza odsłona specyfikacji Java EE 5 udostępnia odrestaurowaną specyfikację Enterprise JavaBeans w wersji 3.0 (EJB3). EJB3, jak i samo Java EE 5, jest przeciwieństwem bolączek, z jakimi borykali się programiści w wersjach poprzednich. Krytyka EJB 2.1 i poprzednich była podstawą dla powstania jej alternatywnych rozwiązań, w których prym wiedzie Spring Framework. I to przede wszystkim ich wpływ i udział ich projektantów w ciele standaryzującym specyfikację EJB3 sprawiły, że jest ona naszpikowana interesującymi konstrukcjami programistycznymi wypromowanymi przez projekty otwarte i podparte usprawnieniami Java SE 5. Należą do nich: konfiguracja poprzez annotacje, wstrzeliwanie zależności (ang. dependency injection), POJO jako komponenty EJB czy interceptory (znane z AOP). Poza nimi znajdziemy w EJB3 autorskie usprawnienia, gdzie najważniejszym jest konfiguracja przez nadpisywanie (ang. configuration by exception).
Rozpoczęcie roku 2007 nie mogło być powitane prezentacją o mniej zdumiewającym swoim rozmachem novum niż EJB3. EJB3 dodaje blasku specyfikacji Java EE 5 i przyczyni się do powrotu wielu programistów i projektantów do platformy Java EE 5, którzy zmęczeni trudami EJB 2.1 zmigrowali do rozwiązań alternatywnych.
Prezentacja prowadzona będzie przez Jacka Laskowskiego, który jest członkiem grup rozwojowych projektów Apache Geronimo i Apache OpenEJB. Jest założycielem grup Warszawa JUG i Poland BEA User Group. Zaangażowany w poznawanie możliwości specyfikacji EJB3 tworząc egzamin na JavaBLACKbelt.com. Prowadzi Notatnik Projektanta Java EE, w którym znaleźć można m.in. relacje z lektury specyfikacji EJB3.
Planowany czas prezentacji to 1,25 godziny z kolejnymi 15 minutami na dyskuję.
Zapraszam w imieniu Warszawa JUG!
03 stycznia 2007
Software Development GigaCon 2007 - Zaproszenie do współpracy
I mamy nowy rok 2007! Jaki był poprzedni nie ma większego znaczenia - minął i już nie wróci. Najważniejsze, że mamy kolejne postanowienia i tym razem będziemy trzymać się harmonogramu i wypełnimy wszystko skrupulatnie! ;-) Tym mocnym postanowieniem wkraczam w 2007.
Nie, nie oznacza to, że skoro mamy 2007 rok to postanowienia z roku 2006 są przedawnione. Nadal zaczytuję się w specyfikacji EJB3 i pamiętam, aby wnioski upublicznić, choć nie ukrywam, że zbliżające się III spotkanie Warszawa JUG przypomina mi o przygotowaniu prezentacji, właśnie na ten temat. Dla przyciągnięcia uwagi nadmienię, że nadchodzący wtorek to dzień kolejnego spotkania Warszawa JUG. Zainteresowanych tematyką EJB3 serdecznie zapraszam. Nadal borykam się z ustaleniem precyzyjnego tematu spotkania, ale pewne jest, że będzie to coś o EJB3. Wspomnę o GlassFish, EJB3 i najprawdopodobniej o ostatnim osiągnięciu uruchomienia aplikacji przykładowej projektu JBoss Seam.
Ale skąd ten tytuł?! Wielu z Was wie, że moim osobistym marzeniem jest zorganizowanie konferencji w stylu JavaPolis, czy ApacheCon, czy może nawet JavaOne. Coś w kształcie 2-dniowej konferencji naszpikowanej warsztatami, prezentacjami na maksymalnie wyśrubowanym poziomie. Pomysł opiera się na idei, że tylko zintegrowane środowisko programistów i projektantów może uczyć się wzajemnie na własnych doświadczeniach. Nie chodzi o to, abyśmy spędzili czas na kolejnych prezentacjach, z których nic nie wynosimy. Konferencja miałaby polegać na "wstrzyknięciu" (ang. injection - ot takie popularne słowo ostatnio) kilku pomysłów, które po powrocie do naszych projektów natychmiast wdrażamy, udoskonalając je. Wierząc, że kiedyś uda mi się zorganizować taką właśnie konferencję, dzisiaj otrzymałem wiadomość od pani Katarzyny z Software-Konferencje o magicznym tytule "Zaproszenie do współpracy", której wycinek przytoczę (wierząc, że nie naruszam żadnych praw, a odwzajemniam się darmową reklamą konferencji):
Zespół Software-Konferencje organizuje ósma edycję konferencji Software Development GigaCon 2007, która odbędzie się 22-23 marca 2007 roku w Hotelu Marriott w Warszawie. Chcielibyśmy zaprosić Pana do wygłoszenia wykładu merytorycznego na naszej konferencji.
Oczywiście z wielką satysfakcją i zainteresowaniem przeczytałem wiadomość. Kompletnie zapomniałem, że istnieje już na rynku instytucja o ugruntowanej pozycji, która organizuje profesjonalne konferencje dla projektantów i programistów w Polsce. Nie mogłem zażyczyć sobie lepszego rozpoczęcia roku! Oczywiście, że zgodziłem się przyjąć zaproszenie! Jak inaczej mogłem zareagować na tak wspaniały prezent w 2007 roku! Temat mojego wystąpienia nie został jeszcze ustalony, ale na pewno będzie to mieszanka projektów otwartych (ang. OSS - open source software) wokół Java EE 5. Postaram się również przygotować prezentację-warsztat o Apache Geronimo i Apache OpenEJB 3. Do czasu konferencji zamierzam zbierać uwagi o możliwych tematach na konferencję. W końcu będzie to okazja spotkać wiele osób spoza Warszawy, którzy nie mają okazji uczestniczyć w spotkaniach Warszawa JUG, a którzy zainteresowani są tematyką Java EE 5 i projektów otwartych. Już nie mogę się doczekać! Proszę o nadsyłanie propozycji tematów, które chcielibyście uslyszeć na konferencji w moim wydaniu (czyż nie jest to wspaniałe, że mogę popytać wkoło, czym miałbym zainteresować potencjalnych zainteresowanych?!)
Zainteresowanych konferencją odsyłam na http://www.sdevelopment.gigacon.org.
Nie, nie oznacza to, że skoro mamy 2007 rok to postanowienia z roku 2006 są przedawnione. Nadal zaczytuję się w specyfikacji EJB3 i pamiętam, aby wnioski upublicznić, choć nie ukrywam, że zbliżające się III spotkanie Warszawa JUG przypomina mi o przygotowaniu prezentacji, właśnie na ten temat. Dla przyciągnięcia uwagi nadmienię, że nadchodzący wtorek to dzień kolejnego spotkania Warszawa JUG. Zainteresowanych tematyką EJB3 serdecznie zapraszam. Nadal borykam się z ustaleniem precyzyjnego tematu spotkania, ale pewne jest, że będzie to coś o EJB3. Wspomnę o GlassFish, EJB3 i najprawdopodobniej o ostatnim osiągnięciu uruchomienia aplikacji przykładowej projektu JBoss Seam.
Ale skąd ten tytuł?! Wielu z Was wie, że moim osobistym marzeniem jest zorganizowanie konferencji w stylu JavaPolis, czy ApacheCon, czy może nawet JavaOne. Coś w kształcie 2-dniowej konferencji naszpikowanej warsztatami, prezentacjami na maksymalnie wyśrubowanym poziomie. Pomysł opiera się na idei, że tylko zintegrowane środowisko programistów i projektantów może uczyć się wzajemnie na własnych doświadczeniach. Nie chodzi o to, abyśmy spędzili czas na kolejnych prezentacjach, z których nic nie wynosimy. Konferencja miałaby polegać na "wstrzyknięciu" (ang. injection - ot takie popularne słowo ostatnio) kilku pomysłów, które po powrocie do naszych projektów natychmiast wdrażamy, udoskonalając je. Wierząc, że kiedyś uda mi się zorganizować taką właśnie konferencję, dzisiaj otrzymałem wiadomość od pani Katarzyny z Software-Konferencje o magicznym tytule "Zaproszenie do współpracy", której wycinek przytoczę (wierząc, że nie naruszam żadnych praw, a odwzajemniam się darmową reklamą konferencji):
Zespół Software-Konferencje organizuje ósma edycję konferencji Software Development GigaCon 2007, która odbędzie się 22-23 marca 2007 roku w Hotelu Marriott w Warszawie. Chcielibyśmy zaprosić Pana do wygłoszenia wykładu merytorycznego na naszej konferencji.
Oczywiście z wielką satysfakcją i zainteresowaniem przeczytałem wiadomość. Kompletnie zapomniałem, że istnieje już na rynku instytucja o ugruntowanej pozycji, która organizuje profesjonalne konferencje dla projektantów i programistów w Polsce. Nie mogłem zażyczyć sobie lepszego rozpoczęcia roku! Oczywiście, że zgodziłem się przyjąć zaproszenie! Jak inaczej mogłem zareagować na tak wspaniały prezent w 2007 roku! Temat mojego wystąpienia nie został jeszcze ustalony, ale na pewno będzie to mieszanka projektów otwartych (ang. OSS - open source software) wokół Java EE 5. Postaram się również przygotować prezentację-warsztat o Apache Geronimo i Apache OpenEJB 3. Do czasu konferencji zamierzam zbierać uwagi o możliwych tematach na konferencję. W końcu będzie to okazja spotkać wiele osób spoza Warszawy, którzy nie mają okazji uczestniczyć w spotkaniach Warszawa JUG, a którzy zainteresowani są tematyką Java EE 5 i projektów otwartych. Już nie mogę się doczekać! Proszę o nadsyłanie propozycji tematów, które chcielibyście uslyszeć na konferencji w moim wydaniu (czyż nie jest to wspaniałe, że mogę popytać wkoło, czym miałbym zainteresować potencjalnych zainteresowanych?!)
Zainteresowanych konferencją odsyłam na http://www.sdevelopment.gigacon.org.
Subskrybuj:
Posty (Atom)