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

05 października 2011

Java EE 6 Web Profile z Apache TomEE na warsjawie 2011

0 komentarzy
Nie masz czasami uczucia, jakby wszystko, co czynisz w swoim życiu było już wcześniej ustalone? Mnie czasami nachodzi taka myśl.

Wczoraj pisałem o moich wątpliwościach czytelniczych i jakby na dokładkę dostałem dzisiaj elektroniczne wydanie Pro Android 2 z Apress. Nie ma więc już mowy o siedmiuset stronicowej cegle, którą muszę taszczyć ze sobą, aby móc ją czytać bez względu na miejsce i porę. Temat się rozwiązał, jakby za dotknięciem czarodziejskiej różdżki - wystarczyło napisać do wydawnictwa z prośbą o kopię i nie trzeba było długo czekać na odpowiedź. Ten temat mam rozwiązany.

To jednak nie koniec moich kłopotów z terminarzem na najbliższe dni.

Mogłem się przecież spodziewać, że konferencja JavaOne, która właśnie trwa w San Francisco, może zmienić moje plany na najbliższe 2 tygodnie z łatwością. A może to jednak nasza, lokalna warsjawa, która odbędzie się za 2 tygodnie, 15 października w Warszawie? Sądzę, że obie miały wpływ, ale to warsjawa faktycznie zmusiła mnie do zmian. Zaproponowałem temat "Java EE 6 Web Profile z Apache TomEE" na warsjawę i zostałem przyjęty (wierzę, że to merytoryczne przygotowanie prelegenta, a nie jego urok czy udział w zespole organizatorów konferencji sprawiło, że tak się stało).

Dla tych, którzy jeszcze nie doświadczyli Java EE 6 w okrojonej wersji profilu webowego będzie to doskonała okazja poznać temat, a głównym graczem będzie Apache TomEE, czyli stary, ale wciąż jary i powszechnie wykorzystywany do tworzenia aplikacji korporacyjnych Apache Tomcat wzbogacony o elementy wymagane przez Java EE 6 Web Profile, czyli:
  • Apache OpenEJB - kontener EJB 3.1
  • Apache OpenWebBeans - kontener CDI 1.0
  • Apache MyFaces - kontener JSF 2.0
  • Apache OpenJPA - kontener JPA 2.0
Wszystkie z wymienionych dostarczają składników potrzebnych do zbudowania korporacyjnej wersji Apache Tomcat i przejścia przez rygorystyczne wymogi TCK dla Java EE 6 Web Profile. Właśnie wczoraj Apache Software Foundation (ASF) ogłosiło w The Apache Software Foundation Announces Apache TomEE Certified as Java EE 6 Web Profile Compatible, że:
Apache TomEE has obtained certification as Java EE 6 Web Profile Compatible Implementation.
Po około roku wytężonej pracy zespołowi programistów z projektu Apache OpenEJB udało się przejść przez TCK i stanąć dumnie w szpalerze certyfikowanych środowisk spełniających wymagania stawiane przez specyfikację, obok takich tuzów jak Oracle GlassFish Server 3.x, Caucho Resin 4.0.17 i JBoss Application Server 7.

Podczas warsjawy 2011 zamierzam przedstawić cele i zalety użycia Apache TomEE z NetBeans IDE 7.1. Tym samym nie powinno być już żadnych złudzeń, o czym będę się rozpisywał na tym blogu przez kolejne 2 tygodnie - Java EE 6 Web Profile, Apache TomEE i NetBeans IDE.

Zachęcam do dzielenia się uwagami w komentarzach poniżej. Gdyby nękały Cię pytania związane z tematem, życzyłbym sobie poznać je już teraz, aby podczas konferencji być przygotowanym i odpowiedzieć na kilka. Przez godzinę i kwadrans mojej prezentacji należy oczekiwać kwadransu wprowadzenia, aby później przejść przez kilka przykładów demonstracyjnych. Do zobaczenia w sobotę w Warszawie.

03 września 2011

Embeddable EJB 3.1 z Apache OpenEJB 4, Apache Maven 3 i IntelliJ IDEA 10.5

6 komentarzy
Opublikowałem właśnie nowy artykuł Embeddable EJB 3.1 z Apache OpenEJB 4, Apache Maven 3 i IntelliJ IDEA 10.5, który kontynuuje cykl przedstawiania nowych cech specyfikacji Enterprise JavaBeans (EJB) 3.1. Chodził za mną od kilku dni i potrzeba mi było zebrać się w sobie, aby w końcu usiąść i napisać go. W końcu jest!

Zapraszam do lektury i komentarzy. Dla zwrócenia uwagi napiszę, że w samym ziarnie MySession popełniłem kilka błędów architektonicznych, w których zakładam pewne zachowanie ziarna bezstanowego mimo, że takowej nie oferuje (bez świadomej i specyficznej konfiguracji kontenera). Ciekawym komu uda się zauważyć moją pomyłkę, albo kilka? Zachęcam do dyskusji.

20 sierpnia 2011

"Uruchomienie cyklicznego zadania w EJB 3.1 ze @Schedule" udoskonalone

0 komentarzy
W trakcie odpowiedzi na pytanie @Schedule on Stateless EJB 3.1 on JBoss 6.0 Final na forum JBoss EJB3, nieznacznie usprawniłem artykuł Uruchomienie cyklicznego zadania w EJB 3.1 ze @Schedule na moim Wiki. Podniosłem wersję GlassFish do 3.1.1 i użyłem profil mavenowy do uruchomienia jego śledzenia.

