Poměrně pravidelně dojíždím z Pardubic do Hradce Králové dopravou a docela často používám server http://jizdnirady.idnes.cz/JRCis.asp na vyhledávání spojů. Nemohl jsem si nevšimnout, že nedávno tento server přešel pod správu společnosti MAFRA, a.s.. Všimnul jsem si a musím tedy kroutit hlavou.

Celý portál je kompletně zahlcený reklamou na další web projekty této společnosti a to velmi nevkusně a nepříjemě. V záplavě blikajících obrázků a linků kamsi, člověk jen obtížně nachází to, kvůli čemu na portál přišel - vyhledávací formulář.

Před tím, než jsem mohl ozkoušet maven-release-plugin, na který jsem si stěžoval v článku Co bych rád slyšel v září na CZJUG, musel jsem rozchodit přístup do našeho CVS skrze SSH s přihlašováním pomocí privátního klíče. Po zkušenostech můžu říct, že to byla práce nelehká a musím potvrdit negativní ohlasy ostatních, že v některých případech dokumentace k Mavenu (respektive k jeho konkrétním pluginům) je opravdu nedostatečná. Oříšek jsem nakonec rozlousknul díky zdrojákům a oddebugování.

Kamarád mi poslal odkaz na zajímavý článek. Jistě všichni znáte ochranu zneužití veřejně dostupných formulářů pomocí CAPTCHA. Koneckonců je většina z nás má na svých blozích po tom, co nám začaly chodit spamové komentáře k článkům. Pánové z Carnegie Mellon University však našli způsob, jak tento otravný fenomén převést na něco, co je užitečné.

Na světě existuje ohromné množství tištěné literatury, které se snaží archiváři digitalizovat, aby se zachovaly pro budoucí generace. Při digitalizaci se používá OCR pro rozeznávání textového obsahu. OCR však není v řadě případů úspěšné - prostě nedokáže rozeznat napsané slovo (podle statistiky 1 z 10). Výsledkem je tedy text, který je více či méně znehodnocený a je nutný lidský zásah, aby byl původní text zkompletován.

Aplikační události jsou jedním ze základních stavebních kamenů Springu a proto by bylo škoda se ochudit o tuto skvělou vlastnost na rozhraní modulů. Je zřejmé, že nebudeme chtít otevřít všechny aplikační události svému okolí, nicméně u řady událostí bychom chtěli umožnit ostatním modulům reagovat. Jako příklad uvedu interakci mezi modulem pro správu uživatelů a notifikačním modulem - notifikační modul se stará o rozesílání emailových notifikací v reakci na konkrétní aplikační události (samozřejmě obecně - konfigurovatelně). To je typická ukázka stavu, kdy chceme, aby uživatelský modul dokázal emitovat třebas událost “založení nového uživatele” tak, aby notifikační modul mohl reagovat odesláním emailu.

V prvním díle jsme si ukázali, jak jednotlivé moduly separovat a propojit ve stromu. V předchozím pak způsob, jak strom udržet konzistentní a refreshovatelný za běhu aplikace. Dnešní díl bude o tom, jak jednotlivé moduly mezi sebou propojit - respektive, jak zajistit interakci mezi jednotlivými moduly.

Vystavení "interface" bean modulů

Pokud se vydáte cestou tvorby stromu z aplikačních kontextů, pravděpodobně narazíte na problém rozhraní jednotlivých modulů. Vraťme se k našemu příkladu reportovacího modulu, modulu uživatelů a web aplikace. Jak vyřešit velmi pravděpodobný usecase, kdy z web aplikace budeme chtít v reportu zobrazit seznam uživatelů? Jedná se o propojení všech třech modulů, které jsou nezávislé (mají oddělené životní prostory a jeden nevidí k druhému) a které jsou ve stromu na stejné úrovni - podřízené stejnému root contextu.

V této části seriálu si rozebereme problematiku refreshe stromu aplikačních kontextů. Toto je skvělá vlastnost Springu, která je často nedoceněná a málo používaná. Díky ní je možné jednoduše zahodit všechny současné instance bean definované v aplikačním kontextu a provést kompletní reinicalizaci kontextu s aktuální konfigurací (tak můžeme elegantně změnit chování aplikace bez nutnosti restartu serveru). S refreshem aplikačního kontextu se dá vyřešit poměrně dost věcí i v produkčním prostředí - navíc netrpí problémem PermGenSpace jako při reloadu kontextu celé aplikace na serveru. V situaci, kdy máme ale celý strom aplikačních kontextů se nám situace poměrně komplikuje - refresh se totiž stromem sám od sebe nezpropaguje.

