Přeskočit na hlavní obsah

Příspěvky

Zobrazují se příspěvky z 2008

Apache Wicket - Znovupoužitelné komponenty

Tvorba vlastních komponent je u komponentově orientovaného web frameworku, důležitá vlastnost. Jen težko bych hledal projekt, který by si vystačil s existujícími vlastnostmi a komponenty daného rámce a nesnažil se o vlastní tvorbu.

Pokud bych Wicket srovnával s JSF na této úrovni, musel bych více podrobněji znát tvorbu komponent v JSF. Ať jsem se snažil sebevíc, nikdy jsem úplně neodhalil výhody vlastních komponent v JSF. Ten postup mi přišel natolik složitý a nesmyslný, že v tomto případě jsem vždy sáhnul po něčem existujícím (RichFaces, Tomahawk, atd.). V JSF mám v tomto ohledu jen teoretickou znalost, která mi ovšem stačí k tomu, abych se do nečeho takového, jako je tvorba vlastních komponent, vůbec nepouštěl.

Ve Wicketu je situace naprosto rozdílná. Samotný framework mě v podstatě nutí rozsekávat danou prezentaci do několika menších celků, které se později dají znovu použít. Navíc je situace o to snažší, že není potřeba se učit či používat nové věci. Bohatě stačí znalost základních …

JPA 2.0

Nedávno zveřejněná specifikace JPA 2.0 obsahuje asi nejzásadnější posun v možnosti psaní Criteria API. Pokud někdo očekává okopírované Criteria API z Hibernate bude možná trošku zklamán (či potěšen).

Nový způsob je totiž více postaven na "objektovosti" daných entit. Dobrý zdroj a ukázku lze najít na blogu Gavina Kinga.

Osobně toto považuji za správný krok. Samotné JPA (EntityManager) umí pouze JPQL dotazy, které jsou napsané jako jeden String řetězec. To sebou přináší hromadu nevýhod a v mnoha případech nutí, aby si vývojář napsal nějaký ten vlastní "JPQL String Parser". Z tohoto důvodu jsem osobně JPA degradoval na "pouhé" ORM mapovaní, kde mi jasně specifikovaný standard umožňuje být více nezavislý na použitém "provideru pro persistenci". EntityManager jsem vyměnil za "Hibernate Session" a vesele si psal svá Criteria API.

Hibernate Criteria API ovšem nejsou všespásná. V některých případech je tento způsob nepoužitelný. Občas člověk nara…

Apache Wicket - IBehavior, Tabulky

Minule jsem psal o možnosti spojení Wicketu s EJB3 a o Wicket Security. Dnes se podívám na další vlastnosti a možnosti tohoto webového frameworku.

IBehavior

Jedná se o interface, který je označován jako druh pluginu wicket komponent. Já jsem dané řešení využil například pro statistiku návštěvnosti či pro zjistění, jak dlouho trvalo vyrendrování wicket stránky.

Příklad, pro zjištění doby trvání vyrendrování wicket stránky:
public class TimeBehavior extends AbstractBehavior {
private long start;

@Override
public void beforeRender(Component component) {
start = System.currentTimeMillis();
}

@Override
public void onRendered(Component component) {
super.onRendered(component);
long dobaBehu = System.currentTimeMillis() - start;
// dalsi zpracovani
}
}

Třída je potomkem AbstractBehavior, což je adaptér pro interface IBehavior. Tuto implementaci stačí poté přiřadit v "BasePage" (základní Wicket Page, která je předkem všech Page). Samozřejmě, pro Wicket je Page komponent…

Trocha dávky Apache Wicket

Od posledního příspěvku na tomto blogu již uplynula nějaká ta doba. Nebudu tvrdit, že jsem neměl čas. Důvodem byla spíše chuť něco nového napsat. To je ovšem pryč, takže se vrátím zpět ke svému psaní :)

Apache Wicket je zajímavý hned z několika důvodů. Některé z nich jsem prezentoval minule a proto dnes přidám snad jediný důvod: baví mě v něm psát aplikace.

Každý, kdo má alespoň obecnou znalost tohoto frameworku, musí si daný způsob ihned spojit s psaním aplikací ve swingu. Asi bych to vyjádřil slovy: piš to jako ve swingu a přidej k dané třídě html soubor.

Wicket a EJB3

Dají se tyto dvě technologie jednoduše spojit? Repektive dá se snadno zařídit závislost wicket komponenty na EJB servisní beaně? Ano dá. Stačí stáhnout wicket-contrib-javaee.

Pro schopnost provést jednoduché DI (dependency injection) přes anotaci @EJB je třeba definovat referenci ve web.xml.
<ejb-local-ref>
  <ejb-ref-name>cz.irminsul.javaee.ejb3.ServiceLocal</ejb-ref-name>
<ejb-ref-type>Session</e…

