Myšlenky dne otce Fura

Testing transactional aspect of your application is not easy as we usually use Springs’ transaction rollback on tear down testing approach. Though there are solutions to test aspect oriented logic it’s not without a price. More than that – we very much got used relying on easy-to-use Spring @Transaction annotation so that we don’t usually take an effort to do it. There is a few standard Spring rules for rollbacking transaction in relation to method resolution:

• transaction is automatically rollbacked only on unchecked exeption (RuntimeException)
• rollback will also occur for exception types specified in rollback-for attribute of the annotation or XML element
• rollback will not occur for exception types specified in no-rollback-for attribute of the annotation or XML element
• transaction demarcation will aplly only to the external calls of the bean method (consider use-case when external logic calls a public method on your bean, that is not annotated with @Transactionaidl and this method will call in its body another public method of the same class that has @Transaction annotation – in such case Spring will not start and manage transaction)

But there is yet another one – your @Transactional annotation must be resolved by Spring bean post processing logic in the first place. Usually it is, but when using CgLib based proxies (proxy-target-class) there is a catch which will cause omitting @Transactional annotation on your method declaration.

(more…)

Tušil jsem, že to je jednoduché, ale že to je AŽ tak jednoduché, to jsem nevěděl. Dokončujeme projekt pro jednu velkou českou banku a potřebovali jsme mít podrobným logováním pokrytou co největší část aplikace pro případ, že by se vyskytly problémy na prostředí, do kterého, z bezpečnostních důvodů, nemáme a nikdy nebudeme mít přístup.

Jako principiální odpůrce manuální práce jsem ihned zavrhnul myšlenku na manuální procházení kódu a rutinní vkládání debug logování pro strýčka příhodu (krom složitějších metod, kde je to nezbytně nutné).

Další má myšlenka samozřejmě směřovala k AOP. Už jsem si napsal kostru vlastní advice a chystal se psát aspekt, když …

(more…)

Dnes se mi podařilo vychytat velmi dobré přednášky, takže jsem si po včerejším dm Serveru rozhodně spravil chuť. První dnešní přednášky se týkala Groovy a především novinek ve verzi 1.6. Zprvu se zdálo, že Guillame pojede pouze po povrchu Groovy, ale brzy se přednáška rozjela, takže si z ní člověk nakonec odnesl opravdu hodně. Přednáška stavěla na publikovaném článku o Grovy 1.6 na InfoQ. Groovy by ve verzi 1.6 mělo být výrazně rychlejší (různé micro benchmarky ukazují zlepšení výkonnosti od 150% do 430%), díky hotspotu dle Guillama dokonce předběhnou některé jiné dynamické jazyky mimo JVM platformu (konkrétně zmiňoval Ruby). Groovy běží bez problémů na GAP – dokonce je tam k vyzkoušení volně dostupná Groovy konzole. Rozvoj Groovy jede raketovou rychlostí, řekl bych že věci, které tam jsou, v Javě neuvidíme ještě léta a kdo ví jestli vůbec (closures, tuples, properties, statická inicializace properties v rámci konstruktoru). Jediné co nám brání dosud ve firmě nasadit Groovy, je zajištění aby groovy instance vytvořené Springem a naše vlastní instance nad společným Groovy classoaderem sdílely podobné rekompilační chování jako nabízí GroovyScriptingEngine. Groovy je ale rozhodně směr, kterým se chceme ubírat.

(more…)

Dnešní den přenesl (alespoň v mém případě) řadu roztrpčení. K tomu se ale dostanu až o pár odstavců později. Dnešní keynote se nesla v duchu Lean software development – a to především ve smyslu, jak se co nejrychleji dostat z fáze vývoje do fáze produkčního běhu. Přednáška byla poměrně zajímavá – Adrian Colyer ukazoval prostřednictvím STS živý deployment Spring / Grails aplikací (byť) triviálních přímo na Google App Engine nebo na Amazon EC2. Ačkoliv pro to zatím nemám usecase, praktická ukázka byla skutečně impresivní. Adrian je především skvělý přednášející, který je schopný živě reagovat na odezvu publika a vkládat skutečně zajímavé oživující prvky, které udrží dobrou náladu a pozornost posluchačů (jako třeba bílý tučnák, kterého v průběhu přednášky trestal za jakoukoliv chybu, která se mu ukázkách povedla). Kéž bych uměl své přednášky udělat tak zajímavé jako on . To co jsem si z přednášky odnesl je to, že nasadit Spring aplikaci na GAE nebo EC2 nemusí být zase tak těžké, jak by se na první pohled mohlo zdát.

(more…)

Dnes začala v Amsterodamu konference Spring One zaměřená na technologie okolo Spring Frameworku (Spring samotný, Spring MVC, Spring WebFlow, Grails, Spring Batch, Spring Security, Spring tc a dm Server atd.). Konference se koná v hotelu Krasnopolski v úplném centru Amsterodamu. My jsme přijeli o den dříve, abychom si město stihli v klidu prohlédnout a projít si zajímavá místa (Red light district apod. ). Nějaké fotografie si můžete prohlédnout zde. Kromě všudy přítomných coffee shopů mě zarazilo především to, že holanďané si vůbec nepotrpí na soukromí a ve velkých oknech řada domů nemá ani záclony, takže je jim běžně vidět téměř až do postele. Druhá věc, která vás na Amsterodamu zarazí, je neuvěřitelné množství kol – ty jsou tu daleko běžnějším dopravním prostředkem než třeba automobil. Průměrné stáří kol, je ovšem (soudě dle vzhledu) snad 20 let – jelikož jsou tu běžná kola podobná tomu, o kterém se v naší rodině traduje, že je předválečné. Zdá se, že tu holanďané soutěží o ošklivější kolo s největším zámkem, což mě přivádí k myšlence, že se tu musí kola poměrně dost “ztrácet”.

Původně jsem ale chtěl psát především o konferenci a proto se k tomuto tématu zase vrátím…

(more…)

Dynamic proxies can be very nasty if you don’t know what happening under the cover. Last week I was searching for the memory leak that caused our application to crash. Even though Tomcat had assigned 1GB memory for heap and 0,5GB for PermGenSpace it stood alive for only approximately twelve hours. It’s pretty nasty situation having known that application is only in betatesting with relatively low traffic.

When analyzing generated heap dump I have found, that memory leak was caused by web application classloader, that managed thousands of CgLib dynamically generated classes. I was using Eclipse Memory Analyzer, that’s probably the best tool for memory heap dump analysis I have ever seen. It’s the third time it quickly identified the suspicious classes, by heuristic analysis called Leak suspect.

(more…)

Tento článek mám ve WordPressu rozepsaný snad už rok. Jeho původní název zněl “ResourceBundle – stačí Javě beze změny?”. Plno věcí, které jsme původně jako Java vývojáři dělali my, postupně uzpůsobujeme tak, aby je mohli dělat web designeři. Na prezentační vrstvu zcela jistě patří lokalizované texty a zprávy, pro které standardně používáme ResourceBundly Javy, které se načítají z property souborů. Ideální model pro web developery je iterace: navrhnu stránku, vložím text do property bundlu, uložím, reloadnu stránku a kouknu jak to vypadá. V tomhle jednoduchém scénáři jsme však narazili hned na několik problémů.

Standardní PropertyResourceBundle se obvykle získává takto (to je mmch. cesta zmíněná v dokumentaci ResourceBundle):

Takto načítaný property soubor (“MyResources.properties”) musíme mít na classpath (kde samozřejmě není editovatelný) a musíme jej mít ve Ascii formátu zkonvertovaný utilitou Native2Ascii. Dalším problémem je sekvence, ve které se hledají konkrétní lokalizované varianty bundlu. Díky tomu, že Java původně vznikla hlavně pro desktopové aplikace se do posloupnost hledání bundlů dostává i bundle pro systémové locale stroje, na kterém aplikaci spouštíme. V případě volání metody getBundle s Locale(“cs”,”CZ”) se na anglickém Ubuntu hledá property bundle v této posloupnosti:

1. messages_cs_CZ.properties
2. messages_cs.properties
3. messages_en_US.properties
4. messages_en.properties
5. messages.properties

Tuto věc jsem ještě před rokem nevěděl, a to možná také proto, že není nijak zmíněná v dokumentaci Javy.

Tak se nám těch problémů nakonec sešlo docela dost – na to, že řešíme takovou hloupost jako je lokalizace – že?

(more…)

Nice thing about Aspect Oriented Programming is that you can easily add piece of logic to several (possibly other way not connected) parts of your application. You’ll only write an Advice (piece of code that should be weaved into original code and executed at exactly specified point of time) and define Pointcut (an expression defining which classes and methods shall be advised). Please, keep in mind, that above description is somewhat simplyfying and that AOP could be much broader than this. Describing AOP is not the aim of this post – the aim lies in something else, and that is – testing. What’s the best approach to test application logic modified in runtime (or compile time) with AOP process?

(more…)

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

(more…)

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.

(more…)