Java EE, Scala, Play 2 i WebSphere Liberty Profile

Wielu z Was już z pewnością miało okazję zapoznać się z moimi literackimi (po)tworami, które dotykają tematyki integracji Java EE ze Scalą, a nawet uruchomienia Play Framework 2.1 na WebSphere Liberty Profile. Z moimi poczynaniami poszedłem tak daleko, że wręcz pokusiłem się o kontakt z twórcami produktów, którzy wcale nie oponowali, aby użyczyć mi trochę swojej wiedzy ku wzmocnieniu merytorycznym artykułów.

W ten sposób udało mi się stworzyć trzy artykuły z serii o roboczym tytule "Java EE, Scala, Play 2 i WebSphere Liberty Profile":

• Developing Java Servlets in Scala with Eclipse and WebSphere Application Server V8.5 Liberty Profile
• Scala as Shared Library for Java EE applications in WebSphere 8.5 Liberty Profile
• Deploying Play 2 applications to WebSphere 8.5 Liberty Profile

Byłbym niezwykle rad, gdyby ktoś zechciał podzielić się wrażeniami z lektury i wskazać miejsca wymagające większego wysiłku umysłowego. Kto pierwszy?

Nowy artykuł o pisaniu servletów w Scali z Eclipse i WebSphere Application Server V8.5 Liberty Profile

Ku mojemu zaskoczeniu, ostatni wpis Listy w Scali przyciągnął dość znaczą uwagę - pojawiły się komentarze, które nie pozostają w mojej głowie bez echa. Dają mocno do myślenia. teamon oraz dmilith nie odpuszczają w swojej krucjacie podniesienia wartości moich wpisów i ku okrzepieniu serc zebrałem się na napisanie czegoś dłuższego - artykułu Developing Java Servlets in Scala with Eclipse and WebSphere Application Server V8.5 Liberty Profile. Ciekawym Waszego zdania na TEN temat.

Jak napisałem na swoim angielskojęzycznym blogu planuję poświęcić kilka wieczorów na Play Framework, którego planuję uruchamiać na WebSphere Application Server V8.5 Liberty Profile, a może nawet na pełnym WebSphere Application Server 8.5. Gdyby ktoś zechciał pomóc, pokierować, to zapraszam do sekcji komentarzy poniżej lub maila. Dziękuję!

Poznań by poznać - Eclipse DemoCamp i GDG DevFest

Jakoś tak umknęło mi, aby napisać, że od czwartku do niedzieli będę w Poznaniu na dwóch konferencjach w zaszczytnej roli prelegenta - Eclipse DemoCamp (EDC) w czwartek o 21:15 (!) oraz GDG DevFest Poland w sobotę o 12:00.

W ten sposób mam możliwość odwiedzić Poznań, aby poznać ludzi i ich opinie na prezentowane tematy. Na to liczę. Nie zamierzam występować w roli eksperta omawianych tematów. Wyrosłem z takiego myślenia (że w moim przypadku jest to w ogóle możliwe). Interesuje mnie wyłącznie rola osoby, która spędziła trochę czasu, aby zrozumieć tajniki współistnienia Enterprise OSGi z Java EE w ramach IBM WebSphere Application Server V8.5 Liberty Profile (to w czwartek na EDC) oraz współbieżności na platformie Android (sobota podczas GDG DevFest) i chciałaby podzielić się zdobytymi umiejętnościami z innymi, aby ukierunkować dalsze zgłębianie tematu.

Liczę na liczne przybycie oraz aktywny udział uczestników, aby poświęcony czas - organizatorów, uczestników oraz prelegentów - był wyłącznie mierzony w skali pozytywnych doznań (zamiast negatywnie jako zmarnowany).

Klimat konferencji tworzą wszyscy zaangażowani i ostatnią rzeczą powinno być narzekanie, że było nieciekawie, kiedy wystarczyło zawłaszczyć trochę czasu dla własnych potrzeb. Namawiam do zadawania pytań, nawet w sytuacji, kiedy istnieje przekonanie, że jest to najbardziej trywialne i najmniej pożądane pytanie w danej chwili (skąd w ogóle mogłoby nam przyjść takie myślenie do głowy, skoro pytanie jeszcze nie padło?!) Konwenanse zostawiamy w domu i pracy, a na konferencję przychodzimy z otwartymi umysłami pozbawionymi obostrzeń w postaci przeszłych (zamierzchłych?) doświadczeń, które nauczyły nas wyłącznie słuchać bądź akceptować prawdy oczywiste.

Zachęcam gorąco do zabrania pomidorów, aby skorzystać z kilku, jeśli okaże się to jedynym sposobem na wyrażenie swojej opinii nt. oprawy prezentowanego tematu, a pewnie i tym samym przegonienie prelegenta ze sceny (ze skutkiem natychmiastowym i pewnie dożywotnim) :-)

Ja z TomEE na JDD 2012 w Krakowie

Nie mam co do tego jakichkolwiek wątpliwości - krakowskie JDD na stałe wpisało się w harmonogram polskiej społeczności javowej, a ostatnie ruchy proidei ku umiędzynarodowieniu jej przynoszą wciąż niewielkie, ale zauważalne rezultaty. Wciąż jednak uważam, że JDD to bardzo lokalna konferencja, która jedynie przez swoje usytuowanie (Kraków) potrafi przyciągnąć uczestników i prelegentów. Na moje oko przewinęło się przez nią 200 osób w szczycie, a prelegenci wciąż nie zachwycają. Wciąż brakuje mi na niej nazwisk, które mogłyby gwarantować poziom wystąpienia i możliwość zamienienia słowa już po. Właśnie ta cecha konferencji, gdzie siedzę z prelegentami (częściej) i uczestnikami (rzadziej) sprawia, że JDD i inne konferencyjne propozycje inspirują mnie do dalszego rozwoju i poszukiwań.