V tomto díle si povíme něco o aplikačních kontextech, jejich vlastnostech a možnosti jejich řetězení do stromové struktury. Tato část je základem principem celého modulární skladby, jejíž detaily vám budu v následujících dílech popisovat. Jak jsem již uváděl v předmluvě, nejedná se o nic světoborného, jen o základní principy Springu.

Aplikační kontexty

Celý Spring je postaven na aplikačních kontextech. Aplikační kontext se dá nejlépe přiblížit ke class loaderům v Javě, má i řadu podobných vlastností. Aplikační kontexty mohou tvořit strom, kontexty v nižších úrovních se odkazují na kontexty nadřazené. Z nižších kontextů jsou viditelné beany v kontextech nadřazených, z nižších kontextů jsou ApplicationEventy posílány ke zpracování i do nadřazených kontextů. Pouze post processorové faktory (BeanPostProcessor a BeanFactoryPostProcessor) jsou pro každý kontext definovány zvlášť.

Ve chvíli, kdy začnete používat při vývoji masivněji Spring Framework a začnete vytvářet znovupoužitelné knihovny postavené nad tímto frameworkem, začnete řešit jak z těchto knihoven co nejlépe složit výslednou aplikaci. První myšlenky povedou pravděpodobně těmito cestami:

1. konfigurační soubory jednotlivých knihoven sloučit v jednom velkém aplikačním kontextu
2. držet jednotlivé knihovny odděleně - nechat jim jejich vlastní aplikační kontexty a k těmto kontextům se dostávat programovým způsobem

Obě cesty však mají svá úskalí.

Pokud mi někdo řekne, že moje aplikace má běžet v aplikačním serveru OC4J naskočí mi husí kůže. Tento reflex se mi už dostal do podvědomí kvůli řadě bezesných nocí řešením řady chyb ukrytých v kódu, ke kterým člověk nemá zdrojové kódy. Nedá se ovšem nic dělat, náš zákazník, náš pán. Opět jsem se tedy musel ponořit do zakalených vod bažiny OC4J.

Pozn.: Tento příspěvek byl psán ve velké depresi. Kdo nemáte rádi pesimistické články před víkendem, radši ani nepokračujte ;-) .

Tento post je tak trochu věnován Petru Ferschmannovi ze SoftEU, který bude mít 19. září 2007 přednášku na téma praktické nasazení Mavenu na CZJUGu. Jelikož vím, že občas na můj blog zamíří (doufám že pravidelně :-) ), věřím, že na článek zareaguje a kdo ví - třeba na moje otázky v září odpoví.

Problémy s maven-release-plugin

Vycházím z praktické zkušenosti (cca 3/4 roku staré tedy), kdy jsem se snažil použít maven-release-plugin pro vydávání verzi v multiprojektu. Typicky mám parent pom.xml v nadřízené složce, a pom.xml jednotlivých modulů ve složkách o úroveň níže (obdobný problém jsem ale měl i pokud jsem parent umístil také do složky druhé úrovně, myslím). Při použití maven-release-pluginu na parent projektu bych čekal, že správně releasne jak hlavní projekt, tak všechny moduly v něm registrované. Problém je v tom, že plugin všechny zdrojáky zataguje ve VCS a následně si je vycheckoutuje pod tímto tagem do složky "target". Po vycheckoutování mu ale nesedí relativní cesty k pom.xml jednotlivých modulů a celé to vyhoří. Jediným způsobem, jak plugin použít, pro mne bylo spouštět postupně releasy na všech modulech projektu, což bylo velmi nekomfortní. Dále mě na celém tomto způsobu vadilo, že v celém release procesu jsou spouštěny např. testy 2x - přitom by přeci stačilo je spustit jen jednou. Navíc parametry, se kterým se spustil daný release se posléze nepřenesly do buildování již té vycheckoutované verze - mám ten dojem, že plugin si interně spouští úplně novou instanci mavenu na zbuildování vycheckoutované verze.

