Je čas na Apache Wicket?

Záznam diskuze:
L: Ahoj Franto, mám menší problém.
F: Jaký Lumíre?
L: Nevím, který webový framework pro javu je nejlepší.
F: No to je jednoduché. Vyzkoušej těch 40 nejznámenjších a pak se rozhodni.
L: Hmm... :(
Konec.

Ať již člověk navštíví jakoukoli homepage webového frameworku, dočte se, že zvolil dobře. Nejlepší možné řešení, vše jednoduché, perfektně rozšířitelné a v porovnání s ostatními je proste "Number ONE".

Sám jsem již dávno rezignoval na hledání zlaté žíly v podobě nejlepšího řešení. Volbu by mělo ovlivňovat to, jakou architekturu dané aplikace plánuji či jakým backendem aplikce disponuji. I když jsou snad všechny možné kombinace možné (Seam + Spring, Seam + EJB, Wicket + Spring, ...., ne vždy je volba zrovna šťasná. Pokud do hry vložím další možnosti jako volání část aplikace jiným způsobem (např. remote EJB), dostávám již užší skupinu možností.

Z této skupiny, která se vyznačuje volnou vazbou na business logiku, snadnou rozšířitelností a možností souběžného běhu s jiným web kontextem mi zatím nejlépe vychází Apache Wicket.

Ano já vím, stále existuje lepší .... nebo ještě lepší .... a vlastně úplně nejlepší ...... Ale já nemám čas ani náladu zkoumat další desítku možností. Stačí mi ta první desítka :)

Proč Apache Wicket?

• volná vazba na business logiku


• žádné xml


• žádné anotace, které z POJOs dělají komponenty použitelné pouze v daném kontextu


• téměř čisté html


• vše je psané v jave, takže refactoring je mnohem snažší záležitost


• dané komponenty si pamatují předchozí stav, takže tlačítko zpět již nemusí být noční můrou


• menší zátěž pro server oproti JSF či Seamu


• psaní aplikace je velmi blízké psaní swingových aplikací


• dostatek komponent + snadné psaní znovupoužitelných komponent


• při psaní se skutečně využívá objektově orientovaných principů


• pro běh není třeba žádného speciálního kontextu (běží stejne v Tomcatu jako v AS)


• daná aplikace je snadno přenositelná na jakýkoli jiný web kontejner

Asi bych mohl pokračovat dalšími body. Nicméně to, co jsem zde vypsal jsou vlastnosti, které mě přesvědčují o správné volbě.

Co se týče záporů, ty si budu muset nechat na pozdější dobu. Zatím jsem jen nezávislým pozorovatelem daného web frameworku. Každopádně jsem pevně rozhodnut toto řešení použít i za cenu složitejší spolupráce s EJB modulem a částí aplikace napsané v Seamu.

Takže mám 2 favority. Seam a Apache Wicket. Každý z nich přistupuje k cíli jiným způsobem a každý z nich se rozhodně hodí pro jiný typ aplikací. Až si Apache Wicket více osahám pokusím se obě řešení více porovnat a přesněji zjistit, pro jaký typ aplikací se dané frameworky hodí.

Testování EJB komponent

Všeobecně známý fakt, že se EJB komponenty špatně testují, je postaven zejména na tom, že neexistuje žádný standardní způsob, jak při psaní testů postupovat. Pokusím se sepsat způsoby, jak tento palčivý problém vyřešit.

O tom, že je testování důležitá část vývoje, nemá smysl polemizovat. V poslední době se na české scéně objevilo několik článků: "proč je testování důležité". Osobně zastávám názor, že bez testů nemohu kód považovat za funkční a jeho nasazení je velký risk, který se násobí následným refaktoringem či řozšiřováním stávajícího kódu.

V následujících odstavcích se budu zabývat jen EJB 3.0.

Způsoby testování bych rozdělil na 2 typy: testování uvnitř aplikačního serveru a mimo něj.

Testování uvnitř aplikačního serveru

Tento způsob má tu výhodu, že dané testy se mohou začít psát bez jakékoli další pomůcky pro inicializaci EJB kontejneru a služeb v něm. Ohromnou nevýhodou je ovšem to, že samotné psaní a spouštění testů je přímo závislé na nastartování a nahrání celé aplikace na server. Tato činnost může při větších projektech trvat řádově i několik minut. V takové chvíli může vývojář získat naprostý odpor k testování.

Způsob, jak testovat EJB komponenty uvnitř AS, je použití vzdáleného volání EJB komponent. Nevýhodou je ovšem to, že při návrhu musíte definovat "remote" rozhraní.

Druhým způsobem je testování přímo v EJB komponentě, kde mohu pomocí DI (dependency injection) získanou EJB komponentu otestovat. Nevýhodou je zde to, že tento způsob již překračuje základní způsoby testování. JUnit či jemu podobný framework je v takovém případě nepoužitelný.

Testování mimo aplikační server

První velkou nevýhodou tohoto řešení je samotný fakt, že nějak musíte nahradit EJB kontejner. Asi nejznámějším řešením je použití Embedded JBoss.Tento způsob vyžaduje, aby vaše aplikace byla schopná běžet pod JBoss AS, a abyste použili JVM 1.5 (na novejších verzích bohužel embedded JBoss nespustíte). Pokud aplikaci vyvíjíte pod jiným aplikačním serverem, budete s tímto mít asi problémy. Například už jen z důvodu samotné nestandardizace JNDI či použitých nekompatibilních vlastností pro Java EE 5.

Druhým způsobem, jak umožnit testování EJB komponent mimo aplikační server je, že použijete framework typu Ejb3unit, který na základě vaší definice EJB komponent sám provede dependency injection a další vlastnosti typické EJB kontejneru. Nevýhoda tohoto řešení spočívá v tom, že má příliš mnoho omezení, která poté mohou zbytečně ovlivňovat návrh business vrstvy. Na stránkách je možné se dočíst, že brzy vyjde verze 2.0, která snad přinese slibované vlastnosti.

Posledním způsobem, jak vyřešit testování, je použití vlastního řešení. Jelikož používám jako aplikační server Glassfish, byl pro mne JBoss Embedded tabu. Jelikož mám i uvnitř EJB komponent občas složitejší architekturu (dělené vrstvy), tak Ejb3unit byl nepoužitelný.

Můj vlastní způsob spočívá v tom, že testuji EJB komponenty, které obsahují vazby na další EJB pomocí anotací @EJB či vstřikují pomocí @PersistenceContext EntityManager (+ občasné delegování na Hibernate Session).

Jinými slovy, řídím EJB pomocí anotací, což mi umožňilo napsat si i vlastní řešení na testování. Moje řešení totiž využívá Java reflection API, přes které provádím jak dependency injection dalších EJB komponent, tak samotné DI EntityManageru a dalších zdrojů, které zrovna potřebuji.

Test poté vypadá jednoduše: "při inicializaci pošlu testovanou EJB komponentu do metody, která mi vrátí instanci samotné EJB komponenty i s inicializací potřebných závislostí".

Zatím jsem nenalezl lepší řešení. Pravdou je, že v této oblasti jsou EJB komponenty nechány napospas vývojářům, což s sebou přináší jen nekompatibilní způsoby testování jednotlivých částí aplikace.

Doufám, že Glassfish V3 přinese slibovanou možnost být "embeddable" v plném rozsahu či někoho v SUNu napadne s tímto problémem něco udělat. Zatím mi přijde, že každý si napíše vlastní řešení, protože kromě JBoss Embeddable jsem nenašel nic, co by alespoň trošku splňovalo mé požadavky.

Pokud má někdo zkušenosti i s dalšími možnostmi testování EJB komponent, nechť se o ně podělí v komentáři, děkuji.

NetBeans 6.1 a Facelets plugin

O tom, že vyšly Netbeans 6.1 se nemá smysl zmiňovat. Ovšem výhodou této verze je zejména její rychlost, na kterou se údajně vývojáři nejvíce zaměřili.

Jedna věc mi ovšem zde chyběla. A to opět plugin pro facelets :)