Chętnie usłyszałbym komentarze do treści, formy i w ogóle kierunku dalszej nauki EJB 3.1. Z jakimi serwerami uruchamiacie własne projekty z EJB 3.1? GlassFish? JBoss AS 7? A może wciąż JBoss AS 6? IBM WebSphere Application Server 8? Apache OpenEJB? Co było zaskakujące podczas uruchomienia? Poszukuję natchnienia zanim całkowicie oddam się Androidowi (wrzesień), więc wszelkie komentarze związane z EJB 3.1 i artykułem wielce mile widziane.

19 lipca 2011

Book review: EJB 3.1 Cookbook

7 komentarzy
Okres wakacyjny sprzyja spędzaniu czasu na lekturze książek, które zalegają od dawna na mojej półce. Właściwie, EJB 3.1 Cookbook to była swego rodzaju "wrzutka", którą zaproponowano mi do recenzji z wydawnictwa Packt Publishing. I to był błąd. Kolejny raz przekonałem się, aby nie iść na skróty i czytać książki-streszczenia, czy poradniki (ang. cookbook w wolnym tłumaczeniu), kiedy na półce stoi i czeka Enterprise JavaBeans 3.1, Sixth Edition z O'Reilly. Dostałem po łapach i powinienem już zapamiętać, że lepiej dwa razy się zastanowić niż spędzić czas na lekturze książki niskich lotów.

Więcej moich odczuć na temat książki EJB 3.1 Cookbook z Packt Publishing w mojej recenzji Book review: EJB 3.1 Cookbook. Przy okazji, zachęcam do oceny (przydatności) recenzji na Amazonie - Too basic, often repetitive and thus boring - 400 pages yet 100 would make it a better reading. Na chwilę obecną zajmuję "New Reviewer Rank: 13,857" z "Helpful Votes: 110" i chyba dałem się wciągnąć w zabawę w roli recenzenta.

Zainteresowanych lekturą tej książki zapraszam do kontaktu na jacek@japila.pl.

18 marca 2011

Confitura 2011, 33rd degree, GeeCON i InfoShare oraz "markowy" inż. z OSGi i CDI

9 komentarzy
Dla tych, którzy spędzają wolne chwile z dala od komputera i mają tą rzadko spotykaną "przypadłość" cieszyć się wolnością umysłu bez wpływu facebooka, twittera, blogów, grup, forów i innych, mniej lub bardziej zajmujących serwisów, donoszę, że długooczekiwana data nie mniej długooczekiwanej konferencji polskiej społeczności javowej Confitura 2011, pod silnym przewodnictwem grupy Warszawa JUG, odbędzie się 11. czerwca 2011. Organizatorzy wierzą, że nie będzie to kolidowało z żadnymi z Twoich planów i stawisz się dzielnie podjąć każde wyzwanie intelektualne podczas konferencji.

Z pewnych rzeczy, to z pewnością miejsce - Warszawa, wspomniany termin - 11.czerwca oraz...cóż, chyba mi się skończyły pewne rzeczy. Agendy jeszcze nie ma, bo plan zakładał jej ustalenie po zebraniu propozycji tematów, o czym niebawem. Więcej na stronie konferencji Confitura 2011.

Jako współorganizator będę robił wszystko^H^H^Hwiele, aby konferencja była największą pod względem możliwości wymiany doświadczeń (jej wielkość niech będzie liczona możliwościami zdobycia praktycznej wiedzy i pomysłami, a nie liczbą uczestników) i chciałbym, aby pojawiło się wiele osób nowych, niekoniecznie z doświadczeniem występowania publicznego. Niech Confitura będzie platformą nauki, a buława prelegenta dana będzie wizjonerom, a nie oratorom (oczywiście osoby łączące te cechy są bardziej niż mile widziane). Zapraszam do udziału w konferencji w roli uczestnika i/lub prelegenta, z naciskiem na tą drugą. Warto! W razie jakichkolwiek wątpliwości zaleca się kontakt ze mną. Sprawdziłem i działa.

Skoro o konferencjach to pojawię się jeszcze na 33rd Degree w Krakowie, w dniach 6-8.04, InfoShare 12-13.05 w Gdańsku oraz GeeCON w Krakowie, w dniach 11-14.05.

Na pierwszej dwóch - 33rd Degree oraz InfoShare - biorę udział jako prelegent z tematami dotyczącymi EJB 3.1, CDI oraz językiem funkcyjnym Clojure. Nie zamierzam wprowadzać w temat, a podzielić się znaleziskami, których część mogłem już przedstawić na tym i moim angielskojęzycznym blogu - http://blog.japila.pl. Znużyło mnie ciągłe wałkowanie tematu od zera, co ani mnie nie bawi (wręcz zaczyna nużyć), a wielu przyprawia o ból głowy musząc słuchać tego samego w nieznacznie zmienionej postaci. I tylko wieje nudą. Szanujmy swój czas, co zamierzam zastosować właśnie podczas wspomnianych konferencji.