Konferencja JDD 2012 trwa 2 dni - 25.10 (czwartek) i 26.10 (piątek) - ale ze względu na kolejne wyjazdy konferencyjne na Ukrainę na JavaDay musiałem zadowolić się jedynie pierwszym dniem i spotkaniem wieczornym dzień wcześniej. Podczas dnia konferencyjnego wystąpiłem z prezentacją o Apache TomEE, który jak zapewne uczestnicy już dobrze pamiętają, jest "zwykłym" Apache Tomcat plus dodatki. Owe dodatki sprawiają jednak, że pracujemy z certyfikowanym środowiskiem spełniającym wymogi specyfikacji Java EE 6 Web Profile (TomEE). Mamy również do dyspozycji edycje rozszerzone o JAX-RS (TomEE JAX-RS) czy JAX-WS i JMS (TomEE+). Jak możnaby to określić - dla każdego coś dobrego.

Tylko po co mi kolejny serwer aplikacyjny? I to jeszcze jakiś tam TomEE? Zajrzyj do prezentacji, a może coś jednak znajdziesz w TomEE dla siebie?



Gdyby zliczać liczbę wystąpień frazy "TomEE is Tomcat" to pewnie byłaby to najczęściej wspominana fraza podczas mojego wystąpienia. Moim założeniem było odpowiedzenie na pytanie "Dlaczego TomEE?" i mimo, że robiłem, co mogłem, to i tak na koniec padło pytanie "Po co mi TomEE?" :-) Możnaby zapłakać, ale faktycznie ucieszyłem się. W końcu kiedy to pytanie padło, to skoro padło, to znaczy, że niewystarczająco dobrze wyjaśniłem tę kwestię, a pytanie z tłumu posłużyło jako dodatkowy katalizator, aby inni zwrócili uwagę na moją odpowiedź, co życzyłbym sobie, aby było na samym początku. Siła pytania od publiczności uważam, że jest porównywalna z moimi staraniami, aby odpowiedź przebiła się do umysłów uczestników i każda pomoc mile widziana. Mam wrażenie, że teraz, po 50 minutach mojego wystąpienia, kilku zgodziłoby się na spędzenie kilku chwil z TomEE w swoich rozwiązaniach. Naprawdę warto, bo wszystko, co nowe rozwija, a praca z TomEE to praca z Tomcatem plus uzupełnienia do profilu webowego Java EE 6. Nie będę gołosłowny, kiedy powiem, że tworzenie aplikacji webowych z TomEE jest znacznie przyjemniejsze niż z czystym Tomcatem. Spróbuj i postaraj się skontrować moje tezy.

Nadmienię, że w zanadrzu mam(y) przecież jeszcze IBM WebSphere Application Server V8.5 Liberty Profile, którym jestem zafascynowany i który może wydawać się być łudząco podobny do Apache Tomcat czy Apache TomEE, ale faktycznie nimi nie jest i ma również swoje małe poletko, na którym rządzi niepodzielnie lub za chwilę będzie - patrz Enterprise OSGi i wykorzystanie kodów źródłowych pełnego WASa. To dla związanych z WASem stanowi niebagatelny powód, aby przystanąć w rzędzie korzystających z Liberty Profile. W końcu, jeśli docelowym środowiskiem uruchomieniowym będzie IBM WebSphere Application Server, to ostatnią rzeczą, jaką należałoby zrobić, jako programista, to korzystać z serwera alternatywnego, a najgorszym rozwiązaniem byłoby korzystanie z serwera o mniejszych możliwościach, chociażby na płaszczyźnie pełności wsparcia dla specyfikacji Java EE. Czyż praca z Tomcatem przed wejściem na WASa, to nie obdzieranie ze skóry możliwości WASa i obniżania wartości cech, które udostępnia?! Warto o tym pamiętać, na długo zanim zacznie się psioczyć na środowisko docelowe - może to być związane z niewłaściwymi oczekiwaniami, których sami jesteśmy autorem (!)

Jeśli chcesz spróbować się z WAS V8.5 Liberty Profile, zachęcam do lektury moich artykułów. Oferuję dodatkowo swoją pomoc (licząc, że sam ją również otrzymam). Ty zadajesz pytania, ja odpowiadam - wirtualnie przez artykuły, fizycznie, siedząc przy kompie ramię w ramię. Podejmiesz wyzwanie? Spotkania WJUGowe czekają :-)

Organizatorzy konferencji wraz z radą programową, w skład której wchodził m.in. ten Sławek Sobótka, pozwoliła mi na uchylenie rąbka tajemnicy o sensowność zastosowania TomEE. Okazało się, że pytanie o wdrożenie produkcyjne, które skwitowałem niemiłym ruchem ramionami na znak niewiedzy, już po moim wystąpieniu, sprowokowało jednego z uczestników do podzielenia się swoimi doświadczeniami w produkcyjnym użyciu TomEE. Jest jednak w Polsce produkcyjne wdrożenie, którego wyłącznym celem było przesyłanie plików za pomocą Web Services i Tomcat^H^H^H...ekhm...to znaczy TomEE...świetnie się do tego nadawał. Osoba rekomendująca nie miała problemów z wyborem po krótkim spotkaniu z TomEE. Działa i na to użycie sprawdza się znakomicie. Branża bankowa.

Mieć wybór - to lubię najbardziej! Jeśli wydawało Ci się, że świat kończy się na JBoss AS, Glassfish czy Tomcat, to teraz dorzucam jeszcze WAS V8.5 Liberty Profile, Apache TomEE, Apache Geronimo i jeszcze nie sposób nie wspomnieć o Oracle WebLogic Server czy Jetty. Mnogość rozwiązań może przerazić, a to pewnie i tak jedynie ułamek wiedzy, której się od nas wymaga.