Naštěstí existuje řešení, jak daný plugin dostat do této verze.

Následující text je spíše dočasný, tzn., že  až vyjde oficiální podpora, jistě bude lepší použít přímo ji.

Na stránce https://nbfaceletssupport.dev.java.net/ je k dispozici cvs repozitář. Z daného repozitáře stačí provést checkout projektu a daný projekt "nbfaceletssuite" otevřít v NetBeans 6.1. Dané pluginy poté zbuildovat a provést create nbm. Tyto pluginy jsou poté schopny pracovat ve verzi 6.1.

Pak již stačí pluginy nainstalovat a máte k dispozici starou dobrou (i když ne zrovna plnou)  code completion v xhtml souborech :)

Glassfish V3 bude embeddable

Minulý týden mi v rss čtečce přistál článek od Kohsuke Kawaguchi, že Glassfish V3 bude "embeddable".

Osobně jsem si přesně toto pro Glassfish přál. Představte si, že budete mít EJB projekt, který budete moci spouštět např. v Tomcatu. Že budete moci testovat EJB, aniž by bylo potřeba provádět deploy na server či používat remote call EJB či používat "nepoužitelné" frameworky jako je EJBUnit (i když uvidíme jak dopadne verze 2.0). Vše co obsahuje specifikace Java EE 5 a vše co implementuje Glassfish je tedy možné provozovat aniž by někde musel běžet daný server.

V současné době se touto možností může chlubit JBoss AS či Jetty, nyní již stačí počkat pár měsíců (možná týdnů do testovací fáze) a bude možné to samé dělat s GlassFish.

Díky modularitě tohoto AS je ovšem možné startovat server v řádech několika milisekund, což narozdíl od JBoss AS je podstatný rozdíl :)

Před nějakým časem jsem chtel Glassfish opustit a jít cestou JBoss, ale asi ještě chvíli počkám, je vidět, že konkurenční prostředí je prostě ideální stav.

Teď nezbývá, než držet palce, ať se dané featury dotáhnou do úspěšného konce.

Informace o WebBeans

O víkendu jsem shlédl video, ve kterém Gavin King přednášel o WebBeans. Z daného videa mám vcelku dobrý pocit a pokusím se zjednodušeně sepsat, co v přednášce bylo a jak asi bude vypadat psaní takových Web Beans.

Web Beans jsou novou specifikací, která se objeví v Java EE 6. Mezi hlavní účel patří zjednodušení vývoje webových aplikací. Samotné Web Beans jsou inspirovány (kopie) webového frameworku Seam. Jelikož je autorem jeden a tentýž člověk (Gavin King), je vcelku jasné, že lidé, kteří znají Seam budou na Web Beans přecházet stejně jednoduše jako třeba v případě Hibernate -> JPA.

Takže, co například Web Beans poskytují a nabízejí:

• možnost psát komponenty jako Stateful EJB, které se anotací vystaví jako Web Beans se všemi vlastnostmi Stateful EJB


• dependency injection, jednoduché vstříknutí do JSF stránek; tak jako v Seamu


• konverzace


• ovládání persistence context, která může např. řešit lazy loading


• integrace s JSF, Servlety či JPA


• JSF backing beana může být vystavena jako Web Beana


• atd.

Nikoho asi nepřekvapí, že samotné Web Beans jsou řízeny pomocí anotací. Samozřejmě opět existuje možnost používat xml, ale myslím, že tato volba bude zřídkakdy využívána a nejsem si jist, že všechny možnosti budou v xml obsaženy.

Jak tedy takové Web Beans vypadají? Příkladem může být jednoduchá komponenta:

@Component
public class Komponenta {
    public String pozdrav(String jmeno) {
        return "Ahoj " + jmeno;
    }
}

Samotnou anotací @Component označujeme, že se jedná o Web Bean komponentu. Kontejner nám takovouto třídu inicializuje jako Web Beanu. Nic převratného.


Dependency Injection

Při psaní definování závislosti mezi jednotlivými komponenty můžeme použít několik možností:

@Component
public class Printer {
    @Current Komponenta komponenta;

    public void pozdrav() {
        System.out.println(komponenta.pozdrav("Ales"));
    }
}

Další možností, jak definovat závislost je např:

@Component
public class Printer {
    private Komponenta komponenta;

    public Printer(Komponenta komponenta) {
        this.komponenta = komponenta;
    }

    public void pozdrav() {
        System.out.println(komponenta.pozdrav("Ales"));
    }
}

Gavin tento způsob názývá "constructor injection" :)

Aby toho nebylo málo, máme zde další možnost nazvanou "initializer injection":

@Component
public class Printer {
    private Komponenta komponenta;

    @Initializer
    initKomponent(Komponenta komponenta) {
        this.komponenta = komponenta;
    }
}

A nyní jednoduché vstříknutí do JSF stránky:

Další věcí, která stojí za zmínku je definování "binding type". Jde o to, že mohu vzít komponentu, tu podědit a při stríknutí závislosti chtít podědenou komponentu. No raději to předvedu :)

Definice vlastniho "binding type":

@BindingType
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER}}
public @interface Casual{}

Nyní již stači napsat vlastní komponentu dědicí moji "komponenta".

@Casual
@Component
public class Cau extends Komponenta {
    public String pozdrav(String jmeno) {
        return "cau " + jmeno;
    }
}

A nyní již vstříknu vlastní komponentu do Printeru.

@Component
public class Printer {
    @Casual Komponenta komponenta;

    public void pozdrav() {
        System.out.println(komponenta.pozdrav("Ales"));
    }
}

Výsledkem bude: "Cau Ales".


Věcí, které Gavin King představil je opravdu hodně. Já zde ukážu poslední věc, která je jistě neméně zajímavá.

Nazval bych to "zástupnými anotacemi". Jak jsem na začátku psal, Web Beans jsou řízeny pomocí anotací, což ovšem může vyvolat určité rozpaky ve chvílích, kdy samotná Web Beana bude obsahovat hromadu anotací, které se často opakují.

Představme si, že máme takovouto Web Beanu:

@Component
@Transactional
@Production
@Secure
public class Komponenta {}

Výčet anotací může být i delší, což mě trochu děsí :)

Je však možné použít následující:

@Secure
@Transactional
@Named
@Production
@Stereotype
@Retention(RUNTIME)
@Target(TYPE)
public @interface Action {}

A nyní již použít:

@Action
public class Komponenta {}

Alespoň že tak :)

Všem, kteří se alespoň trochu zajímají o nové specifikace v oblasti J2EE by si měli dané video prohlédnout.
Já osobně jsem si alespoň udělal lepší obrázek o tom, jak vlastně WebBeans budou vypadat.

Zatím musím uznat, že jsem nadmíru spokojen. Pokud bude vše tak, jak Gavin King ukazuje, asi pošlu jeho Seam do věčných lovisť :) Nenarazil jsem v podstatě na nic podstatného, co by Seam měl a WebBeans nikoli. Zatím to vypadá na pravý opak.

Richfaces pro JSF

Komponentový framework jakým je JSF, má několik kladů, mezi kterými také nalezneme možnost rozšíření o vlastní komponenty. I když psaní vlastních komponent pod JSF není zrovna triviální záležitost.

JSF ve verzi 1.2. nabízí základní komponenty, které mohou být i rozšířitelné, ovšem ne vždy nám vyhovují.  Existence různorodých komponent za nás řeší knihovny třetích stran, které nabízejí zajímavé možnosti. Mezi nejčastějšími požadavky na komponenty jsou různé formulářové objekty, modální panely, stromy, menu, tabulky, atd. Navíc je očekávána podpora AJAXu. Jinými slovy, komponenty, které se svou vizuální a funkční podobou blíží desktop aplikacím.

Pro srovnání různých komponentových knihoven můžeme použít např. AJAX JSF Matrix. Možnost výběru je skutečně obrovský a to nepočítám další, které vznikají téměř každý den.

Samotná volba není zrovna jednoduchá. Já jsem prošel asi 3 různé knihovny z nichž jsem si vybral jasného favorita: RichFaces.

RichFaces

RichFaces má v současné době v  rukou JBoss. Jedná se klasickou JSF komponentovou knihovnu, která ovšem navíc obsahuje i přímou vazbu a podporu A4J (Ajax4JSF). A4J, jak už její název vypovídá se zaměřuje čistě na AJAX a snaží se naučit JSF komponenty asynchroní práci. Jelikož je RichFaces společně s A4J dodávaná jako jedna knihovna (projekt), může nás těšit fakt, že máme jednu z nejlepších kombinaci mezi AJAX-JSF-Komponenta.

V současné době je RichFaces ve verzi 3.2.0, která vyšla vcelku nedávno. Mezi jejími novinkami můžeme najít věci jako: vlastní combo box, progress bar, file upload, atd.

I když je pravda, že s každou novou verzí můžeme nalézt v bugtraceru hromadu opravených a hromadu nový bugů, přesto je tato knihovna použitelná v produkčním nasazení.