Na 33rd Degree będę wyłącznie w piątek, 8.04 (z noclegiem w Krakowie przed i po), a na InfoShare 13.05 (prawdopodobnie z noclegiem do soboty). Piszę o tym, aby pozwolić sobie na przyjemność spotkania się z osobami, z którymi mógłbym przegadać to i owo, a z którymi nie dane mi było spotkać się do tej pory. Zwykle to właśnie dyskusje pozwalają na ugruntowanie wiedzy, a nie bierny udział w prezentacji i możliwość spotkania się wieczorem w pubie czy restauracji uważam za obowiązkowy.

Uważni mogli zauważyć, że terminy InfoShare oraz GeeCON pokrywają się. Dzięki uprzejmości organizatorów GeeCONa otrzymałem wejściówkę, więc łącząc przyjemne z pożytecznym na GeeCONie pojawię się 11-12.05, aby wieczorem udać się do Gdańska, w którym chciałbym spędzić czas do soboty. Nie będzie lekko opanować terminy i chęć zamienienia słowa z uczestnikami, ale nikt nie mówił, że powinno. Na projektach też nie jest lekko, a jednak mają coś magicznego, co nas do nich wciąż ciągnie.

I ostatnia sprawa, nie mniej ważna, o której zaplanowałem napisać - praca inżynierska mojego podopiecznego z praktyk studenckich w IBM - Marka Szpaka dotycząca "analizy połączenia CDI i OSGi (na przykładzie serwera aplikacyjnego GlassFish i IBM WebSphere Application Server) oraz zaprezentowania rozwiązania wolnego od konkretnego serwera aplikacyjnego."

Na temat samych praktyk można przeczytać chociażby na grupie GoldenLine Praktyki w IBM Polska, albo bezpośrednio u "producenta" - IBM Educational Student Internships i gorąco zachęcam do wzięcia w nich udziału. Nie stronię od nawet najbardziej opornych studentów, którym się jednak chce coś zrobić i na brak wrażeń nie można narzekać.

Marek nie tylko próbuje rozpracować możliwość budowania aplikacji korporacyjnych JEE6 z użyciem CDI i OSGi, o czym będzie można przeczytać w jego pracy, ale również organizuje prelekcję na ten temat na swojej uczelni - Uniwersytecie Zielonogórskim. Co mnie bardzo ucieszyło, zaprosił mnie nawet w roli współprelegenta (!) Opiekunem tematu jest pan dr inż. Andrzej Marciniak. Na chwilę obecną wiadomo jedynie co będzie przedstawione - CDI, OSGi i ich połączenie z GlassFishem i WASem, kto - Marek i Ja, a z terminem to jedynie "jeszcze w tym semestrze, to jest najpóźniej pod koniec maja/początek czerwca." Zainteresowanych już informuję, a dalsze informacje niebawem. Wszelkie sugestie mile widziane, czy to związane z terminem, czy też zakresem merytorycznym. Niech to będzie przyczułek do wymiany wiedzy, która mogłaby zaowocować jakimś ciekawym projektem OSS, a może i produktem komercyjnym (?)

Tym samym chciałbym oficjalnie podziękować Markowi i Uniwersytetowi Zielonogórskiemu w osobie p. dra inż. Andrzeja Marciniaka za umożliwienie mi zgłębienia tematu, co powinno przyczynić się do większego rozpoznania tematu po obu stronach, również z korzyścią dla czytelników tego bloga.

Pierwsza połowa 2011 zapowiada się baaardzo interesująco merytorycznie. Już wiem, że druga również, ale o tym jeszcze ciiiii. Czego lepszego mogłem sobie życzyć w 2011. Normalnie bajka!

10 marca 2011

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

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

Zgodnie z javadoc dla @EJB:

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

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

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

import pl.japila.ejb.Hello;

