Blog użytkownika Łukasz Lenart

Smażenie confitury

Łukasz Lenart — Wed, 03 Apr 2013 09:24:23 +0000

Powoli zbliża się kolejna edycja konferencji Confitura - część z Was możecie jeszcze kojarzyć jej poprzedniczkę - Javarsovię. Jednak nowa nazwa konferencji już mocno wgryzła się w świadomość społeczności okołojavowej i nie tylko.

Konferencja ciągle ewoluuje, zmienia się zakres tematyczny wystąpień, pojawiają się miękkie tematy związane z zarządzaniem projektami, budowaniem zespołów czy też kultury pracy. Oczywiście tematy ściśle techniczne mają swoje miejsce i każdy znajdzie coś co go zainteresuje.

Bardzo często wielość tematów jest tak duża, że dochodzą do nas żale ludzi, którzy nie mogli wybrać się na wszystkie interesujące wykłady i postulują o zredukowanie liczby ścieżek do dwóch, trzech, jednej - tak abym "pasowało tylko mnie" ;-)

Taki dylemat z liczbą ścieżek mamy co roku, zawsze mamy bardzo dużo zgłoszeń na C4P, do tego dochodzą wystąpienia Partnerów, a każdym z uczestników kierują inne potrzeby. Nie ma szans aby zaspokoić życzenia i oczekiwania wszystkich :-)

Tegoroczna edycja odbędzie się ponownie w gmachu Uniwersytetu Warszawskiego w centrum Warszawy. Wszystkie sale są wyremontowane i wyposażone w klimatyzację, do tego dysponujemy jeszcze jedną salą w budynku Starej Biblioteki.

W tym roku planujemy całą jedną ścieżkę w języku angielskim, oznacza to tyle, że zgłaszając swoją propozycję wystąpienia możesz wybrać w jakim języku będziesz prezentował. Jest to ukłon w stronę części prelegentów, którzy chcą szlifować swoją formę również w aspekcie języka jak również jest to otwarcie się na przyjezdnych uczestników z zagranicy.

Zobaczymy co z tego wyjdzie :-)

I tak już na zakończenie, zachęcam wszystkich do zgłaszania się z propozycjami wystąpienia podczas konferencji, trwa ciągle Call 4 Papers i jest to najlepsza sposobność aby zaistnieć w społeczności, sprzedać się jako znawca tematu lub po prostu podzielić się swoją wiedzą i przemyśleniami na wybrany problem!

etykiety:

confitura

Hibernate i dobre rady

Łukasz Lenart — Wed, 10 Oct 2012 10:22:14 +0000

Hibernate jest przez wielu traktowany jako podstawowy element składowy każdego projektu - tak jak Spring ;-) I w sumie racja, bardzo szybko na początku otrzymujemy funkcjonalność zapisu danych w bazie danych, nasze obiekty bez większego wysiłku same się aktualizują, zapisują, etc.

Problemy zaczynają się pojawiać, gdy nasz aplikacja się rozrasta i przybywa zależności między obiektami, graf domeny przypomina bardziej las a nie pojedyncze drzewo a do tego wszystkiego dokładamy jeszcze Enversa aby monitorować co i kto miesza nam w bazie.

Powyższe to najprostszy przepis na niezły bajzel :P

Podam kilka dobrych rad, które możesz wykorzystać i może pomogą ci uniknąć problemów z jakimi borykamy się w naszym projekcie po trzech latach pisania i dodawania ficzerów.

Po pierwsze:
Jeśli piszesz testy integracyjne, czyli takie które zapisują coś do bazy a następnie odczytują, to potrzebne dane testowe twórz z poziomu kodu. Nie korzystaj z jakiś zewnętrznych plików, nawet nie wiem o jak prostej składni to i tak ci nie pomoże gdy przyjdzie zrobić refactoring albo dodać jedno pole - pomyśl o tych wszystkich zewnętrznych plikach, do których będziesz musiał dodać wartości dla tego pola. Kompilator tego nie wykryje, dopiero odpalenie wszystkich testów pozwala wykryć brakujące dane (miejmy nadzieję że tak jest ;-)
Po drugie:
Jeśli wybrałeś strategię generowania kluczy dla encji to upewnij się że rozumiesz jak ona działa i że wszyscy w zespole wiedzą jakie wartości będą generowane dla kluczy. I przetestuj czy faktycznie działa tak jak myślisz. Ma to o tyle znaczenie, że jeśli odkryjesz po czasie, że jednak strategia działa inaczej niż myślałeś a już jesteś na "produkcji" to migracja danych może nie być możliwa.
Po trzecie:
Hibernate i Envers zawiera błędy jak każdy inny kod. I jeśli nawet używany jest przez tysiące projektów to może się okazać, że Twoja konfiguracja jest na tyle specyficzna, że źródłem problemów i błędów jest właśnie Hibernate czy też Envers. Przykładem niech będzie błąd w Enversie, który generuje rewizyjne dane pomimo, że transakcja została wycofana a druga transakcja przeszła poprawnie - więcej szczegółów wkrótce u Tomka Dziurko na blogu.
Po czwarte:
Lazy jest fajne ale musisz rozumieć kiedy i jak działa. Co powoduje, że nastąpi select do bazy danych i pociągnięty zostanie graf obiektów. Przykład dość prosty: jeśli masz hashCode() który bazuje na propertisach, które są lazy to w momencie wstawiania takiego obiektu do HashMapy jako klucza, nastąpi wywołanie zapytania do bazy danych - przecież musi być obliczony hashCode()!
Rozwiązanie problemu jest dość proste, użyj dwóch map. W jednej trzymasz relację id => encja1 a w drugiej id_encja1 => encja2. Mało eleganckie ale rozwiązuje problem ładowania obiektu przy wstawianiu go jako klucz.
Po piąte:
Hibernate definiuje dwie opcje persystowania propertisów - wg pól lub wg getter/setter i zależy to gdzie jest umiejscowiona adnotacja @Id - jeśli na polu to mamy field access, jeśli przy getter/setter to mam property access - szczegóły w dokumentacji. Dlaczego o tym mówię ? Bo jeśli potrzebujemy wyciągnąć tylko klucz obiektu, który jest lazy to ma to znaczenie. Dla przykładu: encja1.getEncja2().getId() - i w zależności czy mam field access czy property access to wywołanie getId() pociągnie cały obiekt z bazy lub tylko odczyta wartość klucza z encja1 (toż encja1 zawiera już klucz encja2 ;-)