A skoro o wiedzy, to podczas spotkania wieczornego, Kuba z Allegro pozwolił sobie przypomnieć mi o referencjach w Javie - Weak-, Soft- oraz PhantomReference. Zawsze jakoś odkładałem rozpoznanie ich na półkę z innymi rzeczami oczekującymi mojej uwagi, ale teraz zostałem przywołany do porządku i muszę usiąść nad nimi i zrozumieć ich zastosowanie w praktyce. W końcu to jedynie 5 klas z pakietu java.lang.ref (!) Znasz? Korzystasz? Podziel się wrażeniami! Zawsze to przyjemniej być prowadzonym przez bardziej doświadczone osoby.

Właśnie to najbardziej cenię sobie w możliwości udziału w konferencjach - bezpośredni kontakt z osobami, z którymi trudno byłoby mi się spotkać w innych sytuacjach. Jakkolwiek moim obecnym marzeniem byłoby omówienie TomEE i Liberty Profile, to sam TomEE dał mi również wiele satysfakcji. Był także miły wieczór w doborowym towarzystwie i było wystąpienie na drugi dzień - nie mogę narzekać. Tylko trochę żałuję, że nie mogłem zostać na imprezie integracyjnej z czwartku na piątek, bo wydawało mi się, że wielu mogłoby jeszcze zagadnąć mnie o sensowność TomEE, Liberty Profile czy wręcz Clojure. Szkoda.

Moje slajdy z prezentacji Apache Tomcat + Java EE 6 Web Profile = Apache TomEE znajdują się już na slideshare. Miłego oglądania i gorąco zachęcam do komentarzy. Kiedy dwóch rozmawia, to nierzadko prowokuje do konfrontacji aktualnej wiedzy, której kwestionowanie prowadzi do dalszego rozwoju. Skoro ciągła integracja jest tak ważna w naszej profesji, to można wnioskować, że ciągła integracja społeczna również. Czego Tobie życzę.

p.s. Nagrania z prezentacji mają się pojawić w Sieci wkrótce. Podobnie zdjęcia.

Warsztaty z IBM WebSphere na PWSZ w Tarnowie - dzień 1

W ramach zadania "Przyszłość młodych w naszych rękach. Program zacieśniania współpracy uczelni z pracodawcami", które jest częścią projektu KLEKSS BIS Kapitał Ludzki - Edukacyjny Komponent Strategii Szkoły na uczelni PWSZ w Tarnowie mam okazję w ciągu 2 dni przedstawić aktualny stan zaawansowania prac IBM wokół nowych technologii - BPMN 2.0, Java EE 6 oraz aplikacji mobilnych z produktami, których data wydania jest zaplanowana dopiero na...15 czerwca! Mam okazję zaprezentować IBM WebSphere Business Process Manager V8, IBM WebSphere Application Server V8.5 Liberty Profile oraz IBM Worklight V5.0. Jako uzupełnienie stosu technologicznego, dodałem jeszcze programowanie funkcyjne z Clojure i dwudniowy maraton technologiczny trwa na dobre w Tarnowie! Wszystko praktycznie, z tworzeniem aplikacji na żywo i całkowicie bez slajdów - nie wliczając tego wprowadzającego o mnie :-)

Najbardziej podkręcony jestem możliwością zaprezentowania tych wszystkich technologii i produktów na żywo. Nie obyło się bez potknięć, chwil zadumy, ale mam wrażenie, że ogólnie poszło bardzo sprawnie.

O dziwo, jedynie jedna osoba wiedziała, a na drugiej trochę wymusiłem, określenie się z oczekiwanymi stawkami. Padło magiczne 4k PLN netto, co od razu skarciłem, że mi dumpingują rynek (!) Zakazałem mówić o tak niskich kwotach głośno i rozważyć bezpośrednie połączenie z Warszawą (chwilowo przerwane w Krakowie na okres remontu) jako potencjalny argument za większymi stawkami. Liczę na zastosowanie rad w działaniu.

Dzień 1 z BPMN 2.0, Java EE i IBM WebSphere

Dzisiaj miałem okazję przedstawić BPMN 2.0 oraz Java EE 6 z produktami IBM. Jutro zaplanowałem aplikacje mobilne (poprosiłem uczestników o przyniesienie swoich smartfonów), które będę tworzył w Javie (Android) oraz HTML5, CSS3 i JavaScript (IBM Worklight z użyciem PhoneGap, a w zasadzie Apache Cordova). Na podsumowanie turnee nie mogło zabraknąć Clojure. Nie wyobrażam sobie wystąpień publicznych bez jego udziału i nie mogło być inaczej w Tarnowie.

Podsumowaniem każdej trzygodzinnej sesji jest ankieta, którą uczestnicy wypełniają ku uciesze organizatorów i wykładowcy. Zebrałem wyniki i jestem trochę nimi zaskoczony. Myślałem, że to Java EE 6 wyjdzie mi dużo lepiej, a okazuje się, że udało mi się oczarować uczestników moją wiedzą o BPMN 2.0. Poniżej zestawienia średnich. Ciekawym Twojej interpretacji, gdzie wskazuje się największe niedociągnięcia (tych szukam najbardziej, aby kolejne inicjatywy tego pokroju były o niebo lepsze).

Wyniki pokazują potencjał naukowy drzemiący w studentach 2 roku PWSZ w Tarnowie i mogą stanowić ciekawy materiał badawczy dotyczący przyszłych adeptów informatyki praktycznej w Polsce. Grupa nie jest wielka, ale lepsze to niż nic. Prosiłem ich o najszczerszą szczerość.

Modelowanie procesów bieznesowych BPMN 2.0 w IBM WebSphere Business Process Manager V8.0

Uczestników (podpisanych na liście obecności): 22

Sposób prowadzenia zajęć: 13 osób na "Tak, odpowiadał" z 7 za "Średnio odpowiadał".

Wiedza merytoryczna (średnia): 5,23 (maksymalnie 6)

Umiejętność przekazywania wiedzy (średnia): 5,14 (maksymalnie 6)

Chętnie odpowiadał na pytania i udzielał wyjaśnień: wszystkie 22 osoby na "Tak".

