AspectWorks » Java

DB žurnál pomocí Hibernate interceptoru

Jan Pacek — Tue, 10 Apr 2012 07:33:34 +0000

Na mnoha projektech je třeba řešit databázový žurnál aplikace, který zaznamenává události v systému včetně dat, která při těchto událostech byla změněna či jen čtena. Zákazníci často požadují u událostí, které mění data, žurnálovat jak staré tak i nové hodnoty záznamu.

Implementace takového mechanismu přímo na DAO vrstvě by byla pracná a hlavně složitě konfigurovatelná. Řešení žurnálování na úrovni databázových procedur a triggerů by zase zrušilo nezávislost aplikace na konkrétním typu databáze. Hibernate pro žurnálování nabízí zajímavou funkčnost interceptor pro zachycení a zpracování různých událostí, jako například databázové CRUD operace.

Vycházím z příkladu použití interceptoru na audit log (žurnál) a samozřejmě ze samotné dokumentace http://docs.jboss.org/hibernate/core/3.3/reference/en/html/events.html

Po menší modifikaci lze uvedený příklad použít i na žurnálování starých a nových hodnot. Vytvořímě si entitu AuditLogData pro ukládání změněných hodnot a přidáme ji do entity AuditLog.

@Entity @Table(name = "auditlog", catalog = "mkyong")
public class AuditLog implements java.io.Serializable {
private Long auditLogId;
private String action;
private String detail;
private Date createdDate;
private Long entityId;
private String entityName;
@OneToMany() @JoinColumn (name = "auditLogId") @OrderBy("propertyName")
privateList auditLogData;
...
}

@Entity @Table(name = "auditlogdata", catalog = "mkyong")
public class AuditLogData implements java.io.Serializable {
private Long auditLogDataId;
private String propertyName;
private String oldValue;
private String newValue;
...
}

Při ukládání záznamu budeme pracovat přímo se záznamem AuditLog třídy a ne pouze s entity.