To chyba na razie tyle, jak jeszcze wejdę na jakąś minę i przeżyję to dam znać :D

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

architektura

Testowanie z transakcjami w tle

Łukasz Lenart — Fri, 21 Sep 2012 14:11:14 +0000

Spora część aplikacji, które piszemy wykorzystuje relacyjne bazy danych. Pewnie można by założyć, że większość aplikacji, które mają coś wspólnego z bazami danych, korzysta z baz relacyjnych. Bazy NoSQL są wciąż w mniejszym stopniu w powszechnym użyciu.
Oczywiście testowanie w aplikacji składających się z wielu warstw jest obecnie dość proste. Wstawia się mocka zamiast rzeczywistej implementacji i gotowe, można testować. Jednak czasami mamy potrzebę sprawdzić trochę więcej niż jedną klasę, potrzebujemy napisać test integracyjny, które przejdzie przez kilka warstw, dotknie bazy danych, zahaczy o transakcje i oczywiście będzie odpalany z IDE ;-)

Jeśli jeszcze do tego dodamy DI w postaci CDI oparte o Welda, JPA 2.0 na bazie Hibernate'a to zaczyna robić się ciekawie. I strasznie zarazem - mało kto wie co się dzieje :P W SoftwareMill korzystamy z własnej biblioteki softwaremill-common, która dostarcza różne ciekawe moduły do pracy z CDI, JPA, JSF, etc. Kod jest dostępny na GitHubie i jako repozytorium Mavena z Nexusa.

Wśród wielu modułów jest również klasa AbstractDBTest służąca do pisania testów, które potrzebują prawdziwej bazy danych a nie mocka. W założeniu miała ona wspierać transakcje, bazując na konfiguracji, która została użyta przy testowaniu Enversa i paczki Hibernate-Testing - znajdziecie wiele przykładów.

Niestety, wszystkie one nie działają ;-)

Nie działają z transakcjami, bo do bazy zapisują i odczytują, ale nie w ramach transakcji, którą można sterować.

Tak się złożyło, że w projekcie dla jednego z naszych klientów musieliśmy przetestować czy działa rollback na transakcji, a konkretnie czy wykonane wcześnie zmiany w bazie w wyniku rzucenia Exception zostaną wycofane z bazy - czyli klasyczne begin/commit/rollback.

Niestety nie było to możliwe z AbstarctDBTest, jak również Weld i Embedded Container psują tu wszystko - pierwsza za sprawą wspomnianego pakietu Hibernate Testing, a drugi w związku z pustą implementacją UserTransaction, która nic nie robi.

Jedynym słusznym rozwiązaniem było napisanie wszystkiego jak trzeba, czyli tak aby działało z prawdziwymi transakcjami - pewnie ktoś powie, że takie rozwiązanie już jest, a ja odpowiem, że moje jest lepsze :P

Rozwiązaniem problemu jest klasa TransactionDBTest, która wykorzystuje bibliotekę Bitronix jako Transaction Managera. Bitronix jest bardzo fajnym rozwiązaniem, gdyż pozwala na uruchomienie serwera JNDI i wstawienia naszego DataSource tak aby Hibernate mógł z niego skorzystać.

Nie będę podawał przykładu jak użyć tej klasy, wystarczy przyglądnąć się testowi TestTransactionDBTest.

Klasa wykorzystuje Arquilliana i bazuje na magicznym D.inject().

Miłego testowania i uwagi mile widziane w postaci push requestów na GitHubie :-)

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

szkielety

testy

testy jednostkowe

... i po konfiturze

Łukasz Lenart — Wed, 04 Jul 2012 10:12:47 +0000

Tak właśnie, minęło już kilka dni od zakończenia drugiej edycji konferencji Confitura, a w sumie szóstej licząc cztery poprzednie edycje pod marką Javarsovia. Pasuje podsumować całość, zwłaszcza jak było się członkiem kapituły - choć lepszym mianem dla mnie było by "księgowy" ;-)
Jest to kolejny rok, gdzie konferencja rośnie, może już nie tak skokowo jak jakiś czas temu ale bardziej organicznie - szacunkowo było ~850 uczestników w porównaniu do poprzedniego roku, kiedy to zjawiło się ~800 osób.