Integrace build systému do IDE je věc pro mne nepostradatelná. Není ovšem integrace jako integrace. Pokud používáte Maven 2 a IntelliJ Idea jako my zjistíte, že pluginů je řada, ale velmi rozdílné kvality a velmi rozdílné aktuálnosti.

Navíc osobně si velmi cením možnosti buildovat projekt přímo z IDE - toto buildování je totiž řádově rychlejší než kterýkoli ant / maven build, jelikož IDE ví přesně, které třídy se změnily a zda je třeba překompilovat závislé třídy a když, tak jaké. Ant a Maven při vší své dokonalosti dokáží rozeznat a překompilovat jen třídy se změněným timestamp, ale závislé třídy nezkompilují. Dále mi to umožňuje jednoduše používat HOT replace funkcionalitu, pouštět testy přímo z IDE atd. Důvodů je prostě řada. Proto jsem chtěl, aby mi plugin pomohl zůstat ve svém IDE, ale pro správu dependencí a produkčních buildů využít daleko lepších možností Maven 2. Chvíli to trvalo, ale našel jsem.

Integrační testy spočívají v testování konkrétní kódu spolu s okolními částmi, se kterými spolupracuje. Cílem je snaha otestovat kód ve stavu, který se blíží reálnému nasazení. Obvykle takto testujeme datovou vrstvu aplikace (jelikož tam klasické jednotkové testy ztrácejí smysl - chceme přeci otestovat správné dotazování databáze, tudíž databázi k testu potřebujeme) a v řadě případů se nám nevyplatí mockovat ani na úrovni business vrstvy. Dokonce i Rod Johnson ve své prezentaci (kterou byl inspirován tento článek) zdůrazňuje důležitost integračních testů.

Jsou chyby malé, velké, závažné i triviální, úsměvné, spletité i velmi hloupé. Z celého pokolení chyb je tahle velmi, velmi stará a také dost hloupá. A vypadá to, že z úcty k jejímu věku, ji nechá M$ už pokojně dožít spolu s chatrčí zvanou Internet Explorer.

Na chybu narazíte tehdy, když coby Java programátor napíšete servlet, který vrací binární data přes protokol HTTPS (např. vygenerovaný MS Excel jako já, nebo třeba PDF atd.). Aniž byste to explicitně nastavili do HttpResponse, bude vrácená odpověď (pravděpodobně) obsahovat v hlavičce tyto údaje:

Nedávno na jednom připomínkovacím sezení mě zákazník překvapil přáním, že bych chtěl chránit své emailové adresy uvedené v kontaktech jako <a href="mailto:blabla@blabla.cz"/> proti zneužití spamboty. Jedná se o poměrně jednoduché přání, se kterým jsem se ale ve své praxi setkal poprvé. Obvykle, většina z nás akceptuje toto riziko výměnou za to, že naši zákazníci jednoduše kliknou na odkaz a otevře se jim rovnou jejich mailový klient s předvyplněnou adresou. Ihned nás napadlo vyměnit mailto linky za emaily vepsané např. do obrázku, ale to bychom přišli o tu výhodu jednoduchého otevření mailového klienta s adresou. Nicméně jednání jsme ukončili s vědomím, že si klient bude muset vybrat jedno nebo druhé. Nakonec mi to ale stejně nedalo a zkusil jsem pana gůgla ...

Spring framework má "od přírody" k dispozici implementaci Observer patternu. To není nic jiného než mechanismus "listenerů" tak, jak jej známe například ze Swingu. Základní a defaultní implementace je velmi jednoduchá, kdekoliv v managovaných beanách můžete přes tzv. Publisher (což je typicky aplikační kontext, kterým je daná beana vytvořena) vyslat informaci o události. Tuto událost pak může zpracovat jakákoliv třída implementující ApplicationListener rozhraní, a která je správně zaregistrovaná do fronty listenerů. Registrace se provádí velmi jednoduše - pouze deklarací beany v context.xml. AbstractApplicationContext (předchůdce všech specifických implementací aplikačního kontextu) při své inicializaci všechny beany implementující zmíněné rozhraní zaregistruje.