@Stateless
public class TestFacadeEJB implements Hello {

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

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

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

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

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

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

09 marca 2011

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

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

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

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

07 lutego 2011

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

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

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

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

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

03 stycznia 2011

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

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

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

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

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

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

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

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

Zatwierdź przyciskiem ENTER.

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

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

Results :

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

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

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

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

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

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

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

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


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

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

Dla początkujących, jak znalazł.

30 grudnia 2010

Embeddable EJB 3.1 z GlassFish 3.1 i NetBeans IDE 7.0

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

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

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

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

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

20 grudnia 2010

EJB 3.1 z OpenEJB 3.1 i NetBeans IDE 7.0

3 komentarzy
Jest wiele sposobów na naukę nowych technologii i dobór odpowiednich narzędzi może znacząco usprawnić ten proces. W przypadku EJB 3.1 możemy skorzystać z projektu Apache OpenEJB 3.1, podpierając się NetBeans IDE 7.0 jako zintegrowanym środowiskiem programistycznym z asystentami tworzenia ziaren EJB z Apache Maven w tle.

Zastosowanie EJB 3.1 jest zwykle podyktowane względami praktycznymi, kiedy wybór serwera aplikacyjnego Java EE 6 mamy już za sobą i pozostaje wykorzystać jego usługi. Ich kompletność i gotowość do użycia najlepiej doświadczyć, kiedy konieczne jest wykorzystanie transakcji, podłączenia do bazy danych z możliwością przypisania komu i co wolno, udostępnić Web Service z wykorzystaniem REST w ramach aplikacji webowej czy podobne "deklaratywne czynności". Nie ma konieczności zestawiania gotowej konfiguracji usług, a konwencja ponad konfigurację znacznie przyspiesza dostarczanie kompletnych rozwiązań. Przenośność aplikacji jest również istotnym aspektem wyboru stosu technologicznego. Dodając do tego łatwość testowania aplikacji korporacyjnych i Java EE 6 (JEE6) wydaje się być idealną platformą aplikacyjną.

W tym artykule przedstawię uruchomienie bezinterfejsowego, niestanowego ziarna sesyjnego EJB (ang. no-interface stateless session bean) z użyciem projektu Apache OpenEJB 3.1.4, który stworzę w NetBeans IDE 7.0 (wersja rozwojowa z dnia 15.12.2010). Celem jest maksymalne zminimalizowanie czasu koniecznego do uruchomienia środowiska. Kolejną zaletą zastosowania OpenEJB jest możliwość wykonanywania wszystkich operacji projektowych (budowanie i testowanie) poza IDE, dzięki użyciu Apache Maven wspieranym przez NetBeans IDE 7 "z pudełka".

Więcej w artykule EJB 3.1 z OpenEJB 3.1 i NetBeans IDE 7.0.

14 grudnia 2010

33rd degree i ja z "EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6"

5 komentarzy
Skoro większość z Was wskazuje na Java EE 6 jako temat przewodni grudnia, to może niech i tak zostanie w nadchodzącym roku 2011. Ot, taka mała zapowiedź dalszych poczynań w blogosferze oraz konferencyjnie.

W mojej skrzynce pocztowej znalazłem wiadomość o nadchodzącej konferencji 33rd degree. Niewiele o niej wiadomo, bo temat bardzo, bardzo świeży. Mógłbym założyć, że na tyle, że jestem pierwszym, który pisze o tym na blogu (poza zapowiedzią u samych organizatorów - Wymarzona konferencja nadchodzi).

Piszę o tym, gdyż jest to kolejna konfencja javowa w Polsce, obok JDD, NYAC, GeeCON, Javarsovia, warsjawa, java4people czy 4Developers. Mimo, że wiele z nich cieszy się renomą, widać, że wciąż jest miejsce dla kolejnej. Do grona "uczestników" sceny konferencyjnej dołącza 33rd degree. Jak na tak niewielki kraj, możemy powiedzieć, że tyle u nas konferencji co partii politycznych (!) Może kiedyś dojdzie do jakiś fuzji konferencyjnych?! Tak czy owak, będzie wiele okazji, aby się spotkać i wymienić doświadczeniami. Będę miał w tym swój wkład!

Należy dodać, że markę 33rd degree chce się zbudować na "Top quality speakers that usually talks at big conferences and were chosen many times as Rock Stars" oraz "All speakers were invited personally and validated in practice. No surprises expected. Only great talks." (za stroną domową konferencji).

I teraz o moim wkładzie, a raczej wykładzie. Tak, tak, będę miał swoje 60 minut na przedstawienie tematu EJB 3.1 vs Contexts and Dependency Injection (CDI) and Dependency Injection for Java in Java EE 6. Na razie mam jedynie szkic, co chciałbym przekazać słuchaczom i w jaki sposób, aby dotrzymać kroku innym wystąpieniom, gdzie slajdy należy potraktować za...relikt przeszłości i eksponat muzealny. Sprawa się będzie klarowała w kolejnych miesiącach.

Pora na rozlosowanie specjalnych kodów promocyjnych. Mam ich 10 (i nie zawaham się ich użyć pro publico bono). Niech jednak będzie to transakcja wiązana (bodaj jedyna legalna forma obdarowywania bezkosztowo w PL), gdzie ja Tobie, a Ty mi i jesteśmy kwita. Proszę o wyrażenie swojej opinii nt. połączenia wystąpienia z wcześniej przygotowanymi nagraniami (coś ala skrinkasty) i lokalnym repozytorium wersji kodów źródłowych, aby zamiast klepania (rękoma i ustami) interakcja między prelegentem a uczestnikami przebiegała znacznie szybciej i bez ryzyka utraty tempa czy toku rozumowania. Rola prelegenta sprowadziłaby się do zaprezentowania nagrań i uzupełniania ich słowno-muzycznie. Czy to ma rację bytu? Wsród osób, które wyrażą swój głos w komentarzu do tego wpisu rozlosuję po jednym specjalnym kodzie promocyjnym na konferencję 33rd degree.

06 grudnia 2010

Odkrywcze podobieństwo Java SE i Java EE z CDI na czele

5 komentarzy
Każdy, kto programuje w Javie "siedzi" na poziomie Java Standard Edition, w skrócie Java SE, czy wręcz JSE. Obecna wersja to 6.0. Mamy do dyspozycji cały zestaw interfejsów i klas - wszystko objęte terminem Java SE API. Dokumentacja do aktualnej wersji znajduje się na stronach Java Platform, Standard Edition 6 API Specification. To powinno być oczywiste i należy do podstawowej wiedzy programisty Java.

Co jednak nie jest już tak oczywiste, to jak niewiele różni obecnie JSE od kolejnego zestawu Java API o nazwie Java Enterprise Edition, w skrócie Java EE, albo po prostu JEE. Zwracam Twoją uwagę na termin "kolejny zestaw Java API". Od lat siedzę przy obu zestawach - JSE i JEE, a jednak dopiero teraz dotarło do mnie, jak niewiele je różni - wszystko za sprawą środowiska uruchomieniowego, które określa zachowanie naszej aplikacji.

Do wersji JSE 5.0 wcale nie było oczywistym, że umiejętność programowania na platformie JSE jest równoznaczna z JEE. Nie grzebiąc za długo w historii JEE postawię tezę, że umiejętność posługiwania się JSE była dalece niewystarczająca od posługiwania się JEE. Wiele się być może nie zmieniło chyba, że nie mówimy o właściwym użyciu API (semantyce), a jedynie umiejętności użycia konstrukcji (składni). Tu widzę duże uproszczenia.

Od wersji JSE5 mamy adnotacje. Możliwość dopisywania metainformacji na różnym poziomie naszych bytów javowych - interfejsów, klas, pól i metod. Szybko zauważono ich zaletę i zaraz wprowadzono na JEE. I jakkolwiek tworzenie aplikacji na poziomie JSE zmieniło się nieznacznie, to w przypadku JEE postęp jest ogromny.

Poniżej klasa do uruchomienia na platformie JSE.
package pl.jaceklaskowski.blog;

public class BlogEntry {
    private String title;