Jeszcze kilkanaście tygodni temu nie wiedzieliśmy co nam się uda zorganizować, czy będzie catering z lunchem, czy tylko kawa i ciasteczka. Czy będzie SPOINa czyli impreza integracyjna po konferencji czy tylko wyskoczymy na piwko. Czy będą koszulki dla uczestników. Więcej było niewiadomych niż byśmy sobie tego życzyli.

Zawsze chcemy zapewnić jak najwięcej atrakcji ale jest to trudne nie dysponując gotówką na ich pokrycie. Konferencja jest całkowicie bezpłatna dla uczestników, jedynym kosztem w tym roku to była zgoda na mailing od naszych Partnerów, gdzie maksymalnie będzie to sześć wiadomości wysłanych w ciągu najbliższych sześciu miesięcy. Chyba żaden koszt jak za całodzienną konferencję wraz z wyżywieniem. Jednak mimo tego część uczestników nie chciała nas wesprzeć i nie zgodziła się na mailing - szkoda, za rok konferencja może przez to być skromniejsza.

I tu dochodzimy do clue sprawy - konferencja nie zrobi się sama, ktoś ją organizuje, ktoś wykłada pieniądze, ktoś przychodzi w wolną sobotę i dokłada cegiełkę do całości. Stąd naszych sponsorów nazywamy Partnerami a nie Sponsorami, bo ich wkład jest ważny i nie chodzi tylko o pieniądze. Stąd nasza prośba o zgodę na mailing, bo dzięki temu wy również stajecie się partnerami dla naszych Partnerów. To jest transakcja wiązana - oni Wam atrakcje, a wy wysłuchanie ich głosu. Naprawdę niewiele.

Dobra, dość tego marudzenia, chyba rozumiecie, że nie działamy na Waszą szkodę.

Myślę, że wszyscy są bardzo zadowoleni z udziału w konferencji, i Partnerzy, i uczestnicy. Każda ze stron wyniosła to co chciała z konferencji. Ilość atrakcji jakie były dostępne samych nas wprowadziła w zdumienie i gdyby niezbyt szeroki korytarz wszystko wyglądało by super. Choć w sumie wystarczyło przesunąć jedno stoisko w inne miejsce aby rozłożyć atrakcje równomiernie a tym samym zagęszczenie uczestników ;-)

Osoby, które były na konferencji wiedzą, że już za rok odbędzie się Confitura'13 i mamy nadzieje, że w tym samym miejscu. Oczywiście, że Uniwersytet Warszawski - nasz gospodarz, a dokładnie Audytorium Maximum ma swoje minusy - wąski korytarz - ale ma też plusy, które trudno nie doceniać - lokalizację w centrum miasta, możliwość rozstawienia namiotów (jeszcze tydzień przed konferencją nie było żadnych wykopków ;-)) no i cena :-)

Na koniec chciałbym podziękować jeszcze raz naszym Partnerom, bo niestety nie da się zrobić konferencji tej skali bez pieniędzy:
Platynowy: Javart
Złotym: Akamai, Oracle, e-point, Allegro Group, Atlassian
Srebrnym: Google, Decerto, NASK, SMT Software, Outbox, pracuj.pl
Brązowym: TouK, Xentivo, SAGES, Code Sprinters
Technicznym: SoftwareMill, OVH, ej-technologies, O'Relily, Helion, 3D TV, NZS PW

W tym roku zaliczyliśmy dość poważną wpadkę, jak zawsze na koniec konferencji zapraszaliśmy naszych Wolontariuszy na zakończenie, abyście mogli poznać z twarzy osoby, bez których obsłużenie takiego tłumu nie było by możliwe. Jest mi przykro z tego powodu i jedyne co mogę obiecać, to że uczymy się na błędach i w przyszłym roku powrócimy do tej chlubnej tradycji.

I jeszcze na koniec, wszyscy marudzący na temperaturę, powinni być wdzięczni, że konferencja odbyła się w minioną sobotę, na tą najbliższą prognozowane jest od 32 do 35 stopni, dopiero byłby ukrop ;-)

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

wydarzenia

@ViewScoped czy nie @ViewScoped

Łukasz Lenart — Fri, 15 Jun 2012 10:54:52 +0000

Dzisiaj bardzo ważny wpis dla wszystkich używających JSF 2.0 i adnotacji @ViewScoped. Oczywiście dla niektórych może to być oczywista oczywistość to co przeczytają, ale mi zajęło trochę czasu zrozumienie całości problemu i dojście do poniższych wniosków.

Dobra, spytacie o co chodzi z @ViewScoped ?

Tej adnotacji używa się na klasie kontrolera strony JSF jeśli używamy go w połączeniu z <f:ajax/>, sprawa prosta i oczywista. Jednak dość często nasz kontroler ma dodatkowe adnotacje na poziomie klasy. Może to być @ManagedBean lub @Named czy też inne adnotacje CDI. Dla jasności @ManagedBean jest adnotacją JSFową a nie CDI.