Program wykładu: 16 osób na "Odpowiedni" z 6 osobami na "Za mało nasycony".

Oczekiwania: 4,5 (maksymalnie 6)

Uwagi:

• więcej zastosowań programu (BPM)
• przykłady gotowych projektów w BPM
• przedstawienie gotowego projektu
• przykłady z życia wzięte
• więcej przykładów gotowych procesów biznesowych
• przykłady praktyczne modelowania procesów biznesowych oraz aplikacji od strony klientów
• gotowy projekt
• sensowne użycie programu
• realne przykłady biznesowe z projektów
• krótki przegląd narzędzi BPMN
• większy nacisk na programowanie
• dokładnie sprecyzowany model rzeczywistego projektu biznesowego
• wyjaśnienie modelowania procesu biznesowego na konkretnym przykładzie biznesowym

O czym innym wartoby posłuchać?

• aplikacje mobilne
• 2 osoby za "Programowanie w Javie"
• 2 osoby za "Różne języki"

Java EE 6 z IBM WebSphere Application Server V8.5 i Eclipse IDE

Uczestników (podpisanych na liście obecności): 18

Sposób prowadzenia zajęć: 17 osób na "Tak, odpowiadał" z 6 za "Średnio odpowiadał".

Wiedza merytoryczna (średnia): 5,23 (maksymalnie 6)

Umiejętność przekazywania wiedzy (średnia): 5,09 (maksymalnie 6)

Chętnie odpowiadał na pytania i udzielał wyjaśnień: wszystkie 23 osoby na "Tak".

Program wykładu: 2 osoby na "Zbyt przesycony", 18 osób na "Odpowiedni" z 3 osobami na "Za mało nasycony".

Oczekiwania: 4,5 (maksymalnie 6)

Uwagi:

• Więcej rozbudowanych przykładów
• zagadnienia z projektowania serwisów internetowych opartych na Java EE i EJB

O czym innym wartoby posłuchać?

• 3 osoby za "Tworzenie aplikacji mobilnych"
• języki programowania
• 4 osoby za "Java od podstaw"
• AWT/Swing
• Spring MVC

Wątki podczas obsługi asynchronicznego żądania w Servlet 3.0 i IBM WebSphere Application Server 8.0.0.3

Kontynuując moje rozpoznawanie mechanizmów asynchronicznego przetwarzania żądań w Servlet 3.0, tym razem przysiadłem, aby rozpoznać ich obsługę w serwerze aplikacyjnym IBM WebSphere Application Server 8.0.0.3. Stworzyłem servlet, który wyświetla wątki uczestniczące w zadaniu.

package pl.japila;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/AsyncServlet", asyncSupported = true)
public class AsyncServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

        // Record the servlet's thread
        PrintWriter out = response.getWriter();
        out.printf("<h3>Servlet's thread: %s</h3>", Thread.currentThread());
        out.flush();
        
        // Put the request into asynchronous mode
        request.startAsync();

        // Run an asynchronous task via servlet 3.0's abstractions
        AsyncContext asyncCtx = request.getAsyncContext();
        MyTask mt = new MyTask(asyncCtx);
        asyncCtx.start(mt);
        
        // Run another asynchronous task via java's abstractions
        MyTask mt02 = new MyTask(asyncCtx);
        new Thread(mt02).start();

        out.printf("<h3>Servlet finishes its job</h3>");
    }

    public class MyTask implements Runnable {

        AsyncContext asyncContext;

        public MyTask(AsyncContext asyncContext) {
            this.asyncContext = asyncContext;
        }

        @Override
        public void run() {
            ServletResponse response = asyncContext.getResponse();
            try {
                // do the time-consuming job
                PrintWriter out = response.getWriter();
                for (int i = 0; i < 5; i++) {
                    out.printf("<h2>Hello from thread: %s (%d)</h2>", Thread.currentThread(), i);
                    out.flush();
                    Thread.sleep(1 /* secs */ * 1000);
                }
            } catch (IOException e) {
                e.printStackTrace();
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                asyncContext.complete();
            }
        }
    }
}

Czy widział(a)byś usprawnienia w tym servlecie?

Komentarz Tomka mógłby świadczyć o niepoprawności takiego podejścia, ale w moim przekonaniu jedynym obecnie problemem jest tworzenie wątku każdorazowo po otrzymaniu żądania i opcjonalnie brak określenia czasu oczekiwania na zakończenie. Alternatywnym i sądzę, że możliwym podejściem jest tworzenie pseudo-wątku za pomocą java.util.concurrent.Callable i skorzystanie z mechanizmów oferowanych przez pakiet java.util.concurrent. Na chwilę obecną wiem, że to możliwe (konsultant), ale nie wiem, jak to zrealizować (specjalista).

Wcześniejsze wpisy o przetwarzaniu asynchronicznym w Servlet 3.0:

• Asynchroniczne przetwarzanie w Servlet 3.0
• Uruchomienie wątku w servlecie w Servlet 3.0

Jego uruchomienie skutkuje wyświetleniem strony z uczestniczącymi wątkami. Uważam, że podział na dedykowane pule wątków w WASie, które można osobno stroić do potrzeb aplikacji, prezentuje się obiecująco.

A jak to wygląda na Twoim serwerze aplikacyjnym? Ciekawym wyników z GlassFish 3.1.2, JBoss AS 7.1.1, Apache Tomcat 7.0.27, Oracle WebLogic Server 12c i in. Wyniki można słać na priv, albo zamieścić bezpośrednio w komentarzu do tego wpisu. Gorąco zachęcam.

Uruchomienie wątku w servlecie w Servlet 3.0

Wczorajszy wpis "Asynchroniczne przetwarzanie w Servlet 3.0" przyciągnął uwagę Tomka oraz Grześka (a wiem również, że i Marcina) i utwierdził mnie w przekonaniu, że jeśli tylko temat poruszy się we właściwy sposób, może przyciągnąć uwagę skutecznie. Chciałbym móc poświęcić więcej czasu na Scalę i na niej budować takie zagadki, ale nie tym razem. Może ktoś zainspirowany spróbuje pociągnąć temat na swoim blogu, albo chciałby skorzystać z mojego?

Kontynuując poznawanie Servlet 3.0, mam kolejną zagadkę.

Poniższy servlet działa poprawnie, ale jedynie w obecnej "gołej" konfiguracji - nie korzystam chociażby z żadnych mechanizmów bezpieczeństwa. Gdzie jest potencjalny problem? Proszę wskazać linię jego możliwego wystąpienia. Dla pewnego uproszczenia zagadki podaję namiary na javax.servlet.AsyncContext.

package pl.japila;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/AsyncServlet", asyncSupported = true)
public class AsyncServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {

        // Put the request into asynchronous mode
        request.startAsync();

        // Run an asynchronous task
        MyTask mt = new MyTask(request, response);
        mt.run();
    }

    public class MyTask implements Runnable {

        HttpServletRequest request;
        HttpServletResponse response;

        public MyTask(HttpServletRequest request, HttpServletResponse response) {
            super();
            this.request = request;
            this.response = response;
        }

        @Override
        public void run() {
            AsyncContext asyncCtx = request.getAsyncContext();
            try {
                // do the job
                PrintWriter out = response.getWriter();
                out.printf("<h2>Hello from %s</h2>", this);
                out.flush();
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                asyncCtx.complete();
            }
        }
    }
}

Asynchroniczne przetwarzanie w Servlet 3.0

Poniższy servlet kończy się wyjątkiem - java.lang.IllegalStateException - na linii 18, w której dostaję się do javax.servlet.AsyncContext. Dlaczego?

package pl.japila;

import java.io.IOException;

import javax.servlet.AsyncContext;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

@WebServlet(urlPatterns = "/AsyncServlet", asyncSupported = true)
public class AsyncServlet extends HttpServlet {
    private static final long serialVersionUID = 1L;

    protected void doGet(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
        AsyncContext asyncCtx = request.getAsyncContext();
        response.getWriter().printf("<h2>AsyncContext: %s</h2>", asyncCtx);
    }

}

Niech to będzie początkiem mojego eksperymentu naukowego, którego obiektem jesteś...Ty! :-)

IBM WebSphere Application Server V8: Developing RESTful Web Services (JAX-RS)

To zawsze było moje prywatne postanowienie, aby usiąść nad tematem nagrywania skrinkastów i ze zmianą grupy na IBM Worldwide WebSphere Competitive Migration Team, nagrania stały się całkiem wartościowym narzędziem reklamy, a wręcz mój szef dopytuje się o nie (!)

Tym samym znalazłem trochę czasu, aby się zebrać i opublikować kolejny odcinek z serii "Jak to się robi w Java EE 6, IBM WebSphere Application Server 8 i IBM Rational Application Developer 8".

W "IBM WebSphere Application Server V8: Developing RESTful Web Services (JAX-RS)" poznasz jak stworzyć usługę RESTową korzystając z JAX-RS i IBM Rational Application Developer V8. Aplikacja jest wdrażana na IBM WebSphere Application Server V8.

Mimo, że starałem się wykorzystać możliwie jak najwięcej uproszczeń WAS V8, to i tak przegapiłem możliwość skrócenia klasy ConferenceApplication jak opisano w Configuring JAX-RS applications using JAX-RS 1.1 methods. Można spodziewać się kolejnego nagrania już niebawem.

Chętnie dopasuję nagrania do Twoich uwag. Daj mi tylko je poznać, aby kolejne odcinki były jeszcze lepsze i bardziej dopasowane do Twoich potrzeb. Pewnie jest też obszar w Java EE 6, który chciałbyś poznać przez skrinkasty. Jaki?

Wrażenia pokonferencyjne - o Eclipse DemoCamp w Poznaniu

Jak ten czas szybko płynie! Wydaje się, że to wcale nie tak dawno, kiedy pisałem o konferencji JDD w Krakowie, a to już prawie 2 tygodnie mija i dopiero teraz przedstawiam wrażenia z kolejnej, ze mną w roli prelegenta. Potwierdza się stara, dobra zasada, że zadania trzeba robić, a nie o nich mówić i w przypadków moich relacji pokonferencyjnych niestety nie udało mi się jej zastosować. Nadrabiam.

Dobrego złe początki

Że też zawsze muszę sobie wybrać temat na wystąpienie, w którym doświadczenie zdecydowanie odbiega od standardów, których oczekuje się od prezentującego! W końcu zejdę na serce od tego stresu :)

Do Poznania przyjechałem około 17:30 i wydawało się, że była to odpowiednia chwila. Jeśli jednak dodać do tego właśnie rozpoczynające się targi poznańskie (nie wiem, czy to były te targi, czy inne z puli wielu targów w Poznaniu), to niestety było to złe założenie. Kiedy taksówka zajechała przez dworzec, a później ślimaczym tempem dowlokła się pod drzwi pubu na Szyperskiej, było już dawno po rozpoczęciu Eclipse DemoCamp 2011 w Poznaniu.

Zastałem już tłoczną salę słuchaczami, którym Tomek Zarna przedstawiał karierę Eclipse. Nie miałem okazji wysłuchać jego prezentacji, bo nie tylko, że trochę głośno, że jedynie na przodzie można było usłyszeć, co ma do powiedzenia, ale też sama sytuacja spotkania z organizatorami: Natalią Klimasz i Łukaszem Stachowiakiem, a później Adamem Dudczakiem, aby jeszcze później trafić na Darka "egit" Łukszę i...patrz, że też musiałem zapomnieć imienia!...nie pozwalała na wsłuchiwanie się. Zresztą, kto by tam słuchał, kiedy można pogadać z dawno niewidzianymi znajomymi?! Trafiłem również w międzyczasie na Dawida Weissa, ale to było chyba już po jego prezentacji. Wszystkich gorąco pozdrawiam!