Serial port v Jave aneb RXTX

Jakožto spokojený uživatel linuxu jsem dost odstíněn od windows. Bohužel to sebou přináší i určité problémy, kdy potřebuji portovat aplikaci na windows.

Ano, java je multiplatformní, jenže pouze do chvíle, kdy potřebujete přistupovat k sériovému portu a číst z něj data. K tomuto účelu existuje několik možností, které ovšem v jave znamenají implementovat funkčnost pouze pro daný OS.

Nic není tak černé, a proto existuje možnost, jak donutit vaši aplikaci, aby uměla komunikovat se sériovým portem na více OS. To vše bez nutnosti měnit stávající kód.

Ta možnost je přes RXTX. Kromě klasického COMx umí i LPT či USB.

Samotná implementace je víceméně jednoduchá:

nakopírují se příslušné knihovny (u linuxu do usr/lib/ a u windows do jre/bin).
přes JNI se zavolají příslušné metody z knihoven daných OS
otevře se port, zaregistruje listener a již mohu číst či zapisovat.

Jelikož na notebooku používám redukci mezi USB a sériovým portem, trochu jsem se bál samotného zprovoznění. Opak je pravdou. Přes identif…

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 …

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é aplika…

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 …

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.

Nik…

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.…

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…

DTO a ORM

Pojem DTO jistě není třeba představovat. Jedná se o objekt reprezentující data, které je třeba přenést z jedné strany na druhou. Asi nejčastějším využitím jest výsledek dotazu z persistentní vrstvy.

Při použití ORM frameworku, jako je např. Hibernate, definuji data v DB pomocí objektů (entit). Tyto entity poté mohou být i výsledkem, tedy mohou představovat jak doménový model aplikace, tak i dané DTO. Jsou ovšem chvíle, kdy takové DTO je nepoužitelné či jeho použití může znamenat výrazný pokles výkonnosti aplikace.

Prvním příkladem, kde entita nemůže (neměla by) být reprezentována jako DTO:
"Vytvoř seznam zaměstnanců s celkovým počtem odpracovaných hodin."
V takovém případě je třeba výsledek z OQL přemapovat do vlastního objektu (DTO), který bude obsahovat číslo, jméno, příjmení, celkový počet hodin. Sice by někdo mohl namítnout, že daná hodnota (odpracované hodiny) se dá do entity, jako @Transient, přidat. Ale doménový model bych se neměl "špinit" vlastnostmi, které r…

Seam - tipy a triky

Jelikož jsem zastánce tohoto frameworku, z jichž uvedených důvodů, rozhodl jsem se sepsat pár dobrých triků, které mohou pomoci při vývoji s tímto frameworkem. Dnes začnu asi tou nezajímavější a tím je Hot Deploy, nebo-li rychlá aktualizace některých částí aplikace bez nutnosti provádět celé nahrání aplikace na server.

Hot deploy - NetBeans
Netbeans 6.0 má dost slabou, respektive nulovou, podporu pro tento framework. Jednou z dobrých vlastností Seamu je tzv. hot deploy, kde změny na view vrtvě mohou být aplikovány bez nutnosti provádení undeploy-deploy aplikace. Jedná se zejména o změnu facelets stránek. Takže jak něčeho takového dosáhnout v netbeans?

Stačí vytvořit vlastní "ResourceResolver", který se poté zaregistruje v web.xml.
Příklad takového ResourceResolver:
public class FilesystemResourceResolver implements ResourceResolver {
private static final String PATH_TO_DEVELOPMENT = "/home/ales/dev/java/Irminsul/Irminsul-war/web/";
public URL resolveUrl(String s)…

Linux pro javistu

Na svých oblíbených weblozích jsem našel několik příspěvků, které se věnovali linuxu, coby hlavnímu operačnímu systému pro programátora. Psal o tom dagi či ronnie. Jeden je v navážkách, druhý utekl zpět k windows.

Abych nebyl výjimkou, rozhodl jsem se, že ho teda také vyzkouším. Linux jako systém považuji za velice úspěšný na serveru, co se týče osobního desktopu, vždy jsem našel něco, co mě přinutilo vrátit se k windows. Dnes již tomu tak není a já se pokusím sepsat vše, co mě monentálně k tomuto tématu napadá.

Proč práve linux?
Není v tom nic speciálního. Na serveru nám běží bez problémů a já si chtěl vyzkoušet, zda by můj notebook nebyl s tímto systémem "rychlejší" a "efektivnější". Nehledám v tom nic převratného, a ani nechci zkoušet něco, abych jen vybočoval z "řady windowsáků".
Linux tedy zkouším čistě ze zvědavosti s nadějí, že objevím něco "užitečného".

Výběr distribuce a HW
Výběr distribucí linuxu je ohromný. Má volba padla na SuSE, jednak…