Myšlenky dne otce Fura

Je tomu už drahně let, co jsem používal k populaci JavaBean Commons-BeanUtils z rodiny Apache Jakarta. Od chvíle, kdy stavím svoje aplikace nad Springem, pozbývá používání této knihovny smysl - naopak bylo by bláhové se této knihovny držet, když Spring nabízí již ve svém základu mnohem víc. Prostým logickým úsudkem lze odvodit, že Spring coby IoC kontejner bude obsahovat promyšlenou logiku pro injektování dat do Java Bean. Nicméně v dokumentaci o tom najdete jen poměrně krátkou kapitolu Validation. Proto jsem se rozhodl vyextrahovat ze svého kódu pár příkladů, které standardní Spring dokumentaci trochu rozvádí do podrobností.

(pokračování …)

Tento týden jsem řešil problém s nedostatkem paměti při spouštění testů jednoho projektu. Pro běh testů nestačilo výchozích 64MB paměti Javy na heapu, což mi připadlo v porovnání s velikostí projektu podezřelé. Začal jsem profilovat a jelikož mne výsledky poněkud překvapily, chci se s Vámi o ně v tomto článku podělit.

Hned na úvod řeknu, že jádrem problému byla třída AspectJExpressionPointcut. Tato třída je ve Spring dokumentaci zmiňována hned několikrát, velmi jednoduše se používá a ze všech dostupných materiálů jsem dospěl k názoru, že se jedná o doporučovaný a běžně používaný standard.

(pokračová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.

(pokračování …)

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.

(pokračování …)

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.

(pokračování …)

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.

(pokračování …)

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

(pokračování …)

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 .

(pokračování …)

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

Hlavní problém integračních testů, u kterých máte ve spodu relační databázi je rychlost. Každý test spoléhá na nějaká data v DB - ty mohou být (a jsou) ostatními testy poškozena a proto je nedílnou částí všech testů setUp / tearDown operace, která se o tuto přípravu a uklizení stará. Jelikož jsou programátoři cháska líná a nechtějí se zabývat přípravou pouze minimální potřebné sady pro každý test, obvykle si vytvoří nějakého předka, který obsahuje setUp a tearDown, pro všechny testy najednou. Tím pádem se vždycky inicializuje kompletní sada dat a to si bere významné množství času. Odhadoval bych, že 80% času testů se stráví v této přípravě dat a pouze 20% času běží skutečné testy.

(pokračování …)

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.

Výchozí implementace distribuce / zpracování eventů je velmi jednoduchá a také postačuje ve valné většině případů. Jedná se o synchronní zpracování vyslaných událostí. Tzn. okamžitě, jakmile přes Publisher zveřejníte událost, jsou notifikování všichni zaregistrovaní listeneři, kteří událost opět okamžitě ve stejném Threadu zpracují - a operace pokračuje dál, až všichni se svou činností skončí. Někdy se ovšem hodí, když se mohou vybrané události zpracovat asynchronně - nezávisle na threadu, který událost vyvolal.

Situace, kdy bychom mohli chtít oddělit zpracování událostí do jiného threadu, jsou mají společné tyto základní vlastnosti:

• nejsou blokující pro poskytnutí odezvy uživateli (tzn. operace je pouze vedlejším produktem operace, kterou uživatel vykonal)
• náklady na její zpracování jsou větší než nepatrné - tzn. zpracováním události v jiném vlákně urychlíme odezvu uživateli
• o případné selhání této operace nemusí být uživatel nutně informován

Otázka zní, jak tohoto docílit …

(pokračování …)