    public BlogEntry(String title) {
        this.title = title;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }
    
    public BlogEntry create(String title) {
        return new BlogEntry(title);
    }
}
Od wersji JSE5 można dodawać do klasy metadane w postaci adnotacji. Dwoma z adnotacji dostarczanych w ramach zestawu JEE5 są @Entity oraz @Id.
package pl.jaceklaskowski.blog;

import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public class BlogEntry implements Serializable {

    @Id
    private int id;
    private String title;

    protected BlogEntry() {
    }

    public BlogEntry(String title) {
        this.title = title;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getTitle() {
        return title;
    }

    public void setTitle(String title) {
        this.title = title;
    }

    public BlogEntry create(String title) {
        return new BlogEntry(title);
    }
}
Poza dodaniem tych dwóch adnotacji pojawiły się również zmiany w samym kodzie klasy. I jakkolwiek samo użycie adnotacji nie wymaga ich, to użycie na platformie JEE może uczynić je obowiązkowymi do poprawnego użycia klasy. Aby ujawniła się ich obowiązkowość konieczne jest uruchomienie klasy w ramach platformy JEE, tj. serwera aplikacyjnego JEE (którego zadaniem jest udostępnienie usług respektujących wytyczne specyfikacji JEE) oraz użycie konstrukcji aktywujących daną funkcjonalność. Innymi słowy, samo uruchomienie w ramach serwera aplikacyjnego JEE nie jest równoznaczne z użyciem usługi, która interpretuje adnotacje. Nie zamierzam jednak tym razem wnikać w szczegóły i unikam wyjaśnień wskazując podręcznik The Java EE 6 Tutorial, a szczególnie rozdział Part VI Persistence. Obowiązkowa lektura dla każdego, któremu marzy się tworzenie aplikacji korporacyjnych w JEE, o których w kolejnych wpisach.

I te małe dodatki - metadane w postaci adnotacji - mnie dzisiaj zachwyciły. Podczas lektury artykułu w Sieci na temat tworzenia Web Services, olśniło mnie, że aplikując adnotacje do klasy i uruchamiając ją w ramach serwera aplikacyjnego dostajemy wiele przy tak niewielkim nakładzie pracy.

Przyjrzyj się poniższej klasie.
package pl.jaceklaskowski.blog;

public class BlogPanel {
    public Blog createBlog(String title) {
        return new Blog(title);
    }
}
Niewiele w niej cech aplikacji korporacyjnej, którą cechuje użycie bazy danych (często wielu równocześnie), dostęp do innych zasobów transakcyjnych, różne protokoły dostępowe (wszechobecny HTTP może być uzupełniany przez chociażby FTP czy IMAP) czy bezpieczeństwo. To tylko niektóre z możliwych usług serwera aplikacyjnego JEE.

Przyjrzyjmy się kolejnej wersji wcześniejszej klasy BlogPanel, która różni się jedynie adnotacją @Stateless.
package pl.jaceklaskowski.blog;

import javax.ejb.Stateless;

@Stateless
public class BlogPanel {
    public Blog createBlog(String title) {
        return new Blog(title);
    }
}
Tym razem, poza @Stateless, nic więcej się nie zmieniło. Czyżby?

Jeśli uruchomisz tę klasę na serwerze aplikacyjnym JEE, okaże się, że wykonanie metody createBlog(String title) pociągnie za sobą wzbudzenie monitora transakcji i uruchomienie dedykowanej transakcji, która rozpocznie się i zakończy z rozpoczęciem i zakończeniem wykonania ciała metody. Dodatkowo, każdemu będzie wolno wykonać tę metodę, ale samo sprawdzenie zostanie wykonane. Jak widać, użycie tak niewinnie wyglądającej adnotacji @Stateless może odmienić zachowanie aplikacji, a jej czas wykonania wydłuży się kosztem opakowania jej usługami serwera.

Tak wiele, tak niewielkim kosztem - odkrywcze podobieństwo między JSE a JEE.

W JEE6 pojawiło się rozszerzenie oferowanego API o pakiety javax.enterprise.inject, javax.enterprise.context oraz javax.enterprise.event, które materializują wytyczne specyfikacji JSR 299: Contexts and Dependency Injection for the Java EE platform, w skrócie CDI. Sama specyfikacja jest częścią Java EE 6 i przez to obowiązkowa w ramach serwerów aplikacyjnych JEE6 (tu należy zwrócić uwagę na wersję wspieranego zestawu JEE - musi być 6).

I tutaj było moje największe odkrycie, a w zasadzie faktyczne przetrawienie wszystkiego, co do tej pory usłyszałem na temat JEE6, EJB 3.1, JSF 2.0, JPA 2.0, Servlets 3.0 i kilku innych.

Wszystkie byty na platformie JEE6 są opisywalne przez adnotacje.

Z tego płynie bardzo istotna wiedza pozwalająca zrozumieć sedno działania serwera aplikacyjnego JEE i związywania usług do odpowiednich składowych (komponentów) naszej aplikacji. Wystarczy zaaplikować adnotację i jak za dotknięciem czarodziejskiej różdżki pojawi się automagicznie pożądana funkcjonalność (ortogonalna do funkcjonalności biznesowej, którą oprogramowujemy i tu jest właśnie miejsca dla naszej inwencji twórczej).

Skoro CDI to specyfikacja odnosząca się do definiowania kontekstu funkcjonowania bytu zwanego ziarnem zarządzanym (ang. managed bean) - wcześniej termin zarezerwowany przez specyfikację JSF) i to właśnie kontekst wyznacza jego cykl rozwojowy (ang. lifecycle) - przejścia między stanami, w których wyróżnionymi są utworzenie i zniszczenie obiektu, wtedy można postawić tezę, że wszystko, co mamy do dyspozycji jako programiści JEE6 można oprzeć na CDI.

W ten sposób Resin - kontener webowy - oferuje EJB 3.1 przez CanDI. Pewnie będzie można zauważyć podobny trend w innych serwerach aplikacyjnych.

CDI jest również możliwe do uruchomienia na platformie JSE6, ale w takiej konfiguracji będziemy musieli rolę serwera przejąć na siebie i oprogramować w ramach aplikacji. Nawet, jeśli CDI i JEE6 nie są doskonałe, to są standardem, który zmierza w dobrym kierunku. Po czasach rozterek JEE vs Spring Framework+Hibernate mam wrażenie, że wybór staje się bardziej oczywisty. Mnie to cieszy.

29 listopada 2010

Po wykładzie na PWSZ w Tarnowie

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

27 listopada 2010

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

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

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

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

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

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

Konspekt

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

21 listopada 2009

Eclipse DemoCamp we Wrocławiu aż nazbyt emocjonujący

1 komentarzy
Właśnie doświadczyłem niezwykle interesującego zakończenia Eclipse DemoCamp 2009 we Wrocławiu. Siedzę sobie w hotelu Diament, po tym, kiedy odwołano ostatni lot do Warszawy ze względu na niewielką widoczność na lotnisku Okęcie. Zawrócono samolot spod Łodzi, abym ponownie zjawił się we Wrocku i po godzinie zamieszania znalazł miejsce w hotelu na koszt Lotu (taksówka z/na lotnisko i śniadanie w cenie). Hotel nowy i przyzwoity, ale to, że zamiast siedzieć w weekend w domu, siedzę w hotelu do najprzyjemniejszych nie należy. Wykańczający jest również brak pożądnego miejsca, gdzie możnaby coś zjeść na lotnisku. Pozostają kanapki i futrowanie się słodyczami :( Kolejnym razem pomyślę dwa razy zanim wybiorę przelot powrotny do Warszawy ostatnim rejsem.

A wracając do samej konferencji, to byłbym nieprzyzwoicie nieprzyzwoity, gdybym nie napisał, że warto było wstać o 5:30, aby móc w niej uczestniczyć. Możliwość spotkania się z Grzegorzem Białkiem, Krzyśkiem Kowalczykiem, Jackiem Pospychałą i innymi programistami Java z Wrocławia bezsprzecznie kwalifikuję jako bezcenne doświadczenie w moim życiu. Było wiele o wnętrzu platformy Eclipse, że w pewnym momencie mnogość akronimów mnie przygniotła. Nie zdawałem sobie sprawy, że jest tyle projektów pod parasolem Eclipse Foundation - EMF, XPAND, ATF, to tylko niektóre, które odnotowałem. Widać różnicę w podejściu do Eclipse DemoCamp w Warszawie a Wrocławiu. My (Warszawa) proponujemy raczej narzędziową stronę Eclipse IDE, podczas gdy oni (Wrocław) oferuje zajrzenie w głąb Eclipse jako platformy. Ciekawe doświadczenie móc zobaczyć produkt od tej strony. Nie ukrywam, że czułem się lekko zmieszany tą niewiedzą produktową o Eclipse.

Jacek Pospychała rozpoczął EDC z prezentacją na temat niedoskonałości darmowej "oferty" Eclipse IDE, aby pokazać nam swoje cudo oparte o Eclipse Ajax Tools i Web Tools Platform - Zend Studio. Podobało mi się, bo umożliwiało śledzenie wykonywania HTML, CSS i JavaScript, czyli tych technologii, wokół których krążę, ale ze względu na brak narzędzi programistycznych zwykle traktuję notatnikiem, albo innymi zewnętrznymi do IDE narzędziami, jak Firebug. Z Zend Studio możemy mieć to w ramach Eclipse IDE (pomijając fakt, że to narzędzie rodem z PHP).

Później na scenie pojawił się Grzesiek Białek - organizator wrocławskiego EDC i rozpoczął swoją krucjatę nt. Eclipse Modeling Framework (EMF). Generatory rządzą. Tak mogłem odebrać prezentację Grześka. To, że nie tylko ja odjechałem na jego prezentacji niech świadczy, że komputer wiedział, jaki materiał go czeka i chyba zlitował się nad publiką prezentując...Blue Screen of Death. I to na samym początku! Grzesiek rozpoczął od prezentacji swojego dzieła licencjackie - ruch ręką w 2001, później 2003 większa aplikacja na modelu, aby w 2004+ wszedł na Eclipse Platform.
Na sali była część osób, które buduje/-owały rozwiązania na Eclipse Platform. Zdaniem Grześka, Eclipse EMF napędza niektóre zmiany w samej Java SDK, np. w Java 7 będzie coś co powstało początkowo w EMF, a teraz jest "wczytywane" w Java SE (niestety nie pamiętam, co to było). Jako podsumowanie jego wystąpienia niech przytoczę zdanie, które padło po kilku moich pytaniach - "Nie brakuje mi niczego, co mógłbym otrzymać od Eclipse EMF, bo jeszcze nie wiem, czego mogłoby mi brakować" :)

Po Grześku pizza i moja prezentacja nt. powiązania Enterprise JavaBeans i OSGi z Apache OpenEJB. Po zaplanowanych 1,25h mógłbym skończyć, ale nie wykazano zainteresowania tym planem, więc skończyłem po 2h. Miałem wrażenie, że przekazywałem wiedzę składnie (brak skromności to moje drugie ja) i kontakt z publicznością został nawiązany, więc liczę na kilka ciekawych inicjatyw wokół tematu EJB3, OSGi i OpenEJB z kierunku południowo-zachodniej strony Polski. Ja jestem zadowolony z dyskusji, jakie się wywiązały i pomijając odpowiedź z XMLem było cacy (pozdrowienia dla zwycięzcy wafelka :)). Chciałbym wierzyć, że publika również wyszła zadowolona z mojej prezentacji zakończonej demonstracją rozwiązania w akcji.