I właśnie tu jest mały problem. Jeśli na poziomie klasy kontrolera mieszamy adnotacje z dwóch światów - JSF i CDI - to skutki mogą być opłakane a co najmniej nieprzewidywalne ;-)

Pewnie zastanawiacie się dlaczego ? Ano sprawa jest prosta, JSF tworzy swoją instancję kontrolera a CDI swoją i która gdzie będzie wstrzykiwana to może być niezła zagwozdka do rozsupłania.

Pewnie teraz powiecie, no ale @ViewScoped jest tylko w JSFie, w CDI nie ma odpowiednika (wg specyfikacji) i będziecie mieć rację. Jednak w takim przypadku należy wystrzegać jest adnotacji z CDI i użyć poczciwego @ManagedBean znanego z czasów JSF 1.0, czyli:

@ManagedBean(name = "myPage")
@ViewScoped
public class MyPageBean {
 
}

i gra gitara.

Jednak mała uwaga. Seam 3 dostarcza moduł Seam Faces a wraz z nim jest dostarczana implementacja @ViewScoped bazująca na CDI. Jeśli niechcący użyjecie sobie tego modułu w waszej aplikacji, to znów mamy pomieszane dwa światy :P

Tak więc, w przypadku używania modułu Seam Faces wyrzucamy @ManagedBean i używamy @Named, aby było jasne że nasz kontroler jest kontrolowany przez CDI czyli:

@Named("myPage")
@ViewScoped
public class MyPageBean {
 
}

Jeszcze jedna mała uwaga do @ViewScoped. Oznaczone nim klasy będą odkładane w sesji, ale tylko na czas, gdy użytkownik przebywa na danym widoku. Jeśli opuści stronę @ViewScoped, instancja zostanie usnięta z sesji i zniszczona.

Powoduje to jednak pewien problem, klasa musi być Serializable jak i wszystkie jej pola, no chyba że mają inne scope to wtedy zależy. Jest to głównie problem z serwisami ale wtedy można użyć adnotacji @Singleton na nich i nie martwić się takimi problemami. O ile są bezstanowe ;-)

I jeszcze jedna uwaga. Jeśli użyjemy wersji CDI @ViewScoped (czyli mamy moduł Seam Faces w zależnościach) to wtedy Weld (referencyjna implementacja CDI) wykonuje walidację czy wszystkie zależności klasy i sama klasa są serializowalne jeśli jest @ViewScoped. W przypadku używania @ManagedBean nie ma takiej walidacji i spokojnie możemy pakować do sesji obiekty, które nie są serializowalne ;-)

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

java

szkielety

JSF 2.0 a parametry żądania GET

Łukasz Lenart — Mon, 09 Apr 2012 11:36:10 +0000

Możecie wierzyć lub nie, ale spece od JSFa odkryli, że świat webowy to nie tylko postback i w JSF 2.0 wprowadzili w miarę poprawną obsługę parametrów żądania GET. Co to znaczy? Znaczy tyle, że mając żądanie o postaci:

/mypage.jsf?id=1&client=internal

możemy coś z tym zrobić :D

Może wydawać się dziwne, ale z tego co ja rozumiem, to do tej pory, obsługa żądań GET nie była możliwa, znaczy może i była możliwa, ale polegała bardziej na sztuczkach niż na wsparciu samego szkieletu JSF. Tak to czasami bywa, gdy jedyny punktu widzenia jaki mamy to nasz własny i stąd wychodzi pasztet :P

Wróćmy jednak do JSF 2.0 i obsługi żądań GET z parametrami. Aby obsłużyć powyższe żądanie po stronie JSF 2.0 musimy zmodyfikować stronę mypage.xhtml i uzupełnić ją o odpowiednie metadata, tak jak poniżej:

<f:metadata>
    <f:viewParam name="id" value="#{myPage.clientId}" required="true"
                     requiredMessage="Proszę użyć linku ‘Edit’"/>
    <f:viewParam name="client" value="#{myPage.clientType}"/>
    <f:event type="preRenderView" listener="#{myPage.initClient"/>
</f:metadata>

Trochę wyjaśnień:

<f:viewParam/> pozwala na zdefiniowanie jakie parametry żądania GET są wymagane, aby otworzyć daną stronę
<f:event/> pozwala określić jaka metoda mam być wywołana po ustawieniu parametrów i w jakiej fazie - w 99% przypadków, będzie to preRenderView

W zbliżającym się wydaniu JSF 2.2 dodano bardziej sensowny tag <f:viewAction action="#{myPage.initClient}" />, ale to jeszcze przyszłość ;-)

Kilka dodatkowych uwag do powyższego kodu. Powyższa metoda #{myPage.initClient} zostania wywałana dla każdego żądania, również AJAX, przy czym dla żądania AJAX dwa razy (tak, zgadza się - 2x). Niestety nie jest to żaden feature tylko błąd ;-) Aby go rozwiązać trzeba przesunać <f:event/> poza sekcję <f:metadata/>, jak poniżej:

<f:metadata>
    <f:viewParam name="id" value="#{myPage.clientId}"
                     requiredMessage="Proszę użyć linku ‘Edit’"/>
    <f:viewParam name="client" value="#{myPage.clientType}"/>
