Způsoby konfigurace Springu

Když se mluví o Springu, tak to má hned každý spojený s tím, že se vše konfiguruje pomocí XML. Pravděpodobně je to kvůli tomu, že opravdu v minulosti (do verze 2.0) nebyla jiná schopná možnost konfigurace, ale to již dneska v žádném případě neplatí.

Jakými způsoby můžeme tedy konfigurovat springovské aplikace?

XML

Vždy aspoň trochu té konfigurace v XML budeme potřebovat, minimálně říci, že budeme konfigurovat např. pomocí anotací. Já osobně mám konfiguraci v XML celkem rád, protože vše mám vytažené na jedno místo, hned vidím všechny ty možné závislosti. V porovnání s anotacemi nemusím skákat mezi třídami a zjišťovat, jak je to vše vlastně propojené. To má podle mě také výhodu s ohledem na úpravu konfigurace. Na druhou stranu musím uznat, že někdy je to "až moc upovídané" - to se částečně zlepšilo s nástupem namespaců. Nejvíce mi to přijde upovídané ve webové vrstvě okolo kontrolerů, tak jsem tuto část aplikace začal konfigurovat pomocí anotací.

Anotace

Od druhé verze Springu je možné používat anotace. Anotace jsou v poslední době "sexy", takže tento styl se bude využívat asi hodně často. Spring se také snaží držet hesla "convention over configuration", což ve spojení s anotacemi vytváří velice rychlý a efektivní způsob konfigurace. Jak už jsem zmiňoval, velice se mi toto osvědčuje pro webovou vrstvu aplikace.

Java konfigurace

Tento způsob konfigurace není standardní součástí Spring frameworku, ale je vyvíjen bokem jako Spring Java Configuration Project. Tento způsob bych asi použil tehdy, když bych potřeboval mít dynamicky měnící se konfiguraci, tj. za běhu např. měnit nastavení parametrů připojení k databázi. Výhodou určitě také je to, že vše je v Javě - máme doplňování kódu, kontroly syntaxe a všeho možného, refaktoring.
Zdá se mi ale, že tento projekt se nějak zastavil. Pamatuji si na několik přednášek na konferenci SpringOne v červnu minulého roku, kde toto prezentovali jako novinku a zajímavou možnost do budoucna. Je o devět měsíců později a projekt je pořád ve stejném stavu. Myslím si, že přeci těch způsobů konfigurace je celkem dost a že malinkato se to překrývá s projektem Spring dynamic modules.

Properties

Hned na začátku říkám, že nemám na mysli využití PropertyPlaceholderConfigurer, ale PropertiesBeanDefinitionReader . Jedná se tedy o způsob konfigurace pomocí properties souborů.
Tento způsob konfigurace je ve Springu už asi jen z historických důvodů, na nových projektech tento způsob už asi nikdo nepoužije.


Na závěr bych dodal, že jednotlivé způsoby konfigurace lze libovolně křížit, pro určitou část můžeme použít anotace, pro jinou XML apod.
Volba způsobu konfigurace závisí na každém z nás, každý preferuje jiný způsob. Proto mi přijde celkem nefér, že se často vytýká Springu jeho upovídanost, protože je to každého věc a pokud budu chtít, tak té konfigurace bude opravdu minimum.

Články k příspěvku:
More on Java Configuration
Spring Java Configuration Moving Ahead

Bezpečnostní problémy webových aplikací

Již před pár lety naše firma vytvořila aplikaci pro administraci LDAP adresáře jedné nejmenované pojišťovny. Nyní si pojišťovna nechala udělat bezpečnostní audit - nejen na naší aplikaci, ale obecně na celé své řešení spojené s adresářovými službami.
Některé připomínky mě více či méně překvapily, posuďte sami (jen pro přesnost musím uvést, že s většinou uvedených problémů naše aplikace neměla problémy):

• problém jménem Cross-site scripting (2) (XSS). Tento způsob podvržení není asi dobré podceňovat, protože možnosti útoků jsou skoro nekonečné. Jako vhodné řešení (poměr námaha vs. úspěšnost) se mi jeví převádět všechny podezřelé položky (takže vlastně všechny) na HTML entity. Zde nestačí pouze kontrolovat resp. převádět položky zadané uživatelem, ale ideálně i položky z LDAPu nebo databáze.


• CRLF injection, SQL injection


• správa sessions - po každém přihlášení by se měla zrušit stávající session (která byla vytvořena v moment přístupu k aplikaci) a vytvořit nová session. Po odhlášení vždy session zneplatnit.


• ošetření chybových stavů - chybová hlášení by neměla být natolik detailní, aby z nich bylo možné vyčíst údaje vhodné pro další typy útoků. Např. neuvádět detailní popis služby, která spadla, neuvádět jména a verze komponent, kde nastal problém apod.


• slabá hesla - auditor zkoušel namátkou odhadnout hesla uživatelů a zjistil, že 364 uživatelů má heslo "12345678", 12 uživatelů pak "87654321"!

Co (mi) přinesl letošní rok?

Je závěr roku a kdekdo se snaží shrnout, co se NEJ stalo v tomto roce. Já budu také jeden z nich, ale můj pohled bude malinkato jiný - rád bych uvedl věci, které mě jako programátora resp. architekta tento rok nejvíce pomohli v mé každodenní práci. Nebude to přehled nějakých významných objevů či událostí, které se v tomto roce ve světě Javy staly, ale spíše věci, které mi pomohly a pomáhají lépe a rychleji vytvářet aplikace, nebo které mě nějakým způsobem v mé práci ovlivnily.

Rozšiřování Spring portfólia

Já mám rád Spring, já ho rád používám a jsem plně ztotožněn s filosofií, která stála u zrodu Springu, a která platí až doposud. Proto tak oceňuji, že Spring resp. Spring portfólio se rozšiřuje o nové projekty, že čím dále více projektů třetích stran nabízí přímou a snadnou Spring-integraci, že Spring používá čím dál více lidí a tím pádem se objevuje více informací na internetu a více příspěvků v diskuzích.

Zvýšení povědomí o Springu

Tento bod velice souvisí s předchozím bodem, ale je o trochu něčem jiném. Je o tom, že Spring již dneska není považován za nějaký dočasný open-source projektík, ale za vyspělé propracované řešení, které se nebojí využívat ani velcí hráči jako jsou banky, pojišťovny, vládní instituce apod. To je v konečném důsledku super hlavně pro nás vývojáře, že můžeme jít s dobou a nemusíme pořád i dnes vyvíjet v prostředí Javy 1.3 nebo Struts.

Vyspělejší prezentační technologie

Myslím si, že Java oproti jiným jazykům (hlavně C#) nejvíce ztrácí v efektivitě vytváření "ksichtu" aplikací. Je sice hezké mít super robustní jádro aplikace, ale pokud uživatel neuvidí pěknou, moderní, uživatelsky přívětivou aplikaci, tak moc spokojený nebude. Proto jsem rád, že vznikl Seam, který ukázal v tomto ohledu zajímavý způsob řešení, že nastal posun v JSF specifikaci, že vzniká čím dál více použitelných AJAXových frameworků.

J2EE 6

Dle článků na internetu se dá tušit, že specifikace J2EE verze 6 se vyvíjí tím správným směrem. Uvidíme, jak to nakonec ale dopadne - jaké dílčí specifikace budou součástí finální J2EE specifikace, jak moc se podaří prosadit lidem okolo Springu jejich představy.

Nedostatek pracovních sil

Sice tento bod přímo nesouvisí s tím, jak každý den řeším programátorské problémy, ale nepřímo to celkem mojí práci ovlivňuje. Na jedné straně tím, že se nemusím bát o svoji práci, že si mohu vybírat a částečně určovat podmínky já sám. Na druhé straně jako nevýhodu vidím v tom, že máme problémy sehnat nové kolegy (schválně jsem vynechal slovíčko kvalitní, protože to je dneska spíše nedostižný ideál) a tedy spoustu věcí třeba ani řešit nemůžeme.

Skriptovací jazyky v Javě - co s nimi?

Tento článek jsem nezačal psát jako jiné články s tím, že bych rád něco sdělil, ale spíše, že bych se rád něco dozvěděl. Před chvílí jsem dočetl článek o skriptovacích jazycích v Javě a pořád si nějak nemohu správně odpovědět na otázku - K čemu mi jsou v Javě ty skriptovací jazyky vlastně dobrý?

Musím se přiznat, že obecně skriptovací jazyky neovládám a spíše jen pasivně sleduji dění okolo, něco hodně málo jsem napsal v Groovy. Když si čtu články o skriptovacích jazycích v Javě, tak se často objevují tyto výhody vzájemného propojení:

• skriptovací jazyky jsou jednodušší, lehčí, názornější, intuitivnější. To je z velké části dáno tím, že se jedná většinou o jazyky dynamické a slabě typované (obecně řečeno, protože např. Python je typově silný jazyk).


• Java nabízí celou řadu věcí, které nejsou dostupné v samostatných skriptovacích jazycích, např. transakční management nebo vzdálená volání. Kromě toho lze pomocí Javy využít obrovské množství knihoven třetích stran, které lze ve skriptech využít.


• výběr skriptovacích jazyků pro Javu je dneska opravdu veliký


• díky spojení s Javou se neztrácejí hlavní přednosti Javy - možnost vytváření velkých, robustních a škálovatelných aplikací.

Kromě výhod to má samozřejmě i nějaké nevýhody:

• často se uvádí slabší výkonnost skriptovacího enginu s JVM oproti nativnímu enginu samotnému. Je to dáno tím, že je potřeba provádět řadu kontrol a konverzí mezi oběma světy. Toto např. neplatí úplně pro Groovy, což je jen taková jiná Java.


• skripty napsané s pomocí JVM samozřejmě pak nelze spouštět v nativním enginu


• někdy jsou světy Javy a skriptovacího jazyka natolik rozdílné, že to nelze v některých jazycích vůbec implementovat nebo za cenu ne úplně ideálního kódu. Myslím například anotace v Javě.


• větší nároky spojené s údržbou aplikací. Dříve stačilo umět jen Javu, ale teď k tomu potřebuji znát ještě minimálně další jazyk.


• podpora přímo na úrovni JVM od verze 6 - JSR 223

Takže k čemu já to jen využiji? I když si dokážu představit, že určité části aplikace napíši rychleji např. pomocí Groovy, tak jsem asi moc konzervativní, ale mě to zase taková výhoda nepřijde. Já mám svoji Javu rád :), takže si všechno napíšu v ní. Když to nebudu brát jen z mého osobního pohledu, tak přeci jen otázka údržby aplikace je hodně významná a s použitím více jazyků a technologií se tento problém stává těžší a komplikovanější (a tedy nákladnější). A když už budu psát část aplikace pomocí skriptovacích jazyků, tak proč už to pak nenapíšu celé jen pomocí skriptovacího jazyka?

Často se uvádí jako vhodné využití prototypování aplikací. Zde si to dovedu celkem představit jako přínosné, ale moje zkušenost mi říká, že spousta takto vytvořených prototypů se použije pro následný vývoj celé aplikace. Raději bych to tedy od začátku psal pořádně v Javě.

Můj osobní stav je nyní takový, že pořád moc nevím, kde a jak bych mohl efektivně využít skriptovací jazyky z pohledu vývoje v Javě. Budu moc rád, když přispějete formou diskuse a vysvětlíte mi, že se v určitých ohledech pletu nebo jsem jen špatně resp. málo informovaný.

Novinky ze Springu

Moc často nekomentuji různé události, ale teď mi to nedá. Právě se koná konference The Spring Experience, což jsou spolu s konferencí SpringOne dvě nejvýznamnější konference věnované přímo Springu.
Právě na této konferenci se objevily velice zajímavé novinky z dílny firmy SpringSource (dříve Interface21):

• doplnění Spring portfólia o Spring Integration, o část, která by měla pomoci při vývoji servisně-orientovaných aplikací. Podle mého názoru je dneska skoro nezbytností mít něco podobného v portfóliu, v době, kdy se každý ohání slovíčkami jako SOA, webové služby, integrace apod. V brzké době by projekt měl být publikován a někdy ve druhém čtvrtletí roku 2008 by měla být verze 1.0. Více si můžete přečíst na Team blogu SpringSourcu.


• SpringSource Application Management Suite - podle dostupných informací, které se mi podařilo najít, by to měla být taková nádstavba nad Springem, která bude zobrazovat běhové informace o aplikaci jako např. kolik proběhlo transakcí, kolik zpráv se zpracovalo, kolik aktivních beanů je v aplikaci apod. Já osobně to chápu tak, že místo abychom museli vytvářet MBeany pro přístup k velmi často potřebných informacím, tak budeme moci použít tento Application Management Suite, který nám bude automaticky nabízet standardní sestavu pro každou aplikaci.


• SpringSource Certification Program - toto je velice zajímá informace, o které se již tak trochu mluvilo na konferenci SpringOne v letošním roce. Na certifikace jsou různé názory, ale určitě lze říci, že je to krok správným směrem, pokud chceme aby se Spring čím dál více prosazoval a používal mezi velkými hráči jako jsou například banky. Je ale otázka, kdy se to dostane až k nám do Čech - v USA to začne na konci ledna.

Více si můžete přečíst v tomto článku.