"Przebijanie" się przez wrzawę powodowało tylko dalsze jej nakręcanie, więc o rozmowie nie było co marzyć. Za głośno. Jednak próbowaliśmy, co później odbiło się na moim gardle. Do domu zajechałem w stanie, jakbym był po niezłej bibce.

Przysłuchiwałem się prezentacji Dawida, ale wciąż w zasadzie myślałem o moim przygotowaniu tematu i przyglądałem się reakcjom uczestników na to, co ma do powiedzenia. W sali znajdowały się dwa monitory, na których można było zobaczyć slajdy, ale tylko jeden miał obok prezentera, więc było nie lada wyzwaniem zdecydować się, gdzie patrzeć, aby widzieć, albo słyszeć (monitory były różnej rozdzielczości i ich ułożenie sprawiało, że miało to znaczenie). Miałem wrażenie, że atmosfera jest lekko akademicka, tzn. za bardzo nastawiona na odbiór, bez choćby chęci zadawania pytań, co sama atmosfera ogólnego zgiełku dodatkowo "sprzyjała".

Pizza time. Już wspólnie ze Szczecinianami. Spałaszowaliśmy kilka kawałków, aby dalej dywagować na tematy różne. Prezentacje sobie, a my sobie.

Wchodzę na scenę

Przyszła pora na moje wystąpienie. Sądziłem, że EDC to rodzaj spotkania, w którym dużo kodu jest wielce pożądane. Z drugiej strony zastanawiałem się, na ile skuteczny jest przekaz z otwartym IDE i kodowaniem na żywo. Tym razem postawiłem na to drugie. Miało być dużo IBM Rational Application Developer V8 z Java EE 6 na IBM WebSphere Application Server V8. I to był mój błąd. Właśnie przez te monitory i ogólną wrzawę. Kompletnie nie spodziewałem się takiego miejsca i atmosfery, w której ja miałbym prezentować Java EE 6 tworząc aplikacje na żywo. Chciałem dobrze. To wszystko ich wina :)

Najbardziej obawiałem się mojego przygotowania z JAX-RS (z zanurzonym Apache Wink w WAS V8), ale ostatecznie i tak nie pokazałem tego. Dzisiaj bardzo tego żałuję, bo mogło uzupełnić przekaz.

Zaczęły się problemy z mikrofonem - a to za głośno, a to za daleko i tym samym cicho, a ja potrzebowałem wolnych rąk do kodowania. W końcu się dopasowaliśmy - doszedłem do porozumienia z mikrofonem i zabrałem się za demo.

Zacząłem od prostej aplikacji webowej z servletem określonym przez @WebServlet. Zero deskryptora i tylko @WebServlet. Później urlPatterns i @WebFilter. Dalej przyszła pora na demonstrację @Stateless bez jawnego interfejsu biznesowego w ramach WAR. Dalej chwila z CDI i tak przeszliśmy z @EJB do @Inject (ciekawym, ile osób rozróżnia zastosowanie obu?) Dotarłem bodajże do @WebService wygenerowanym z POJO w projekcie javowym i na tym się zakończyła moja batalia o zademonstrowanie produktów IBM wspierających Java EE 6.

Nawet się nie obejrzałem i wnet było już po godzinie.

Losowanie

Na zakończenie organizatorzy przeprowadzili losowanie. Pamiętam, że losowano książki, bo podczas ich rozlosowywania zdążyłem tylko powiedzieć do Darka, że nigdy, ale to nigdy nie udało mi się czegokolwiek wygrać i chyba musiałem mówić to z takim przekonaniem, że kiedy skończyłem, padło "Jacek Laskowski".

Wygrałem książkę!

Cóż za radocha. Miałem do wyboru jedną i padło na "97 Things Every Programmer Should Know". To było doskonałe zakończenie mojego wystąpienia i całego spotkania mimo, że, jak się później okazało, nie był to wcale koniec.

Nocne dyskusje i powrót

Po zakończeniu prezentacji, siedzieliśmy jeszcze dłuższą chwilę. Rozmawialiśmy o różnych rzeczach, aż padło magiczne: "Wychodzimy na miasto". Trafiliśmy na rynek, gdzie przesiedzieliśmy do...4 nad ranem! (mam nadzieję, że nie naciągam, bo już sam nie jestem pewien do której siedzieliśmy). Szczecin odjechał. I ja również zasypiając nad ranem. To na prawdę bolało szczególnie, że zakończyło się moim przespaniem porannego pociągu do Warszawy. W końcu jednak dotarłem do niej i EDC przeszło do historii jako bardzo udane przedsięwzięcie. Upewniło mnie o potrzebie częstszego udziału w nich i coś mi mówi, że nie powinienem odstępować od publicznych wystąpień. Chyba zaczęły mi ponownie sprawiać niesamowitą przyjemność.

Dziękuję Natalii i Łukaszowi za zaproszenie. Możliwość wyłożenia mojej niewiedzy szerszej publiczności była bezcenna :) Czuję się zobowiązany!

warsjawa i TomEE już jutro - Java EE 6 Web Profile z Apache TomEE o 16:15

Maksym to fajny gość. W poniedziałek stuknął mu tydzień i przeszedł pierwsze badanie kontrolne w szpitalu na Madalińskiego.

Jego poczucie humoru przerasta moje wyobrażenia i na propozycję uśmiechnięcia się do kamery zdecydował skwitować to...figą z makiem (!) No cóż, powiedzmy, że miałem zły dzień, a on dobrą zabawę (a może odwrotnie?! :))

W tę sobotę, 15 października jest warsjawa 2011, a na niej ja jako prelegent z tematem Java EE 6 Web Profile z Apache TomEE. Czym bliżej wystąpienia, tym więcej mam wątpliwości, co może zainteresować publikę. Przy takim natłoku certyfikowanych serwerów aplikacyjnych nie wystarczy jedynie pokazać, że działa, ale musi być w Apache TomEE to coś, co zachęci do jego dalszego poznania.

Możliwość użycia zestawu Java EE 6 Web Profile jest kusząca, ale tylko, jeśli idzie w parze z daleko posuniętą prostotą użycia. Podczas wystąpienia zaprezentuję działanie aplikacji demonstracyjnych dostarczanych w ramach NetBeans IDE 7.1 na TomEE.

Sprawdzimy również, jak to jest skonfigurować TomEE z bazą danych MySQL.

Ideą jest, aby zachęcić do dalszych, pewnie już samodzielnych prób z tym zestawem w zaciszu domowego kominka, a podczas wystąpienia będę miał godzinę, aby ten ogień rozpalić. Powinno być ciekawie.

Apache TomEE w NetBeans IDE 7.1 - 2:1 dla błędów

Nie trzeba wielkiego umysłu, żeby wiedzieć, że w życiu kilkudniowego dziecka wszystko, co robi, określane jest jako pierwsze. Pierwszy raz pojawił się grymas na twarzy, który przypominał uśmiech, pierwsza noc w domu (i nadzieja, że będzie ją przesypiał spokojnie z 3 przerwami na jedzenie - nota bene, mimo, że dzieciak mógłby spać całą noc, to i tak po 3h będzie wybudzany na jedzenie!), pierwsza kąpiel w domu, pierwsze coś jeszcze innego i tak lista rośnie. Jak na razie Maksym dostarcza nam całą masę wrażeń. Jest ich tyle, że przy nadchodzącej zimie żadne mrozy nie są nam straszne. Maksym śpi regularnie, je i nie wpływa specjalnie na domowników swoją obecnością, a mimo to wszyscy chodzą jak nakręceni, szczególnie podekscytowani. Cudo dzieciaczek.

W sobotę, a chyba już i w piątek, postanowiłem popróbować się z Apache TomEE i NetBeans IDE 7.1. Oba produkty wciąż w fazie aktywnego rozwoju, więc można spodziewać się kilku, może nawet kilkunastu czknięć. Tych zawirowań jest o tyle mniej w przypadku Apache TomEE, na ile pozwala certyfikacja Java EE 6 Web Profile. Dla zwrócenia uwagi napiszę, że pod względem zgodności z Java EE 6 nie ustępuje miejsca JBoss AS 7.0.1 (!), a to uważam za niemałe osiągnięcie.

NetBeans IDE wspiera Apache Tomcat jako środowisko uruchomieniowe dla Java EE 6, a więc i Apache TomEE - w końcu to wzbogacony Apache Tomcat. Przy odrobinie szczęścia można pozwolić sobie na zestawienie środowiska programistycznego z oboma produktami. I tak faktycznie jest.

Wystarczy postępować zgodnie z wytycznymi asystenta do konfiguracji Apache Tomcat z tą różnicą, że katalogi wskazują na Apache TomEE i wszystko gra! Szkoda tylko, że nie można zmienić nazwy serwera na wybraną przez użytkownika, np. Apache TomEE lub podobnie.

Nie wiem, co mnie podkusiło, ale postanowiłem spróbować się ze zmiennymi środowiskowymi (ang. environment entries) i ich dostępem z servletu. To chyba było z powodu tego zdania na stronie TomEE:

"Any Tomcat provided resources, say from a context.xml, can be looked up or injected."

Tak, na pewno to było to. Stworzenie servletu w NetBeans to chwila. W międzyczasie pytanie o rejestrację servletu w web.xml, na które odpowiedziałem stanowczym nie, tj. zatwierdziłem domyślne ustawienie "Add information to deployment descriptor (web.xml)". Od wersji Servlet 3.0 deskryptor web.xml jest opcjonalny, więc po co mi to?!

I tu się zaczęło.

Najpierw trafiłem na brak wsparcia przez TomEE dla aplikacji webowych bez deskryptora web.xml. Zgłosiłem błąd TOMEE-27 UnknownModuleTypeException thrown when no-web.xml webapp deployed. Nie dawało mi to jednak spokoju i w trakcie sobotniego przesiadywania przed kompem, poprawiłem go. Taa, sam jestem pod niemałym wrażeniem, że zebrałem się w sobie i zrobiłem to.

Z poprawką uruchomienie servletu z adnotacją @WebServlet i bez deskryptora web.xml stało się możliwe. Ciekawe, jak mogło się stać, że nie wyłapał tego zestaw certyfikacyjny Java EE 6 Web Profile TCK?!

Na tym jednak nie koniec, bo głównym celem było dostanie się do zmiennej z context.xml (plik konfiguracyjny Tomcata, a tym samym i TomEE). Tutaj niestety nie mam dobrych wieści, bo wciąż nie ma wsparcia dla niej i pracuję nad TOMEE-28 Support for global environment entries (defined as in server.xml). Tym samym wynik niekorzystny dla poprawek na rzecz 2 błędów. Na dzisiaj 2:1 w starciu błędy kontra poprawki.

Całkiem przy okazji, natrafiłem na możliwość edycji server.xml z poziomu NetBeans - menu kontekstowe Edit server.xml dla serwera.

Jak dla mnie całkiem użyteczna rzecz i przydała się już kilkakrotnie.

Czym jest Java EE 6 Web Profile?

Synuś Maksym jest już w domku i jeszcze nie wie, co oznacza "dać popalić" (oby tylko się w ogóle nie dowiedział o istnieniu czarnej strony mocy). W ogóle jakiś taki grzeczny - zdecydowanie za mało płacze. Żonka uśmiechnięta i cała w skowronkach, a starszaki - Iwetka i Patryś - rozkochane w braciszku. Sielanka, że nic tylko mieć kolejne dzieci.