</f:metadata>
<f:event type="preRenderView" listener="#{myPage.initClient"/>

Kolejne uwagi, sekcji <f:metadata/> nie można umieścić gdzie się chce, musi to być zaraz pod elementem <f:view/> w innym przypadku dziwne rzeczy mogą się dziać ;-)
Jeśli stosujemy szablony, to należy utworzyć odpowiedni punkt wstrzykiwania sekcji metadata, jak poniżej, w przykładowym szablonie default.xhtml:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
 
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:ui="http://java.sun.com/jsf/facelets"
      xmlns:f="http://java.sun.com/jsf/core">
<f:view>
<ui:insert name="metadata"/>
<h:head>
    <!-- css, js, etc … -->
</h:head>
<h:body>
    <ui:insert name="content"/>
</h:body>
</f:view>
</html>

W powyższym przykładzie są dwie sekcje: metadata i content, które możemy odpowiednio wypełnić już w docelowych plikach .xhtml, jak dla przykładu w mypage.xhtml poniżej:

<?xml version="1.0" encoding="UTF-8"?>
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
                xmlns:ui="http://java.sun.com/jsf/facelets"
                xmlns:f="http://java.sun.com/jsf/core"
                xmlns:h="http://java.sun.com/jsf/html"
                xmlns:a4j="http://richfaces.org/a4j"
                template="WEB-INF/templates/default.xhtml">
<ui:define name="metadata">
<f:metadata>
    <f:viewParam name="id" value="#{myPage.clientId}" required="true"
                     requiredMessage="Proszę użyć linku ‘Edit’"/>
    <f:viewParam name="client" value="#{myPage.clientType}"/>
</f:metadata>
<f:event type="preRenderView" listener="#{myPage.initClient"/>
</ui:define>
<ui:define name="content">
  <h1>Moja super strona</h1>
</ui:define>
</ui:composition>

I tada, gotowe :-)

Prawie ;-) Jak pisałem wcześniej, metoda #{myPage.initClient} zostanie wywołana dla każdego żądania AJAX, niestety ze względu na kolejny błąd w JSF, ilość żądań będzie wynosiła n + 1, gdzie n to liczba żądań AJAX jakie do tej pory zostały wykonane do strony :P
Oczywiście dotyczy to stron @ViewScoped. Aby obejść problem, to musimy pomijać żądania AJAX w metodzie #{myPage.initClient}, jak to robię poniżej:

@Named("myPage")
@ViewScoped
public class MyPageBean implements Serializable {
    @Inject
    private FacesContext ctx;
 
    private Long clientId;
    private ClientType clientType;
 
    public void initClient() {
        // pomijamy AJAX
        if (ctx.getPartialViewContext().isAjaxRequest()) {
            return;
        }
        loadClientFromDB();
    }
 
// getters, setters
 
}

Ktoś może spytać po co tyle kombinacji ? Sam się zastanawiam, ale jeśli chce się mieć poprawną obsługę parametrów żądania, to nie ma innej drogi. Znaczy można w setterze do np. clientId dodać logikę, ale szybko się przekonamy jakie to jest niebezpieczne. Po drugie w takim przypadku musimy ręcznie wyciągać parametry z FacesContext, gdyż parametry mogą być ustawiane w nieprzewidywalnej kolejności.

Jeszcze jedna uwaga, jeśli np. umieścimy sekcję gdzieś głębiej w hierarchi drzewa JSF, albo zapomnimy o <f:view/> czy coś jeszcze głupszego, to może się okazać, że nasza metoda i cały bean są tworzone jeśli jesteśmy na innej stronie, ale mamy na niej zdefiniowany link do myPage ;-)

Tak więc, jedynie słuszny sposób jak narazie to ten zaprezentowany powyżej.

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

java

szkielety

projektowanie

JSF 2.0 i Ajax a redirect

Łukasz Lenart — Tue, 13 Mar 2012 12:06:25 +0000

To kolejny z mini postów o moich doświadczeniach w pracy z JSFem 2.0, czyli bitwa trwa dalej :-)
Sprawa jest dość prosta, nie raz zdarza nam się, że w pracy z aplikacją webową, potrzebujemy wykonać przekierowanie (aka redirect) to innej strony. W przypadku zwykłego żądania przychodzącego ze strony JSF nie jest to problem. Robimy proste:
FacesContext.getCurrentInstance().getExternalContext().redirect("/page.jsf");

Niestety, takie rozwiązanie nie zadziała dla wywołań ajaxowych, bo w sumie co miałbym z tym zrobić klient JavaScript? Oczekuje odpowiedzi w formacie:

<?xml version="1.0" encoding="UTF-8"?>
<partial-response>
    .....
</partial-response>

Rozwiązanie jest dość prost choć brak dla niego oficjalnej dokumentacji ;-)

Pierwszym krokiem jest sprawdzenie czy mamy do czynienia ze zwykłym żądaniem czy też jest to żądanie przychodzące z <f:ajax/>. Aby to wykryć musimy sprawdzić czy jest odpowiedni nagłówek HTTP:

private boolean isAjaxRequest(HttpServletRequest request) {
    return "partial/ajax".equalsIgnoreCase(request.getHeader("Faces-Request"));
}