Mě nezbývá, než tuto knihovnu doporučit všem, kteří nemají svého favorita a hledají nejakou slušnou podporu pro JSF komponenty. Psát modální okna, kontextová menu či rozbalovací stromy už nemusí být jen výsadou programátoru desktop aplikací.

Pro zběžný přehled doporučuji samotné demo, které je plně přístupné po zaregistrování na RedHat stránkách, kde si jednotlivé vlastnosti můžete ihned vyzkoušet.

Seam - tipy a triky (EJB)

Seam je dobře použitelný s EJB, kde jsou jednotlivé EJB vystaveny jako Seam komponenty a navíc obsahují všechny služby, které EJB kontejner nabízí.

Jsou ovšem chvíle, kdy bych potřeboval obyčejnou Seam komponentu a do ní nějakým způsobem vstříknout EJB beanu. Co se týče implementaci pro glassfish, není situace tak jednoduchá, jak by se mohlo zdát.

Takže, mějme příklad, kdy potřebuji vytvořit Seam komponentu, která bude míti jednu metodu, která bude vracet seznam hodnot z nějaké entity.

Klasický přístup by mohl vypadat následovně:

@Name("testList")
public class TestList {
   @Unwrap
   public List<Entita> lookup() {
      return entityManager.createQuery("from Entita e").getResultList();
   }
}

Použití ve facelets stránce by poté vypadalo následovně:

Pravdou je, že použití samotné anotace @Unwrap může mít hezké uplatnění.

Jenže, osobně se mi nelibí možnost, že musím uvnitř samotného "testListu" volat entity manager a navíc psát nějaké OQL. Mám již definovanou DAO vrstvu pomocí EJB a chci lookupnout samotnou EJB jako Seam komponentu.

K tomtuto účelu jsem si vytvořil jednoduchou lookup službu, která vypadá následnovně:

@Stateless
@Name("lookup")
@Scope(ScopeType.APPLICATION)
@Interceptors(value = {SeamInterceptor.class})
public class LookupBean implements LookupLocal {

     @Resource
     private EJBContext context;

     @EJB
     private SessionLookupLocal sess;

     public Object ejb(String bean) {
          return context.lookup(bean);
     }

     public EntityManager getEntityManager() {
          return sess.getEntityManager();
     }

     public Session getSession() {
          return sess.getSession();
     }

}

Takže lookup služba slouží k získaní jak EJB beany tak entity manageru popřípadě Hibernate Session. Dá se sice namítnout, že Seam umí přímo injectnout EntityManager (dokonce se to dá hackem zprovoznit i v glassfish), ale já si raději vsrtvy odděluji, proto injectuji daný "persistence provider" jen v nejnutnějších chvílích. Druhou věcí je fakt, že daný provider pro persistenci přenáší jiná EJB beana. Důvodem je fakt, že při inicializaci a vytvoření Seam komponenty ještě není znám provider pro entity manager, proto ho musím získat z jiné EJB.

Ale zpět. K tomu, aby daná lookup služba (která je jak Seam komponentou tak EJB komponentou) byla schopná lookupovat EJB, musí být navíc definovana reference na dané EJB beany v ejb.jar.xml, nebo pomocí anotací. Já jsem zde raději přistoupil k možnosti pomocí XML, jelikož se jedná o speciální požadavek, který se v průběhu života může změnit.

    
        
            LookupBean
            cz.irminsul.seam.app.LookupBean
            
                NejakaDAOBean
                cz.irminsul.NejakaDAOLocal
                NejakaDAOBean
            
        
    

Díky této definici reference mám možnost uvnitř lookupBean získávat ejb dynamicky, tedy přes initialContext.

Konečné použití uvnitř Seam komponenty, která není EJB beanou, může vypadat následovně:

@Name("testList")
public class TestList {     

     @In(value = "#{lookup.ejb('NejakaBean')}")
     private NejakaLocal bean;

     private List<Entita> data;

     @Unwrap
     public List<Entita> lookup() {
          if (data == null) {
               data = bean.metodaLokalnihoInterface();
          }
          return data;
     }

}

Samozřejmě je možné získat i Entity Manager či Hibernate Session. Použití je v podstatě jasné:

@In("#{lookup.entityMananger}")
private EntityManager em;

Daný návod je funkční v Seam 2.0, EJB 3 a Glassfish V2.