A faktycznie wyszła, więc kiedy pojawił się Krzysiek Kowalczyk było już ciemno za oknem i część publiki się rozeszła. Pewnie trochę zmęczyłem ich tym moim gadaniem i jeszcze pora, więc sorry Krzysiek za przepłoszenie potencjalnych zainteresowanych tematyką, którzy nie mogli doświadczyć cudów techniki w Eclipse z Twojej perspektywy. Ponownie pojawił się EMF i...niestety, ale odpuściłem sobie występ Krzyśka. Odsiedziałem swoje przed kompem na holu.

W międzyczasie wywiązała się dyskusja na tematy różne, która zakończyła się dyskusją nt. anglicyzmów w naszym języku branżowym. Argumenty padały za i przeciw stosowaniu polskich odpowiedników, ale te, które użyłem w mojej prezentacji OSGi zostały zaakceptowane bez dwóch zdań. Ufff.

Bardzo ucieszyłem się, kiedy widziałem grupki rozmawiających ze sobą osób. Czuć było klimat społecznościowy EDC. Było około 35 osób. Z tego, co mówił Grzesiek chciało przyjść więcej, ale ze względu na wymogi żywieniowe zdecydował się na zamknięcie rejestracji przy 40tu zarejestrowanych.

Podsumowując, było fajnie. Były również zdjęcia, ale na nie poczekamy, aż Grzesiek i Krzysiek wrzucą je na Sieć. Dziękuję Grześkowi za zaproszenie na EDC i możliwość wystąpienia z prezentacją o moich ostatnich dokonaniach w Apache OpenEJB. Nie żałuję!