public boolean onFlushDirty(Object entity,Serializable id,
                Object[] currentState,Object[] previousState,
                String[] propertyNames,Type[] types)
                throws CallbackException {
                ...
   if (entity instanceof IAuditLog){
       AuditLog auditRecord = new AuditLog("Updated“,entity.getLogDeatil(), new Date(),entity.getId(), entity.getClass().toString());
       fillChangedData(auditRecord, previousState,  currentState, propertyNames, entity);
	 //Add the auditLog to be saved as update after commit of transaction
       updates.add(auditRecord);
   }
   return false;
}

Kde plnění změněných dat by mohlo vypadat přibližně následovně:

private void fillChangedData(AuditLog auditLog, Object[] startState, Object[] endState, String[] propertyNames, Object newObject, Long persistedObjectId)
           throws IllegalArgumentException, IllegalAccessException, InvocationTargetException {
        //check input parameters
        …
        for (int i = 0; i < propertyNames.length; i++) {
            //check if the property has been changed
            if (propertyValueChanged(startState[i], endState[i])) {
                // property changed, add it to auditLog.auditLogData list
                final String pn = propertyNames[i];
                String valueOld = propertyValueToString(startState[i]);
                String valueNew = propertyValueToString(endState[i]);
                addDataToAuditLog(auditLog, pn, valueOld, valueNew);
            }
        }
    }

Jak je na příkladu vidět, Hibernate interceptor je mohutný nástroj, který umožňuje na aplikační úrovni nejen odchytávat operace nad databází, ale i dále zpracovávat jejich data.

Quartz Scheduler a dynamické plánování úloh

Jan Bumbala — Tue, 27 Mar 2012 09:24:13 +0000

Na zákaznickém projektu bylo potřeba umožnit asynchronní spouštění různých handlerů, registrovaných jako Spring bean. Typicky jde o případ, kdy uživatel iniciuje vykonání nějaké činnosti, která může trvat desítky sekund nebo dokonce minut. Zároveň jsme potřebovali, aby řešení bylo persistentní, a tedy aby se naplánované úlohy neztrácely při pádu serveru.
Protože jsme již na projektu využívali Quartz Scheduler pro spouštění pravidelných úloh, použili jsme ho i pro účel tohoto asynchronního zpracování.

Scénář použití Quartz Scheduleru, se kterým jsem se nejčastěji setkal, je takový, že v systému jsou předem nakonfigurované joby, které chceme spouštět, a více či méně složité triggery. Každý job je jednoúčelový a spouští předem definovanou business logiku. Pokud chceme umožnit vyvolávat nějaký nový handler, je potřeba přidat a nakonfigurovat nový Quartz job.

Zde popisované řešení je trochu jiné v tom, že je definované obecné API pro naplánování asynchronního zpracování. Motivací bylo umožnit asynchronní procesing handleru bez nutnosti statické konfigurace Quartz jobu pro každý takový handler. Pro každou naplánovanou úlohu je použit společný Quartz job, který v okamžiku vyvolání vyhledá požadovaný handler ve Spring contextu a spustí jej. Přidání nového handleru, nového typu úlohy kterou chceme asynchronně spouštet, pak nevyžaduje žádné další konfigurační změny Quartz scheduleru, pouze konfiguraci nového beanu ve Spring kontextu.

Pro vyvolání metody na Spring beanu již existuje MethodInvokingJobDetailFactoryBean, jenže tento způsob neumožňuje předat metodě parametry. Navíc i zde je potřeba mít pro každý bean nakonfigurovaný vlastní trigger. V našem scénáři nechceme pro každý springový bean definovat nový trigger, pouze definujeme a nakonfigurujeme univerzální scheduler vrstvu. Popsané řešení je sice závislé na Springu, nicméně klientský kód je oddělený interfacem, takže není až takový problém vytvořit implementaci, která Spring používat nebude.

Implementace

Celý mechanismus je skrytý za API, které tvoří 2 třídy:
-SchedulerDAO – určeno pro přístup z business logiky, pomocí tohoto interfacu se naplánuje asynchronní zpracování
-Task – rozhraní, které musí naimplementovat handler, který chceme asynchronně spouštět

public interface SchedulerDAO {
    /**
     * Schedule task for asynchronous processing.
     * @param taskClass task that is about to be executed asynchronously
     * @param properties data to be passed to the task
     */
     void schedule(Class taskClass, Properties properties);
}

public interface Task {
    /**
	 * run scheduled action
	 * @param properties data the task was scheduled with
	 */
	void run(Properties properties);
}

Jednoduchá implementace SchedulerDAO může vypadat takto:

public class SimpleSchedulerDAO implements SchedulerDAO {
	//...instance variables omitted..
    public SimpleSchedulerDAO(Scheduler scheduler, String jobName, String jobGroup, String classNameProperty) {
        this.scheduler = scheduler;
        this.jobName = jobName;
        this.jobGroup = jobGroup;
        this.classNameProperty = classNameProperty;
    }
    public  void schedule(Class taskClass, Properties properties) {
        JobDataMap jobDataMap = new JobDataMap(properties);
        //todo validation that classNameProperty not present in passed properties
        jobDataMap.put(classNameProperty, taskClass.getName());
        try {
            scheduler.triggerJob(jobName, jobGroup, jobDataMap);
        } catch (SchedulerException e) {
            throw new RuntimeException(e);
        }
    }
}

Navržená implementace naplánuje jeden univerzální job, společný pro všechny Task implementace. Pokaždé je vytvořen nový trigger, který je okamžitě naplánován ke spuštění. Složitější implementace může např. získávat instanci triggeru pomocí trigger factory, kde bude vyřešena různá konfigurace triggeru pro různé typy handlerů.
Důležité je, že do persistentních dat daného triggeru (jobDataMap) se uloží název třídy/interface, který chceme asynchronně spustit. Tj. název třídy, která byla jako parametr předána metodě schedule(..). V okamžiku, kdy Quartz vyvolá takto vytvořený trigger, se podle uloženého názvu třídy vyhledá Springový bean, který chceme zavolat (viz dále). Třída jobu je konfigurovatelná, stejně jako název skupiny a klíč, pod kterým je uložený persistovaný název třídy.

Ukázková konfigurace Spring contextu:

V konfiguraci je vidět název třídy společného Quartz jobu – TaskExecutorJob, který je spouštěn všemi triggery. Job se chová tak, že podle názvu interface uloženého v persistentních datech triggeru nalezne Springový bean, a na něm spustí metodu run(). Za zmínku stojí ještě čtvrtý parametr konstruktoru SimpleSchedulerDAO, jedná se o název klíče, pod kterým bude v persistentních datech triggeru uložen název třídy Spring beanu, zde tedy hodnota "@className". V implementaci SimpleSchedulerDAO je vhodné dodělat kontrolu, že předané properties neobsahují klíč, který by kolidoval s hodnotou classNameProperty, a ještě lépe tuto hodnotu pevně stanovit a zdokumentovat v API.
Na závěr tedy ještě implementace samotného jobu, zde se vyhledá a spustí naplánovaný handler.

public class TaskExecutorJob implements Job{
    private String classNameProperty;
    private ApplicationContext applicationContext;
    public void execute(JobExecutionContext context) throws JobExecutionException {
	    //read class from persisted data
        Class taskClass = readClass(context, classNameProperty);
		//lookup bean instance
        Task task = lookupJobBean(taskClass);
        if (task != null) {
            Properties properties = new Properties();
            properties.putAll(context.getTrigger().getJobDataMap());
            properties.remove(classNameProperty);
			//finally execute the target task
            task.run(properties);
        }
    }
    /**
     * read persisted Task class name from trigger's jobDataMap
     */
    protected  Class readClass(JobExecutionContext context, String beanClassKey) {
        String beanClassName = context.getTrigger().getJobDataMap().getString(beanClassKey);
        try {
            if (beanClassName != null){
                return (Class) Class.forName(beanClassName);
            }
        } catch (ClassNotFoundException e) {
            //log error
        }
        return null;
    }
    /**
     * lookup Task implementation from Spring context
     */
    protected  T lookupJobBean(Class clazz){
        if (clazz != null){
            try {
                return applicationContext.getBean(clazz);
            } catch (BeansException e) {
                //log error
            }
        }
        return null;
    }
}

Možné nevýhody

Existuje zde ovšem také jeden nedostatek. Klientský kód je sice oddělený dvěma rozhraními (Task a SchedulerDAO), nicméně popsané řešení je orientované na Spring framework a toto má jeden dopad: je potřeba, aby handler, který chceme asynchronně spouštět, definoval nové rozhraní rozšiřující interface Task. Například takto:

public interface TestingTask extends Task{
}
public class TestingTaskImpl implements TestingTask {
    public void run(Properties properties) {
      //do something..
    }
}

Nelze definovat přímo implementaci interface Task a tuto se snažit naplánovat přes SchedulerDAO. Jde o to, jak funguje Springový lookup BeanFactory.getBean(Class requiredType): pokud Spring pro AOP používá jdk proxy, nebude možné provést lookup Spring beanu podle jeho implementace, pouze podle interface. Dále je nutné, aby v kontextu byla registrovaná od každého tohoto rozhraní pouze jedna implementace. Popsané řešení by bylo možné změnit např. tak, že scheduling nebude probíhat na základě rozhraní handleru, ale pomocí jména beanu. Toto by ovšem do kódu zaneslo mnohem větší závislosti na Spring frameworku.

Budu rád, pokud se podělíte se svými názory, či jste třeba řesili něco podobného, nebo zda v tom vidíte nějaké problémy.

Ukázkový funkční příklad si můžete stáhnout zde: quartz-example.zip

Eclipse efektivně (4.)

Luboš Račanský — Fri, 24 Feb 2012 10:07:51 +0000

K psaní seriálu Eclipse efektivně nás motivuje pozorování, že někteří (i zkušení) vývojáři nejsou dostatečně efektivní při práci s Eclipse IDE. Možná, že některé tipy, které našim stážistům vtloukáme do hlavy, se budou hodit i vám.

Tentokrát se zaměřím na to, jak získat přehledný výpis chyb. Dále nastavení generování metod equals a hashCode. Nechybí vám, že content assist nenabízí statické importy? Víte, že find dialog dokáže hledat zároveň jak píšete? Nakonec se naučíme kouzlit s řádky.

Problems View

V ideálním případě by měl být workspace bez jakýchkoliv chyb a varování, jenže v praxi se vám dostane pod ruku všelijaký kód. V záplavě chyb pak potřebujete rozeznat, která chyba je ještě „dobrá“. Osobně mám Problems view zapnuté na Group By -> Java Problem Type.

Kdy naposledy jste měli ve workspace otevřený jen jeden projekt? Na přehlednosti nepřidá, když se chyby sesypou na jednu hromadu. Pomůže zapnout Show -> Error/Warnings on Project, což umožní zobrazit chyby pouze z aktuálního projektu.

Checkstyle – Need Braces

Jistě každý blok za if výrazem dáváte do složených závorek. O to víc vás pak musí rozzlobit, že Checkstyle v Sonaru hlásí:

Checkstyle Need Braces (‘if’ construct must use ‘{}’s.)

Příčinou bude s největší pravděpodobností automaticky generovaný kód (kdo by ho kontroloval) metod equals a hashCode. Přitom stačí zaškrtnout volbu Use blocks in ‘if’ statements

Content assist – Import static members

Nevím jak vás, ale mě při psaní testů v Eclipse vytáčelo, že mi ctrl + mezerník (content assist) nenabízí assertXXX. Musíte si ručně nastavit oblíbené statické importy, které má content assist nabízet. Někteří kolegové mají sice proti konstruktu statických importů námitky, ale zdá se mi, že kód je pak méně ukecaný.

Find/Replace

Občas vídám programátory, jak ve Find dialogu napíšou hledaný řetězec, kliknou na tlačítko Find. Následně zjistí, že se přepsali, tak řetězec opraví a opět kliknout na tlačítko. Hrůza! Téměř stále mám zaškrtnutou volbu Incremental, což znamená, že se řetězec vyhledává zároveň jak píšu. Find dialog má ještě jednu šikovnou volbu a to Wrap search, která způsobí, že když hledání dojde na konec stránky, tak pokračuje opět od začátku.

Kouzla s řádky

Někdy se mi zdá, že se programátoři chtějí klávesovými zkratkami ctrl + C, ctrl + X a ctrl + V uklikat k smrti. Za domácí úkol doučit.

Duplikovat řádek: ctrl + alt + šipka nahoru/dolů
Posunout řádek: alt + šipka nahoru/dolů
Smazat řádek: ctrl + D

Závěr

Věřím, že pokud jste výše zmíněné postupy neznali, tak si je rychle oblíbíte. Mohly by vás zajímat i předchozí díly seriálu Eclipse efektivně.

Od Sysdeo v Eclipse k tc Serveru v STS

Luboš Račanský — Tue, 07 Feb 2012 08:53:37 +0000

Při vývoji webových aplikací používáme Eclipse IDE. Z workspace dostáváme Maven závislosti na Tomcat pomocí pluginu Sysdeo. Toto řešení funguje, ale není ideální. Nastavení aplikace lze ovšem jednoduše upravit tak, aby šla spouštět na tc Serveru přímo z STS (SpringSource Tool Suite).

Proč měnit Sysdeo za tc Server v STS? Kromě toho, že se Sysdeo musíte myslet na ruční spouštění buildu (sysdeo-tomcat:generate), tak je navíc potřeba nahrát do Tomcat lib DevLoader.jar a modifikovat konfiguraci /conf/Catalina/localhost/myApp.xml. To je důvod, proč někteří kolegové přešli na IntelliJ Idea. V neposlední řadě STS přináší, což pro mě je největší lákadlo, profiler Spring Insight.

Nejprve potřebujete zpřístupnit volbu Run As -> Run on Server. Toho docílíte tím, že v nastavením projektu (Properties -> Project Facets) přidáte facet Dynamic Web Modul (vyžaduje Java facet). Jste-li dítětem štěstěny, tak již nyní se vám podaří spustit aplikaci na tc Serveru.

S největší pravděpodobností se ale aplikace nejspíš nebude správně deployovat do /home/user/springsource/vfabric-tc-server-developer-2.6.1.RELEASE/spring-insight-instance/wtpwebapps/myApp (výchozí instalace na Linuxu, uživatel user, aplikace myApp).

Překontrolujte soubor org.eclipse.wst.common.project.facet.core.xml v adresáři .settings

Dále soubor org.eclipse.wst.common.component tamtéž

V souboru .classpath budete mít svoje specifické nastavení, nicméně neměla by tam chybět násludující část.

Nyní můžete aplikaci spouštět na tc Serveru z STS a využívat možností profileru Spring Insight (o tom v některém z dalších příspěvků).

Synchronizace scheduleru v clusteru

Tomáš Holý — Thu, 26 Jan 2012 13:48:48 +0000

Na našem projektu Starthead jsme potřebovali implementovat automatické provádění úkolu určeného ke zpracovávání dat v databázi. Ve frameworku Spring, který je pro vývoj použit, je tato úloha jednoduše řešitelná například pomocí TaskScheduler.
Zajímavější situace nastává, pokud má aplikace bežet v clusterovém řešení. To znamená, že je potřeba řešit synchronizaci, aby nedocházelo k vícenásobnému spouštění jobů ve stejný čas. Snažili jsme se najít co nejjednodužší řešení, které by splňovalo danou podmínku a tím se v našem případě ukázalo využití Quartz scheduleru s patřičnou clusterovou konfigurací a synchronizováním pomocí ukládání do databáze.
Zde je uveden jednoduchý příklad vytvoření takového úkolu a jeho konfigurace ve Spring frameworku.

Implementace jednoduchého jobu

package com.aspectworks;
import org.quartz.JobExecutionContext;
import org.quartz.JobExecutionException;
import org.quartz.StatefulJob;
import org.springframework.scheduling.quartz.QuartzJobBean;
public class TestJob extends QuartzJobBean implements StatefulJob {
	private TestService testService;
	protected void executeInternal(JobExecutionContext context) throws JobExecutionException {
		//implementace úkolu
	}
	public void setTestService(TestService testService) {
		this.testService = testService;
	}
}

Definice triggeru úkolu pomocí Cron definice

Konfigurace scheduleru pro clusterové řešení



	
	
	
	
		
			
		
	
	
		
			TestScheduler
			AUTO
			60000
			org.quartz.impl.jdbcjobstore.JobStoreTX
			org.quartz.impl.jdbcjobstore.StdJDBCDelegate
			QRTZ_
			true
			org.quartz.simpl.SimpleThreadPool
			25
			5

V dané konfiguraci je důležité nastavení atributů obsahujících org.quartz.jobStore a org.quartz.impl.jdbcjobstore. Ty říkají, že úkoly poběží v clusteru, a že se má provést jejich ukládání do tabulek s prefixem QRTZ_. Toto nastavení nám samo zajistí, že po inicializaci se úkol uloží do databáze s příslušnými parametry a ve chvíli vykonávání úkolu smí pouze jeden stroj v clusteru provést jeho spuštění. Právo na vykonání úkolu dostane první z běžících strojů v clusteru, který o to požádá.

Vysvětlení nejdůležitějších atributů:
org.quartz.jobStore.isClustered – definování běhu úkolu v clusteru
org.quartz.scheduler.instanceId – nastavení typu určování id instance (defaultně nastaveno na NON_CLUSTERED)
org.quartz.jobStore.class – definování typu ukládání synchronizace úkolů (v našem případě definuje ukládání do databáze)
org.quartz.jobStore.driverDelegateClass – definování driveru pro ukládání dat do databáze (v našem případě MySQL). Sql soubor pro založení tabulek můžete najít v adresáři doc v konkrétní verzi quartz implementace.
org.quartz.jobStore.tablePrefix – nastavení prefixu Qartz tabulek pro ukládání synchronizace úkolů

Pokud se použije ukládání úkolů do databáze, ukládá se společně s JobDetailem i mapa jeho atributů jobDataAsMap. To znamená, že musí být možné je serializovat a také, že by to neměly být žádné objekty s aplikační logikou. Pokud je potřeba v úkolu využít nějakou service spravovanou Springem, je lepší ji předat do úkolu přes schedulerContextAsMap definovanou v SchedulerFactoryBeanu. Tento způsob uloží objekty do contextu Scheduleru a do úkolů je předá až při jejich inicializování, tedy bez nutnosti ukládání do databáze s ostatnímy atributy.

Více o Quartz schedulerech je možné najít na stránkách http://quartz-scheduler.org/overview

IntelliJ Idea pro vývoj v Javě

Jaroslav Kavalec — Wed, 14 Dec 2011 09:27:14 +0000

Většina lidí si vývoj v Javě spojí s jedním ze dvou nejpoužívanějších IDE – Eclipse a Netbeans. Třetí, donedávna čistě komerční IDE je často neprávem přehlíženo. Před pár dny byla uvolněna nová verze IDE IntelliJ Idea s číslem 11. IntelliJ Idea (dále jen Idea), je vyvíjena firmou Jet Brains, která se zaměřuje na vývoj špičkových vývojových nástrojů pro různé programovací jazyky, mimo jiné IDE pro Ruby, Python nebo Objective C. V článku se budu snažit shrnout věci, které jsem si oblíbil a chybí nebo jsou v horším provedení u konkurence (především Eclipse).

Idea je dodávána ve dvou edicích – Ultimate a Comunity, která je k dispozici zdarma. Comunity edici chybí pluginy na vývoj Java enterprise aplikací postavených na Springu, Hibernate, JPA, EJB, GWT a další a proto se v článku budu zabývat Ultimate edicí.

Enterprise vývoj

Idea má ve své Ultimate edici bohatou sadu pluginů podporujíchích vývoj enterprise aplikací běžících na široké škále aplikačních serverů, využívajících mnoho frameworků. Pojďme si tedy pžiblížit nějaké nástroje, kterí nám dá IDE k dispozici.

Spring a Hibernate

Idea si velmi dobře rozumí se Springem. Dokáže si sestavit model celé aplikace, vygenerovat diagram závislostí jednotlivých beanů, a jednotlive chyby, které se třeba v Eclipse zjistí až v runtime, se projeví okamžitě při psaní chybného kódu. Toto funguje jak s autowiringem, tak se Spring AOP. Dále je k dispozici mnoho dalších pomůcek jako generování kódu, podpora pro snadnou editaci xml konfuguračních souborů nebo snadný import beanů přímo do testů, nebo vygenerování diagramu který přehledně zobrazí závislosti jednotlivých beanů nakonfigurovaných Spring kontejnerem.

Třída je na outline editoru oanotována ikonkou značící, že se jedná o komponentu, při kliku na ikonu je možné se přesunout do konfiguračního xml souboru s deklarací komponenty. Další anotace značí komponenty, které jsou autowirovány Spring kontejnerem do komponenty. U komponenty TwitterServiceImpl byla odebrána anotace @Service, takže není registrována v kontejneru a je na první pohled vidět že něco není v pořádku, jelikož chybí ikona.

Podpora Hibernate a JPA je také na velmi vysoké úrovni. Idea opět sestaví model doménových tříd v aplikaci, dokáže z něj vygenerovat i ER diagram, s modelem jde dále pracovat. Velmi užitečné je, že má Idea podporu pro editaci Hibernate i JPA dotazů přímo v Java kódu, takže se jakákoli chyba v dotazech projevuje okamžitě a také je možné využít autocompletition jak pro jednotlivé entity tak pro různé funkce dotazovacího jazyka.

Properties a lokalizace

Velmi příjemná je práce s lokalizavanými zprávami a properties soubory obecně. Lokalizované zprávy mají speciální editor, v němž se všechny zprávy zobrazí pro editaci současně, v případě že zapomenete překlad tak je položka s chybějícím textem zvýrazněna. Idea dokonce vyznačí varování v případě, že nějakou property nelze najít v property souborech aplikace, takže není nutné čekat než se taková chyba projeví v runtime.

Velmi dobrá věc kterou je možné využít je propisování properties přímo do Java kódu.

Pohled na nastavení IDE - panel s inspekcemi

Vývoj webu

IntelliJ si velmi dobře dokáže poradit s HTML a CSS, a také velmi dobře si rozumí s JavaScriptem a mnoha JS knihovnami. Výborná je například podpora jQuery, různých technologií z rodiny HTML5 či pokročilých možností CSS3 a to včetně vendor prefixů. Pro příznivce CSS pre-procesorů je tu v základu podpora LESS, SASS a SCSS. Dokonce se prodává i samostatná verze, určená jen pro vývoj webu, bez podpory Javy, což svědčí o tom, že tato funkčnost není jen navíc ale, že dokáže stát i sama o sobě. K dispozici je i velmi dobrý JavaScript debugger. Java programátoři jistě ocení pohodlnou práci s JSP stránkami.

Editace textu

Toto je oblast v které Idea vyniká. Idea nabízí mnoho detailů které když se sečtou, tak vytvoří velmi silný nástroj na editaci textu:

- Autocompletition – jedna z důležitých vlastností moderních IDE, Idea má velmi mnoho možností jak doplňovat text i podle částí slov, podle prvních písmen camel-case identifikátorů, a také jsou možnosti nabízeny podle kontextu, v němž se nachází právě editovaný kód, takže většinou je nejvhodnější možnost jako první.

- Navigace – ve větších projektech je určitě důležité se velmi rychle navigovat v textu i mezi soubory. Idea má nepřeberné množství různých metod navigace jako je hledaní souborů, tříd, nebo symbolů. přecházení mezi třídou a testem k ní náležícímu, mezi rozhraními a implementacemi, navigace v hierarchii…

- Oblíbené položky a skupiny oblíbených položek

- Inkrementální výběr textu kdy se s každým výběrem rozšíří vybraný text obecně ve formátu slovo->camelCase->identifikátor->výraz->blok kódu->metoda

- Rozeznání camel case

- Obalení vybraného textu párovým symbolem

- Velmi dobře zpracované šablony na vkládání často používaných výrazů (opravdu značné vylepšení proti Eclipse, podrobnějčí popis je nad rámec článku)

- XML editace – velmi dobře funguje a editování xml už není utrpení (tady srovnávám s Eclipsem), navíc je možné použít různé transformace dokumentu, a využít vylepšenou podporu pro editaci specifických XML jako například Spring konfigurace

- Kontrola slov slovníkem – v praxi velmi užitečná věc, okamžitě se tak odhalí překlepy jak v kódu, tak v komentářích, čímž se předejde zbytečným opravám v budoucnu

- Zalamování řádků, na první pohled nevýznamná ale v praxi velmi užitečná funkčnost, zalamovat je možné jak v editoru tak i v konzoli (konzole nabízí navíc folding a filtrování textu)

- navigace v souborech v kódu – Idea ví o všech souborech v projektu, když se třeba v kódu odkazujete na soubor, který neexistuje tak vás na to upozorní.

Analýza kódu

IDE obsahuje velmi kvalitní nástroj na analýzu kódu – k dispozici je velmi rozsáhlá knihovna inspekcí, které je možno vypnout a zapnout, dle potřeby týmu. IDE pak vyznačí podezřelý kód v outline editoru. Je tak možné být varován před kódem, který povede ke špatnému výkonu, mrtvým kódem, místům, která mají potenciál způsobit NullPointerException a mnoho dalších problémů.

JavaDoc

Idea si velmi dobře vede i v práci s JavaDocem, dokáže generovat kostry JavaDoců, hledat chyby v pravopisu, ale hlavně upozorní na chyby, které vzniknou obvykle když programátor změní kód, ale zapomene provést náležité změny i v JavaDocu. Je to velmi pohodlné, a hlavně kód vypadá mnohem profesionálněji.

Refaktoring a transformace kódu

Idea má k dispozici mnoho různých refaktoringů, které pomohou zvýšit kvalitu kódu, bez zbytečných komplikací.

Velmi zajímavou vlastností jsou tzv Intention actions. Jedná se o akce, které je možné spustit v určitém kontextu, na určitém kódu.

Díky tomu lze například v testech transformovat boolean výrazy do asercí, optimalizovat logické výrazy, nahradit kontrolní struktury za jiné, přesunout inicializátor stojící mimo konstruktor do konstruktoru, uzavřít nejbližší výraz po !if! do závorek a velmi velké množství dalších věcí. Navíc v případě, že je možné na kódu nějakou akci vykonat, tak Idea zobrazí náležitou ikonu.

Vyznačení inspekcí, chyb v JavaDocu, také taby jsou značeny dle toho jedná-li se o test, nový či změněný soubor atd. V pravém panelu je naznačeno použití intention akce.

Verzovací systémy a Maven

Idea má konzistentní systém pro práci s různými verzovacími systémy, takže přecházet například mezi SVN a Gitem není žádný problém.

Změny, které se provádějí jsou strukturovány do change setů, které je možné v případě potřeby schovat (shelve changes). Celkově je práce verzovacími systémy velmi pohodlná a komfortní, velmi dobře je řešeno i mergování souborů s pěkně vyřešenou grafickou navigací.

Velmi pěkně je řešeno načení změn přímo v outline editoru, včetně snadného vyvolání předchozích verzí.

IDE má velmi dobrou podporu Mavenu, rozjet nový projekt z pomu je hračka. Z Maven panelu lze spouštět jednotlivé Maven goals, prohlížet závislosti a pluginy. Je možné jednoduše přepnout spouštění testu toggle tlačítkem.

Groovy – nemám zkušenost, ale kolegové si chváli velmi dobrou podporu Groovy.

Nevýhody

Kromě ceny je snad jediná částečná nevýhoda oproti Eclipsu menší množství dostupných pluginů. Na druhou stranu, v základním balíku IntelliJ je jich obrovské množství a jsou bezproblémové – fungují tak jak mají, takže tato nevýhoda není tak vážná.

Mezi nejzajímavější pluginy patří:

- IdeaVim – přidává editoru mnoho funkcí velmi efektivního Vim editoru

- Scala plugin – jednoznačně nejlepší IDE pro Scalu

- Clojure plugin – platí to stejné co u Scala pluginu

Celkově je velmi těžké hledat na tomto IDE nějaké nevýhody. Tým JetBrains jde velmi tvrdě za vývojem nejlepších vývojových nástrojů, a i když Ultimate verze jejich Java IDE není zdarma jako ostatní velká Java IDE, určitě stojí za zamyšlení, je možné vyzkoušet Comunity edition, která je open-source a zdarma, a nebo Ultimate, u které je trial verze na 30 dní. Neznám nikoho kdo zkusil IntelliJ Ideu a poté se dobrovolně vrátil k Eclipse, je tu hromada malých detailů, které však dohromady přispívají k mnohem příjemnější práci, hlavě dokáže odhalit mnoho chyb, které se při práci s jinými nástroji projeví až při spuštění aplikace.

Do článku se všechny možnosti, které Idea přináší nevlezou, k dalšímu studování doporučuji navštívit stránky JetBrains, k dispozici je kompletní seznam vlastností, mapy klávesových zkratek, množství video tutoriálů a dalších informací.

Získávání dat z HTML stránek

Milan Čečrdle — Thu, 27 Oct 2011 10:22:03 +0000

Na jednom projektu jsme potřebovali získávat informace z HTML stránek a využili jsme knihovnu jSoup. Její jednoduché použití si ukážeme na příkladu získání jednotlivých popisů volných pozic ze stránek Aspectworks. Pomocí metody connect a get() získáme načtenou stránkou

Document doc = Jsoup.connect("http://www.aspectworks.com/volne-pozice").get();

Stránka obsahuje „ul“ element s class = „subPages“, ve které jsou pod elementy „li“ uloženy jednotlivé pozice. Pomocí metody select nad daným dokumentem najdeme odpovídající pozice a vypíšeme pozici a URL kde získáme detail pozice

Elements positions=doc.select("ul.subPages li a");
for (Element elem:positions) {
   System.out.printf("Pozice=%s,URL=%s\n",elem.text(),elem.absUrl("href"));
}

K vyhledání cílových informací lze použít syntaxy jquery případně CSS selektorů, detailní popis najdete zde. Užitečné jsou dále metody text(), která vrátí vnitřní obsah elementu a dále absUrl, která vrátí absolutní URL, tak abychom jej mohli přímo použít na další volání. Samozřejmostí je také automické vyplnění parametru stránky a odeslání např. metodou post

Jsoup.connect(URL).data("název parametru","hodnota").post();

Knihovna funguje velmi intuitivně a její použití bylo bezproblémové. Jediný nedostatek je zatím nemožnost nastavit proxy. Výhodou knihovny je také to, že má minimun závislostí a lze ji tedy použít např. při vývoji Android aplikací.

JTA v integračních testech bez aplikačního serveru

Milan Čečrdle — Wed, 12 Oct 2011 07:27:26 +0000

JTA tedy distribuované transakce se dost často použivájí v enterprise systémech, kde je potřeba přistupovat jak k více databázím, tak třeba v kombinaci databáze a messaging systém (např. Websphere MQ). Mezi vývojáři obecně panuje představa, že pro jeho využítí potřebuji aplikační server ala Jboss či Websphere, případně také, že bez EJB JTA nelze použít. Toto není samozřejmě pravda a např. pokud použijeme Spring, situace se nám ještě velmi zjednoduší. V příkladu si ukážeme jak nakonfigurovat transakční manager pro test, který otestuje jednu komponentu, ve které je logika přístupu k více XA zdrojům.

Takto vypadá šablona spring integračního testu, který naloaduje aplikační kontexty, jeden s konfigurací aplikace a jeden s konfigurací testovacího JTA manageru.

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {"/applicationTestContext.xml", "/applicationContext.xml"})
@TestExecutionListeners({TransactionalTestExecutionListener.class})
@Transactional
public class JTASampleIntegrationTest extends AbstractJUnit4SpringContextTests {
  @Test
  public void testComponenet() {
  }
}