Skąd dostać HttpServletRequest będąc w środku JSFa ?

HttpServletRequest request = (HttpServletRequest) FacesContext.getCurrentInstance()
    .getExternalContext().getRequest();

Jeśli już wiemy, że mamy do czynienia z Ajaxem to pozostaje tylko odesłać odpowiednio przygotowany partial, do tego posłuże się poniższą metodą:

private void sendAjaxRedirect(HttpServletRequest request, HttpServletResponse response, String url) 
    throws IOException 
{
    String url = MessageFormat.format("{0}://{1}:{2,number,####0}{3}" + url,
            request.getScheme(),
            request.getServerName(),
            request.getServerPort(),
            request.getContextPath());
 
    PrintWriter pw = response.getWriter();
    pw.println("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
    pw.println("<partial-response><redirect url=\"" + url + "\"></redirect></partial-response>");
    pw.flush();
}

I gotowe! Wyżej wymienionych przykładów można użyć np. w ViewHandler lub w ExceptionHandler, a można też wydzielić do osobnej klasy i wstrzykiwać je sobie tam gdzie potrzebujemy (CDI rulez :-) ).

Jedna drobna uwaga, w wielu komponentach JSFa mamy dostęp do instancji FacesContext i nie musimy wykonywać tego brzydkiego wywołania FacesContext.getCurrentInstance(). Jeśli nie mamy a jest to bean CDI (czyli CDI nim zarządza, co niestety nie zawsze jest prawdą dla składowych JSFa ;-) to możemy wstrzyknąć sobie ów context:

@Inject
private FacesContext context;

Można również użyć biblioteki softwaremill-common i magicznego D.inject() ale to może opisze przy innej okazji.

Pozdrawiam
--
Łukasz
www.lenart.org.pl

etykiety:

JSF 2.0 i Ajax

Łukasz Lenart — Wed, 29 Feb 2012 08:18:18 +0000

Dość tych żalów, przjedźmy do mojego problemu. Poniżej prezentuje drobny wycinek strony XHTML, zawierający dwa formularze oraz mechanizm odświeżania wyników za pomocą <f:ajax/>

<h:form id="form1">
 
    <h:panelGroup id="searchPanel" layout="block">
        <h:outputLabel for="searchValue">Search value:</h:outputLabel>
        <h:inputText id="filterValue" value="#{bean.searchValue}" />
        <h:commandButton value="Search" action="#{bean.search}" id="doSearch">
            <f:ajax execute="form1" render="results :form2"/>
         </h:commandButton>
    </h:panelGroup>
 
    <h:dataTable id="results" value="#{bean.results}" var="result">
        <h:column>
            <f:facet name="header">Value</f:facet>
             <h:outputText value="#{result}"/>
        </h:column>
    </h:dataTable>
 
</h:form>
 
<h:form id="form2" rendered="#{not empty bean.results}">
    <h:commandLink action="#{bean.createPrint}">
        <h:graphicImage value="images/print.png""/>
    </h:commandLink>
</h:form>

Krótkie wyjaśnienie dla powyższego kodu, jak widać form1 zawiera jedno pole do wyszukiwania oraz przycisk Search. Po kliknięciu w przycisk, formularz form1 zostanie przesłany za pomocą Ajaxa do Managed Bean bean (atrybut execute wskazuje na form1). Następnie zwrócona odpowiedź zostanie użyta do wyrenderowania results i form2 (atrybut render zawiera dwa id: results i form2).

Drobne wyjaśnienie co do zapisu atrybutu render, jedno z id zawiera dwukropek na początku. Wynika to z tego, że form2 jest po zasięgiem form1, czyli w innym scopie i aby Ajax wiedział o tym podaje się właśnie : na początku id elementu. Oczywiście można było zapisać to też tak render=":form1:results :form2".

Niestety powyższy kod zawiera drobny błąd, jeśli spróbujecie go użyć i wynik wyszukiwania będzie pusty (#{empty results}) to formularz form2 będzie dalej pokazywany. Dlaczego ?

Wynika to z działania JSFa i Ajaxa (powinno być Ajaxa dżejesofowego, ale chyba jasne ;-) ), teoretycznie form2 zawiera atrybut rendered i jeśli był by to zwykły request, który przeładowuje stronę to wszystko działało by pięknie. W przypadku jednak Ajaxa, atrybut rendered nie jest brany pod uwagę na elemencie, który jest podany jako id. Dopiero elementy w nim zawarte podlegąją tej logice.

Wystarczy dodać jeden element więcej i problem rozwiąże się sam, czyli tak jak poniżej:

<h:panelGroup id="form2" layout="block">
    <h:form rendered="#{not empty bean.results}">
        <h:commandLink action="#{bean.createPrint}">
            <h:graphicImage value="images/print.png""/>
        </h:commandLink>
    </h:form>
</h:panelGroup>

Pozdrawiam
--
Łukasz www.lenart.org.pl

etykiety:

szkielety

A może tak JDO

Łukasz Lenart — Thu, 15 Dec 2011 10:01:00 +0000