Włączam tryb oczekiwania na foty...

p.s. Jesienny Eclipse DemoCamp 2009 w Warszawie już w nadchodzący wtorek, 24.11 od 18tej na MIMUWie.

09 października 2009

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

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

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

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

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

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

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

05 października 2009

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

8 komentarzy
Niedawno dostałem do skrzynki takie pytanie:

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

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

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

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

12 czerwca 2009

OpenEJB 3.1.x, EJB 3.1, @ApplicationException oraz maven.surefire.debug

1 komentarzy
Pewnie zastanawiasz się, skąd ta różnorodność tematyczna w temacie, co? Dla mnie też było to niemałym zaskoczeniem, kiedy uzmysłowiłem sobie, ile rozwiązań przewinęło mi się dzisiaj, aby rozwiązać wydawałoby się początkowo banalne zgłoszenie OPENEJB-980 @ApplicationException inheritance. Najpierw sądziłem, że to kwestia prześwietlenia dostępnych klas w poszukiwaniu adnotacji @ApplicationException. I tutaj pierwsze bliższe spotkanie z ASM, który wykorzystywany jest w Apache XBean do prześwietlania klas bez konieczności ładowania ich do pamięci JVM z użyciem Reflection API. Wystarczy uruchomić ASM, który poprzez wykorzystanie wzorca projektowego Visitor pozwala na gromadzenie informacji o przetwarzanej klasie. W ten sposób do pamięci PermGen, gdzie trzymane są wszystkie definicje wczytanych klas, nie trafiają definicje, które nie są w użyciu i nie puchnie ona niepotrzebnie.