Existuje více implementací JTA, například Atomikos nebo Jotm. Pro testy jsem se rozhodl použít Jotm implementace a dále implementaci XA pool datasource z projektu Enhydra XAPool.

Prvni co musíme je definovat JTATransactionManagera. Tomu musíme specifikovat referenci na factory, která vytvoří JOTM objekt, který implementuje UserTransaction interface. Pro JOTM je již factory součastí springu. V případě běhu v aplikačním server už má JTATransactionManager implementován automatický lookup do JNDI pro konkrétní objekt a není třeba specifikovat nic.

Takto nadefinujeme „testDataSource1″ s využitím XA datasource z Enhrydry, obdobně definuje i druhý datasource.

	
		
			
				
					
				
				
					com.informix.jdbc.IfxDriver
				
				
			
		
		
			user
		
		
			password

Pak už pouze spustíme test a ověříme, že změny v obou datasourcech při testech nebyly commitnuty.

Jak na mock HTTP serveru

Roman Valina — Mon, 05 Sep 2011 12:35:12 +0000

Pro jednoho z naších zákazníků dodáváme C2DM – zasílání notifikací na mobilní telefon s operačním systémem Android. Tato služba je implementována jako HTTP request, ve kterém pošlete zprávu, registrační identifikátor instance zařízení s androidem a C2DM server se postará o doručení.