Właśnie, ilekroć pada pytanie co zastosować do persystencji danych w aplikacji javowej w połączeniu z bazą relacyjną, z reguły odpowiedzią jest Hibernate, JPA, no może czasami (ale to bardzo rzadko), czyste JDBC ;-)
A jakiś czas temu, firma odpowiedzialna za powstanie Javy (dla młodzieży, nie chodzi o Oracle'a ;-), wymyśliła jak to powinno wyglądać i przygotowała JSR-12 - po numerku widać, że było to dawno temu ;-) Było to lata świetlne przed Hibernatem.

Tak właśnie powstał standard Java Data Objects, w skrócie JDO. Pozwalał on na mapowanie obiektów nie tylko do baz danych ale również do innych repozytoriów danych - LDAP, pliki Excel, NoSQL, etc. Głównym założeniem było oderwanie się od relacyjnych baz danych i to już w 2000 roku! Niestety, dziadek Sun nie był tak mocny aby przeforsować swoją ideę, bo było ona nie na rękę wielkim graczom rynku baz danych w tamtych czasach. I tak to dzisiaj odkrywamy koło po raz drugi za pomocą JPA ;-)

JDO zostało przekazane jakiś czas temu pod skrzydła ASF i jest rozwijane w ramach Apache DB. Jest kilka implementacji specyfikacji JDO ale najnowszą wspiera tylko DataNucleus. I tak na marginesie, JDO i DataNucleus jest używane w ramach Google AppEngine ;-)

Skąd moje zainteresowanie tematem ? Wracając z ostatniego Devoxxa jakoś tak mnie naszło, aby przypomnieć i poczytać sobie o tej technologii - właśnie w związku z AppEngine. A druga sposobność pojawiła się kilak dni temu, kiedy to Sebastian napisał na grupie PJUG, że ma problem z JDO.

Poniżej zaprezentuje kroki jakie wykonałem, aby otrzymać działający przykład oparty o JDO w ramach JavaSE. Nie będę tu przytaczał dokumentacji, co i jak, bo kod jest prosty. A jak ktoś chce poczytać więcej, czemu JDO jest lepsze od JPA i innych wynalazków to zapraszam do lektury dokumentacji pod w/w linkami.

Przytoczę tylko jedną zasadniczą różnicę. W przypadku Hibernate'a / JPA mamy do czynienia z klasami proxy, które opakowują nasze encje, stąd np. problem z Lazy Initialization czy z porównywaniem instancji (instanceof). W przypadku JDO jest tzw. proces rozszerzania klas (ang. enhancer), który zmienia byetcode klasy encji, dodając do niego wymagane elementy potrzebne do utworzenia encji zarządzalnej przez JDO. Jest to dalej nasza klasa i instanceof zadziała, możemy również zapomnieć o Lazy Initialisation Exception :P

Do tego dochodzi możliwość zarządzania wszystkimi aspektami z poziomu API, nawet możliwość definiowania nowych klas i ich rozszerzanie w loci ;-)

Przejdźmy do kodu, oczywiście kod podstawowy wygenerowałem za pomocą komendy:

mvn archetype:generate

teraz uzupełniam pom.xml o zależności i dodaje plugin enhancera, celem automatycznego rozszerzania klas

    <build>
        <plugins>
            <plugin>
                <groupId>org.datanucleus</groupId>
                <artifactId>maven-datanucleus-plugin</artifactId>
                <version>3.0.0-release</version>
                <configuration>
                    <api>JDO</api>
                    <log4jConfiguration>${project.basedir}/resources/log4j.properties</log4jConfiguration>
                    <verbose>true</verbose>
                    <props>${project.basedir}/resources/jdo.properties</props>
                </configuration>
                <executions>
                    <execution>
                        <phase>compile</phase>
                        <goals>
                            <goal>enhance</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
 
    <dependencies>
 
        <dependency>
            <groupId>javax.jdo</groupId>
            <artifactId>jdo-api</artifactId>
            <version>3.0</version>
        </dependency>
 
        <dependency>
            <groupId>org.datanucleus</groupId>
            <artifactId>datanucleus-core</artifactId>
            <version>3.0.2</version>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.datanucleus</groupId>
            <artifactId>datanucleus-api-jdo</artifactId>
            <version>3.0.2</version>
        </dependency>
        <dependency>
            <groupId>org.datanucleus</groupId>
            <artifactId>datanucleus-rdbms</artifactId>
            <version>3.0.2</version>
        </dependency>
 
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.9</version>
        </dependency>
 
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>5.14.9</version>
            <scope>test</scope>
        </dependency>
 
    </dependencies>

Najważniejszym elementem jest plugin maven-datanucleus-plugin, który wykonuje rozszerzanie klasy w fazie kompilacji. Bez niego JDO nie będzie działać. Dostępny jest plugin do Eclipse'a, jak również w ramach pluginu do AppEngine istnieje wbudowana funkcja Enhancera.

Teraz pasuje napisać jakiś model, który będzie zapisywany w bazie danych.

@PersistenceCapable
public class Person {
 
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.INCREMENT)
    long id = 0;
    @Persistent
    String name = null;
    @Persistent
    int age = 0;
 
    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
 
    // gettery i settery, equals, hashCode, toString
 
}

Adnotacje chyba są dość zrozumiałe, a jak nie to proszę pytać w komentarzach ;-) Rzecz, na którą chce wam zwrócić uwagę to brak domyślnego konstruktora, który niestety trzeba dodawać w przypadku Hibernate'a i JPA, dla JDO nie jest to problemem ;-)