Miałem już listę klas, które są oznaczone adnotacją @ApplicationException oraz ich potomków. Przyszła więc pora na obsługę samego wyjątku, który niezgodnie z zasadami mechanizmu adnotacji w Javie powinien być oznaczony przez @java.lang.annotation.Inherited, gdyby miał być faktycznie dziedziczony (zdanie w 3. trybie warunkowym z opuszczeniem "if" możecie znaleźć w komentarzu Davida Blevinsa do zgłoszenia - "Had the annotation intended to be inherited it would have been annotated with @Inherited which causes the annotation to be propagated to all the subclasses as described"). W rzeczywistości jednak taka zmiana trafiła do specyfikacji EJB 3.1, w której, mimo, że adnotacja !ApplicationException nie jest @Inherited może taką być przez element inherited z wartością logiczną (domyślnie jest true, czyli jest propagowany w dół hierarchii dziedziczenia). W swoim komentarzu, Dave zaprezentował krótki przykład, który pokazuje, gdzie jest problem (początkowo miałem problemy z dokładnym zrozumieniem tematu, aż do tej chwili, kiedy pojawił się ten przykład - może i Tobie się przyda, o czym ja).

Zajrzałem do specyfikacji EJB 3.1 PFD (ang. Proposed Final Draft) z 24. lutego 2009, rozdział "14.2.1 Application Exceptions" (str. 378). W EJB 3.1, przypisanie wyjątku kontrolowanego (ang. checked exception) jako wyjątku aplikacyjnego dotyczy również wszystkich wyjatków pochodnych. Wystarczy jednak skorzystać z elementu inherited z wartością false, aby dziedziczenie wyłączyć (alternatywnie można użyć elementu application-exception w deskryptorze XML). Zastanawiam się skąd ta decyzja. Pewnie nadanie @Inherited do adnotacji @ApplicationException złamałoby kontrakt, a dodanie elementu już nie (?)

Na stronie 380 specyfikacji EJB 3.1 PFD pokazany jest przykład z wyjątkiem aplikacyjnym dziedziczonym (ExceptionA) oraz nie (ExceptionC). Kolejne miejsce do nauki przez przykład. Jest krótki, więc zdecydowanie nie ma się nad czym zastanawiać, tylko zapoznać się z nim.

Wprowadziłem odpowiednie zmiany w Apache OpenEJB, więc kolejne wersje będą to honorowały (na razie ignorowana jest wartość "inherited" i wszystko jest tak, jakby było "inherited=true"). Jako gotowy przykład do uruchomienia proponuję zajrzeć do aplikacji demonstracyjnej towarzyszącej zmianie applicationexception. Mając klienta Subversion oraz Apache Maven 2, wystarczy
 svn co https://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/applicationexception
cd applicationexception
mvn test
UWAGA: Zmiany potrzebne do uruchomienia przykładu nie są jeszcze rozpropagowane po repozytoriach mavenowych, więc z pewnością zakończy się BUILD FAILURE. Dodatkowo, początkowe uruchomienie pobiera wiele (chyba zdecydowanie za wiele) zależności ze zdalnych repozytoriów, więc przygotuj się na dłuższą przerwę. Najlepiej po prostu ściągnąć źródła OpenEJB i give it a try.

Pozostaje jeszcze wyjaśnić maven.surefire.debug z tytułu wpisu. Pisząc test jednostkowy do tej zmiany użyłem adnotacji @Test(expected = ValueRequiredException.class), która instruuje JUnit, że w teście oczekuje się zgłoszenia wyjątku ValueRequiredException. Początkowo nie wiedziałem, dlaczego ta zmiana to za mało i każdorazowe uruchomienie Mavena kończyły się BUILD ERROR. Doprowadzało mnie to do szału, aż znalazłem rozwiązanie - wyrzucenie "extends TestCase" z definicji klasy testowej ThrowBusinessExceptionImplTest (!) Jeszcze uaktualniłem JUnit do wersji 4.6 oraz maven-surefire-plugin do 2.4.2 i wszystko zaczęło działać poprawnie. W międzyczasie rozglądałem się za dostępnymi, specjalnymi ustawieniami w Mavenie, które mogłyby mi pomóc (wiedziałem, że to może być coś związanego z Mavenem, albo samym testem, ale nie wiedziałem dokładnie co), aż natrafiłem na stronę Debugging Tests. Zamiast definiować konfigurację śledzenia (debugowania) testu w pom.xml wystarczy skorzystać z parametru maven.surefire.debug. Test jest zatrzymywany i oczekuje na podłączenie klienta JDWP...ekhm...zdalnego debuggera. Można również skorzystać z mvnDebug i parametru forkMode, o czym również nie wiedziałem. Do tej pory, kopiowałem konfigurację uruchomienia z włączonym debug do wtyczki maven-surefire-plugin w pom.xml, a tu proszę, rozwiązanie gotowe i pod ręką.

Ze zgłoszenia OPENEJB-980 pozostaje mi jeszcze obsłużyć element inherited w @ApplicationException i temat będzie całkowicie zamknięty. Uwagi mile widziane i pożądane. Nie jest to zmiana najwyższych lotów, a wpisy Łukasza Lenarta Jak cię widzą, tak cię piszą czy Pawła Szulca Testing and Testable Code Presentation tylko mnie utwierdziły, że jeszcze wiele przede mną w temacie dobrych testów jednostkowych.

Z ciekawostek na koniec - podczas testowania przykładu z pustym repozytorium mavenowym zauważyłem, że Apache Maven 2.1.0 pobiera zależności...równolegle (chyba tylko tak mogę interpretować, co zauważyłem - oznaczone na czerwono poniżej). A może jednak nie? To co miałoby to być?!

13 listopada 2008

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

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

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

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

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

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

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

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