Narazil jsem ale na problém jak vytvořit unit test který ověří, správný formát odesílané notifikace. Problém je právě v tom, jak namockovat chování C2DM serveru bez toho, abych musel někde rozebíhat Jetty či nedejbože Tomcat.

Testovaný kód vypadá nějak takto:

private static int sendMessage(String message, URL url) throws IOException {
   // create connection
   HttpURLConnection connection = (HttpURLConnection) url.openConnection();
    connection.setDoInput(true);
    connection.setDoOutput(true);
    connection.setRequestMethod("POST");
    // post data
   DataOutputStream output = new DataOutputStream(connection.getOutputStream());
    output.writeBytes("message="message);
    output.flush();
    output.close();
    // establish connection
   connection.connect();
    // return errocode
   return connection.getResponseCode();
}

Umím vytvořit mock interfacu (viz. EasyMock , PowerMock ect.), dokonce i stub konkrétní třídy. Final třídu URL zkrátka nepodědíte a testovanému kódu pak „nepředhodíte“.

Narazil jsem na knihovnu simple, která velice jednoduše na několika řádcích na pár sekund rozběhne „webový server“. Vy pak můžete snadno nasimulovat chování protějšího serveru.

Vytvoříte třídu implementující interface org.simpleframework.http.core.Container