Specyfikacja Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile jest niezwykle strawnym dokumentem pod względem wielkości - jedynie 20 stron. Warto się z nim zapoznać, bo jest, jak to się wyrażono na stronie 2:

"Being the first profile of the Java EE 6 Platform to be defined, we expect the Web Profile specification to be used as a model for future profiles."

Możnaby powiedzieć, że profil webowy (ang. web profile) jest swoistą referencyjną implementacją dla profili w Java EE 6. Na pewno jest to jedyny znany profil Java EE 6 na chwilę obecną i celuje w określenie standardu tworzenia nowoczesnych aplikacji webowych (ang. modern web applications). Można się z tym zgadzać lub nie, ale trudno zaprzeczyć, że jest to próba nadgonienia^H^H^Hkrok ku uproszczeniu życia programistom i administratorom, którym potrzebna była jedynie specyfikacja Java Servlet 3.0 z dodatkami, a byli zmuszani do "taszczenia" pełnego środowiska Java EE - Apache Geronimo, JBoss AS, GlassFish - lub jedynie korzystali z Apache Tomcat i tworzyli z niego właściwe środowisko (czy to przez wzbogacanie pojedynczej aplikacji webowej, czy też całego serwera). Zamiarem Java EE 6 było ukrócenie tego "procederu" i wyjście na przeciw takim potrzebom. Życie zweryfikuje sensowność takiego działania.

W głównej specyfikacji Java EE 6 - Java™ Platform, Enterprise Edition (Java EE) Specification, v6 (rozdział EE.9, strona 201) możemy przeczytać na temat profili Java EE 6. Jest to jedynie wprowadzenie do mechanizmu ich definiowania i specyfiki działania, a szczegóły pozostawia się dedykowanym dokumentom, np. wspomnianemu Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification.

Profil Java EE jest zestawem (podzbiorem właściwym) specyfikacji Java EE, który spełnia wymagania danej klasy aplikacji (ale mi tutaj pachnie algebrą zbiorów i tylko czekać na przecięcia, pokrycia, algebry ilorazowe i temu podobne :]). W ten sposób można odchudzić środowisko uruchomieniowe - serwer aplikacyjny - tak, aby spełniał jedynie wybrane specyfikacje, np. certyfikacja JBoss Application Server 7.0 nie dotyczy pełnego wydania Java EE 6, a wyłącznie omawianego profilu webowego (patrz sekcja Strict Compliance na stronie JBoss AS 7).

W skład profilu webowego wchodzą następujące specyfikacje:

• Java Servlet 3.0
• JavaServer Pages (JSP) 2.2
• Expression Language (EL) 2.2
• Debugging Support for Other Languages (JSR-45) 1.0
• Standard Tag Library for JavaServer Pages (JSTL) 1.2
• JavaServer Faces (JSF) 2.0
• Common Annotations for theJava Platform (JSR-250) 1.1
• Enterprise JavaBeans (EJB) 3.1 Lite
• Java Transaction API (JTA) 1.1
• Java Persistence API (JPA) 2.0
• Bean Validation 1.0
• Managed Beans 1.0
• Interceptors 1.1
• Contexts and Dependency Injection for the Java EE Platform 1.0
• Dependency Injection for Java 1.0

Oczywiście produkt wspierający dany profil może udostępniać znacznie szersze spektrum specyfikacji niż tylko te wymagane.

Na uwagę zasługuje fakt zawarcia EJB 3.1 w profilu, ale jedynie w jego wersji uproszczonej, zwanej EJB Lite (do omówienia w kolejnych wpisach).

Jedynym formatem aplikacji, które są wspierane przez środowiska wspierające profil webowy, jest moduł aplikacji webowej (WAR).

Poza wymaganiami opisanymi w dokumencie standaryzującym profil mamy jeszcze wymagania opisane w specyfikacji Java EE 6 - Java™ Platform, Enterprise Edition (Java EE) Specification, v6, które muszą zostać spełnione przez wszystkie profile Java EE 6 (patrz rozdział EE.9.5 Requirements for All Java EE Profiles, strona 203):

• wsparcie dla adnotacji @Resource, @Resources, @PostConstruct oraz @PreDestroy
• dostępny kontekst JNDI “java:” (jak opisano w sekcji EE.5.2, "JNDI Naming Context")
• dostępność Java Transaction API (JTA)

Mam wrażenie, że nawet jeśli sama idea profilu nie przypadnie wielu osobom do gustu, bo to wciąż za ciężki zestaw, to wiele zespołów zdobędzie się na zastąpienie poczciwego Tomcata, Resina czy Jetty na jego wzbogacony odpowiednik realizujący Java EE 6 Web Profile. Wciąż będzie to produkt, który przechodzi wymogi specyfikacji Java EE 6 (tutaj ukłon w stronę sponsorów, którzy potrzebują tego typu glejtów), a jednocześnie skurczony do właściwych rozmiarów z kilkoma dodatkowymi specyfikacjami, które nie były dostępne z pudełka w popularnych kontenerach webowych (co powinno spodobać się programistom, bez zawirowań na styku z adminami).

Mam wrażenie, że z nadejściem profilu webowego w Java EE 6 zaprzestano promować ideę, że rozpoczynanie transakcji czy dostęp do bazy danych z poziomu aplikacji webowej jest nieodpowiednie - istnienie JPA 2.0 oraz JTA 1.1 przeczą temu.

A co Ty sądzisz o nowej specyfikacji Java EE 6 i jak to ktoś powiedział (nie mogę teraz znaleźć odnośnika do tego) "programowania adnotacjami"? Kiedyś był wszechobecny XML i jego wady i zalety znamy. Teraz są adnotacje i jest podobnie - są wady i zalety. Czy zalety Java EE 6 przesłaniają jego wady?

p.s. Java EE 6 to ona czy on, abym pisząc "jego wady" odnosił się do właściwej płci? :)

Java EE 6 Web Profile z Apache TomEE na warsjawie 2011

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.