Kolejna klasa służy do zapisu/odczytu obiektów z bazy danych, jako że jest to prosty przykład oparty na JavaSE, dochodzi trochę śmieci związanych z transakcjami, ale łatwych do wyeliminowania stosując np. wzorzec Command ;-)

public class PersonPersister {
 
    public List<Person> list() {
        PersistenceManager pm = createPM();
 
        try {
            Transaction tx = pm.currentTransaction();
            tx.begin();
 
            Query query = pm.newQuery(Person.class);
            List<Person> list = (List<Person>) query.execute();
 
            tx.commit();
            return list;
        } catch (Exception e) {
            if (pm.currentTransaction().isActive()) {
                pm.currentTransaction().rollback();
            }
            e.printStackTrace();
            return Collections.emptyList();
        } finally {
            pm.close();
        }
    }
 
    public Person persist(Person person) {
 
        PersistenceManager pm = createPM();
 
        try {
            Transaction tx = pm.currentTransaction();
            tx.begin();
 
            Person persisted = pm.makePersistent(person);
 
            tx.commit();
            return persisted;
        } catch (Exception e) {
            if (pm.currentTransaction().isActive()) {
                pm.currentTransaction().rollback();
            }
            e.printStackTrace();
            return null;
        } finally {
            pm.close();
        }
    }
 
    private PersistenceManager createPM() {
        Properties properties = new Properties();
        try {
            properties.load(getClass().getResource("/jdo.properties").openStream());
        } catch (IOException e) {
            throw new RuntimeException("File 'jdo.properties' not found");
        }
        PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(properties);
        return pmf.getPersistenceManager();
    }
 
}

W sumie kod też powinien być zrozumiały, cała magia jest w jednej linijce:

PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(properties);

można to porównać do EntityManagerFactory z JPA, a dostępne metody można porównać na tej stronie. Z powyższego widać, że JDO nie jest wcale trudniejsze od Hibernate'a czy JPA, działa podobnie a daje o wiele większe możliwości.

Nie wspominał tu o Fetch Groups, czyli czymś co można porównać do FetchType.LAZY i FetchType.EAGER ale z o wiele większymi możliwościami, np. definiowanie w trakcie działania aplikacji jak i co ma być pobierane za jednym razem z bazy (czyli dynamiczny LAZY i EAGER ;-)

Albo definiowanie klas w trakcie działania aplikacji, rozszerzenie ich i dodanie to bazy danych. Możliwości, o których można pomarzyć w przypadku JPA ;-)

Cały kod aplikacji jest dostępny w repozytorium na GitHubie.

Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/

PS. Cześć druga do RESTeasy jest prawie gotowa ;-)

etykiety:

java

projektowanie

Global Day of Coderetreat

Łukasz Lenart — Mon, 21 Nov 2011 11:46:00 +0000

Początkiem grudnia na całym świecie odbędzie się kilkadziesiąt imprez pod wspólnym hasłem Global Day of Coderetreat, czyli wspólnego uczenia się kodowania za pomocą TDD i Pair-Programming. Jak do tej pory w Polsce odbyło się kilka pojedynczych sesji Coderetreat, jedna była prowadzona przez samego Corey'a Haines, było to podczas konferencji AgileCE 2010.

Z tego co można zaobserwować na stronie GDCR do udziału w zabawie zgłosiły się trzy miasta - Kraków, Warszawa i Poznań. Tak więc można spokojnie wyszukać najbliższe miejsce i zapisać się do udziału w zabawie.

Czym jest Coderetreat ?

Tak jak pisałem - jest to zabawa, piszemy Grę w Życie (Game of Life) stosując praktyki TDD i programowanie w parach. Piszemy w dowolnym języku, co chyba jest najlepszym sposobem na poznanie np. Rubiego dla programistów Java ;-)
Cały wydarzenie jest podzielone na kilka 45-minutowych sesji, pomiędzy którymi pary są mieszane, czyli każdą kolejną sesję rozpoczynasz kodować z kimś innym ;-)

Podczas GDCR planowane jest połączenie video między różnymi lokalizacjami, aby na bieżąco uczestniczyć w spotkaniach na całym świecie.

Niestety nie mam informacji co jest planowane w Warszawie i w Poznaniu, ale podczas GDCR w Krakowie, organizatorzy ugoszczą wszystkich uczestników obiadem, będzie dostępna kawa jak również okazjonalne koszulki i to nawet dwie dla każdego - jak uda wszystko się dopiąć. Wieczorem planowane jest mała impreza, gdzie przy piwie będzie można porozmawiać nie tylko o kodowaniu. Całe wydarzenie jest darmowe, wystarczy się zarejestrować.

Organizatorem jest grupa Software Craftsmanship in Kraków przy wsparciu Lunar Logic Polska, ABB i Applicake. Partnerem globalnym jest JetBrains.

Liczba miejsc jest ograniczona, więc zapisz się już dziś, jeśli chcesz spędzić wolną sobotę na wspólnym kodowaniu ;-)

Pozdrawiam
--
Łukasz
http://www.lenart.org.pl/

etykiety:

spotkania