public class MockC2dmServer implements Container {
  protected String capturedMessage;
  public void handle(Request request, Response response) {
     try {
       capturedMessage = request.getParameter("message");
     } catch (IOException e1) {
       capturedMessage = null;
     }
    if(capturedMessage != null) {
      response.setCode(HttpURLConnection.HTTP_OK);
    } else {
      response.setCode(HttpURLConnection.HTTP_BADREQUEST);
    }
  }
}

Samotné vytvoření serveru a test pak může vypadat nějak takto:

@Test
public void basicSenderTest() throws Exception {
  MockC2dmServer mockServer = new MockC2dmServer();
   // binds server to socket on adress
  Connection connectionServer = new SocketConnection(mockServer);
  SocketAddress address = new InetSocketAddress("localhost",8080));
  connectionServer.connect(address);
   // test method
  String message = "message text"
  C2dmNotificationSender.sendNotification(message, new URL("http://localhost:8080");
  Assert.assertEquals(message, mockServer.capturedMessage);
}

Uznávám, že tento způsob testování má svá rizika, například vám nikdo nezaručí, že port 8080 bude volný, to však jde minimalizovat například metodou, která vám nějaký volný port najde, ale to už není tématem tohoto článku. Pokud někdo z vás přijde na jiné, lepší řešení rád si ho přečtu v diskuzi pod článkem.

Pokročilé integrační buildy

Luboš Račanský — Fri, 12 Aug 2011 12:12:21 +0000

Pevně veřím, že continuous integration je již zažitý standard na všech, nebo alespoň na těch jednodušších, projektech. Chtěl bych rozptýlit případné obavy z konfigurace složitějších projektů. Ukážeme si, jak pouhým mvn clean verify nastartujeme celou SOA platformu a nad ní spustíme selenium testy.

SOA je buzzword, ale principy, které oprášil Roman Pichlík v článku Aplikace kontra Služba kontra Knihovna, stále platí. Jedním ze zmiňovaných aspektů je i loose coupling (volné provázání). To sice zjednodušuje deploy updatu, ale na druhou stranu kompletní rozchození prostředí na zelené louce, pokud byste ho snad prováděli ručně, vás rozhodně bavit nebude. Avšak lenost je matka pokroku a pro maven existuje plugin cargo.

U zákazníka jsme implementovali webovou aplikaci, která volala další dva servery přes REST api a autentizace byla řešená přes SSO (konkrétně CAS server). I takto komplexní platforma je snadno testovatelná. Konfiguraci popíši na zjednodušeném příkladu dvou serverů Foo a Hoo.

Možná máte někde v podvědomí zapsané, že na war souboru nelze záviset. Binárně nikoliv, ale pro potřeby našeho buildu ano. Přidejte tedy do závislostí servery potřebné pro test. Nezapomeňte, že tyto servery musí být nainstalované ve vaší maven repository (nejlépe, pokud spouštíte jejich integrační buildy s goalem deploy).


	com.aspectworks.examples
	foo
	${foo.version}
	war


	com.aspectworks.examples
	hoo
	${hoo.version}
	war

Samotný deploy serverů na tomcat zajistí cargo plugin, configurace viz níže. Pozor, tomcat si budete muset přidat do maven repository sami.


	maven-failsafe-plugin
	2.8.1
	
		
			
				integration-test
				verify
			
		
	


	org.codehaus.cargo
	cargo-maven2-plugin
	1.1.1
	
		
			start-container
			pre-integration-test
			
				start
			
		
	
	
		
			tomcat6x
			
				org.apache
				tomcat
				6.0.32
			
			
				file:etc/conf/
				file:etc/conf/
			
		
		
			
				
					com.aspectworks.examples
					foo
					war
					
						foo
					
				
				
					com.aspectworks.examples
					hoo
					war
					
						hoo
					
				
			
			
				${cargo.port}

Je dobrým zvykem držet konfigurační soubory mimo war. Jediný build tak můžete nasadit v různých prostředích, pouze s jinou konfigurací. V předchozí ukázce pomu jste si mohli všimnout nastavení systémových properties. Tímto způsobem zadáme cestu právě k těmto konfiguračním souborům, které se v našem případě od produkčního prostředí liší například tím, že nastavují in memory HSQL databázi.

Spouštění selenium serveru pro integrační test nastavíme v pomu následujícím způsobem.


	org.codehaus.mojo
	selenium-maven-plugin
	1.1
	
		
			start
			pre-integration-test
			
				start-server
			
			
				true
			
		
		
			stop
			post-integration-test
			
				stop-server

A nyní můžete konečně spustit mvn clean verify

Závěr
Ukázali jsme si, že i testování rozsáhlejších projektů nemusí být složité. Doufám, že jsem inspiroval alespoň jeden projekt, kde již dnes zavedete integrační testy. Pokud by vás zajímalo, jak pro integrační testy a nightly buildy inicializujeme data, dejte nám vědět v komentářích, můžeme se tomuto tématu věnovat v nějakém z příštích příspěvků.