This presentation was prepared formerly for internal purposes of Norkom Technologies in Ireland by my old friend Pavel Jetenský. We appreciate that authorities of this company allowed us to make the presentation public so you can benefit from it as well. I also thank Pavel for preparing this presentation and for providing support to me with finalizing material to be published.

The training shows how to jUnit test J2EE application based on Spring and Hibernate. New unit test is created from scratch in Eclipse IDE, testing simple function for getting data from database. DB is created only in memory, using HSQL db. Training is targeted for developers with little or no experience with automated testing.

Na serveru The Server Side vyšel zajímavý článek o Artifactory. Pro ty kdož chtějí Artifactory nasadit pro vnitrofiremní použití se jistě jedná o velmi užitečný článek. Faktem je, že Artifactory se dá velmi jednoduše nasadit i bez větších znalostí - jedná se o velmi user friendly aplikaci.

Jediný problém, na který jsem narazil (a který je tedy relativně dost nepříjemný) byl ve verzi 1.2.1-rc0, kdy při deployi do repository se náhodně vracel HTTP 500 - Internal Server Error, díky problematické práci se zámky v JackRabbitu. Více zde. Problém je ale v pozdějších verzích již opraven

Je možné zajistit bezpečné sdílení HTTP session mezi oběma protokoly? Z dostupné dokumentace se dozvídáme, že nikoliv. Tento článek se zabývá možným řešením, které za jistých podmínek umožňuje bezpečně sdílet společnou session. Důvod proč se tímto problémem zabývat je jednoduchý - SSL šifrování je výpočetně nákladná věc (viz. např. Performance analysis of Secure HTTP Protocol). Proto je možná vhodné používat HTTPS pouze tam, kde je k tomu důvod (tedy např. uživatel pracuje s některými důvěrnými daty). Jistě se shodneme na tom, že na řadě webových aplikací je takto důvěrných míst pouze pár a zbytek bychom mohli hnát klidně přes protokol HTTP, čímž odlehčíme svému webovému serveru. Jenže tady narážíme na zásadní problém - nemůžeme nechráněným protokolem vyzradit identifikátor session (a naopak nesmíme akceptovat session, která vznikla přes protokol HTTP). Má tedy tato situace řešení, nebo nemá, jak se dočteme v řadě publikací?

Jistě jste také už mnohokrát, stejně jako já, řešili problém, jak spolehlivě automaticky otestovat, že vaše aplikace správně odeslala email s konkrétním obsahem na konkrétní emailovou adresu. Problém je to zapeklitý a dosud jsem ho dokázal řešit jen těmito způsoby:

• udáním testovací schránky a automatickým výběrem této schránky (např. přes protokol POP3)
• vytvořením mock objektu, který mi zastoupil třídu starající se o odeslání emailu (tzn. k žádnému emailu fyzicky v testu nedošlo)

Oba dva přístupy mají svá úskalí. Ten první velmi komplikuje běh testu - musíme naprogramovat další funkcionalitu, která nám vybere emaily jiným protokolem, musíme řešit možnost, že se email někde pozdrží, musíme fyzicky nějakou schránku mít, musíme vyřešit to, jak při opakovaném spouštění testů rozeznáme, že do schránky přišel právě ten mail, na kterém v testu čekáme. Fakticky se potom často stane, že v testu samotném je víc chyb, jak v tom jednoduchém kódu, který se snažíme otestovat.

V projektu, na kterém v současné době pracuji, bylo navrženo poměrně extenzivní použití AJAXových funkcí. Proto jsem se, coby AJAXem dosud netknutý vývojář, vrhnul do studia knihoven, které by mi realizaci usnadnily. Výsledkem mi bylo zjištění, které uvádím v titulku příspěvku - není AJAX jako AJAX. Každá z knihoven tento problém řeší velmi odlišně - a přestože mé první kroky vedly k GWT, brzy jsem tento záměr opustil.

Jelikož pracuji ve společnosti, která své krédo staví na velmi propracovaných webech - co se týká použitelnosti, přístupnosti, validity a grafickém vzhledu (o tuhle stránku věci se naštěstí nestarám já ;)) - bylo nutné zajistit, aby stejná funkcionalita byla přístupná s AJAXem i bez něj. Mým prvotním záměrem tedy bylo: