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

<bean id="testTrigger" class="org.springframework.scheduling.quartz.CronTriggerBean">
	<property name="jobDetail">
		<bean class="org.springframework.scheduling.quartz.JobDetailBean">
			<property name="jobClass" value="com.aspectworks.TestJob" />
			<property name="name" value="TestJob" />
		</bean>
	</property>
	<property name="jobDataAsMap">
		<map>
			<entry key="testAttribute" value="value " />
		</map>
	</property>
	<property name="cronExpression" value="1 * * * * ?" />
</bean>

Konfigurace scheduleru pro clusterové řešení

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
<property name="waitForJobsToCompleteOnShutdown" value="true" />
	<property name="dataSource" ref="dataSource" />
	<property name="overwriteExistingJobs" value="true" />
	<property name="autoStartup" value="true" />
	<property name="triggers">
		<list>
			<ref bean="testTrigger" />
		</list>
	</property>
	<property name="quartzProperties">
		<props>
			<prop key="org.quartz.scheduler.instanceName">TestScheduler</prop>
			<prop key="org.quartz.scheduler.instanceId">AUTO</prop>
			<prop key="org.quartz.jobStore.misfireThreshold">60000</prop>
			<prop key="org.quartz.jobStore.class">org.quartz.impl.jdbcjobstore.JobStoreTX</prop>
			<prop key="org.quartz.jobStore.driverDelegateClass">org.quartz.impl.jdbcjobstore.StdJDBCDelegate</prop>
			<prop key="org.quartz.jobStore.tablePrefix">QRTZ_</prop>
			<prop key="org.quartz.jobStore.isClustered">true</prop>
			<prop key="org.quartz.threadPool.class">org.quartz.simpl.SimpleThreadPool</prop>
			<prop key="org.quartz.threadPool.threadCount">25</prop>
			<prop key="org.quartz.threadPool.threadPriority">5</prop>
		</props>
	</property>
	<property name="schedulerContextAsMap">
		<map>
			<entry key="testService" value-ref="testService" />
		</map>
	</property>
</bean>

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

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

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

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.

	<bean id="jotm" class="org.springframework.transaction.jta.JotmFactoryBean" />
	<bean id="transactionManager"
		class="org.springframework.transaction.jta.JtaTransactionManager">
		<property name="userTransaction" ref="jotm" />
	</bean>

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

	<bean id="testDataSource1" class="org.enhydra.jdbc.pool.StandardXAPoolDataSource"
		destroy-method="shutdown">
		<property name="dataSource">
			<bean class="org.enhydra.jdbc.standard.StandardXADataSource"
				destroy-method="shutdown">
				<property name="transactionManager">
					<ref local="jotm" />
				</property>
				<property name="driverName">
					<value>com.informix.jdbc.IfxDriver</value>
				</property>
				<property name="url" value="jdbc:informix-sqli://....."/>
			</bean>
		</property>
		<property name="user">
			<value>user</value>
		</property>
		<property name="password">
			<value>password</value>
		</property>
	</bean>

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

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.

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

<dependency>
	<groupId>com.aspectworks.examples</groupId>
	<artifactId>foo</artifactId>
	<version>${foo.version}</version>
	<type>war</type>
</dependency>
<dependency>
	<groupId>com.aspectworks.examples</groupId>
	<artifactId>hoo</artifactId>
	<version>${hoo.version}</version>
	<type>war</type>
</dependency>

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

<plugin>
	<artifactId>maven-failsafe-plugin</artifactId>
	<version>2.8.1</version>
	<executions>
		<execution>
			<goals>
				<goal>integration-test</goal>
				<goal>verify</goal>
			</goals>
		</execution>
	</executions>
</plugin>
<plugin>
	<groupId>org.codehaus.cargo</groupId>
	<artifactId>cargo-maven2-plugin</artifactId>
	<version>1.1.1</version>
	<executions>
		<execution>
			<id>start-container</id>
			<phase>pre-integration-test</phase>
			<goals>
				<goal>start</goal>
			</goals>
		</execution>
	</executions>
	<configuration>
		<container>
			<containerId>tomcat6x</containerId>
			<artifactInstaller>
				<groupId>org.apache</groupId>
				<artifactId>tomcat</artifactId>
				<version>6.0.32</version>
			</artifactInstaller>
			<systemProperties>
				<foo.config.location>file:etc/conf/</foo.config.location>
				<hoo.config.location>file:etc/conf/</hoo.config.location>
			</systemProperties>
		</container>
		<configuration>
			<deployables>
				<deployable>
					<groupId>com.aspectworks.examples</groupId>
					<artifactId>foo</artifactId>
					<type>war</type>
					<properties>
						<context>foo</context>
					</properties>
				</deployable>
				<deployable>
					<groupId>com.aspectworks.examples</groupId>
					<artifactId>hoo</artifactId>
					<type>war</type>
					<properties>
						<context>hoo</context>
					</properties>
				</deployable>
			</deployables>
			<properties>
				<cargo.servlet.port>${cargo.port}</cargo.servlet.port>
			</properties>
		</configuration>
	</configuration>
</plugin>

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.

<plugin>
	<groupId>org.codehaus.mojo</groupId>
	<artifactId>selenium-maven-plugin</artifactId>
	<version>1.1</version>
	<executions>
		<execution>
			<id>start</id>
			<phase>pre-integration-test</phase>
			<goals>
				<goal>start-server</goal>
			</goals>
			<configuration>
				<background>true</background>
			</configuration>
		</execution>
		<execution>
			<id>stop</id>
			<phase>post-integration-test</phase>
			<goals>
				<goal>stop-server</goal>
			</goals>
		</execution>
	</executions>
</plugin>

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

MQ Inbound Channel Adapter

Scénář pro naši implementaci byl jednoduchý: poslouchat na frontě a vybírat odtud všechny zprávy, tělo MQ zprávy se přečte jako String a pošle se do výstupního kanálu nakonfigurovaného ve Spring Integration pro další transformování a zpracování. Celou logiku pro přístup k MQ jsem zapouzdřil do nového inbound adapteru, který má za předka org.springframework.integration.endpoint.AbstractEndpoint a implementuje org.springframework.integration.core.MessageSource.

public class MQAdapter extends AbstractEndpoint implements MessageSource{
...
}

Ve Spring konfiguraci lze potom adapter nadefinovat jednoduše takto:

<!-- namespace http://www.springframework.org/schema/integration -->
<int:inbound-channel-adapter ref="mqAdapter" channel="mqOutput">
   <int:poller fixed-rate="1000" max-messages-per-poll="10"/>
</int:inbound-channel-adapter>
<bean name="mqAdapter" class="example.MQAdapter">
...
</bean>

Takto se každou sekundu otestuje fronta, zda nepřišla nová zpráva, v našem příkladu se zpracuje maximálně deset zpráv za sekundu.

Co se týče implementace MQ adapteru, neobsahuje nic složitého. Nejprve se naváže spojení k MQ queue manageru které se udržuje po celou dobu životnosti adapteru. Podle nastavení polleru se pak periodicky zjišťuje, zda nepřišla nová zpráva. Spadlé spojení není potřeba nijak ošetřovat, adapter jednoduše naváže nové spojení při následujícím pokusu o čtení z fronty, není tedy nutný žádný daemon thread. Časově nejnáročnější bylo proniknout do nuancí MQ API, dále tedy následuje popis použití tohoto rozhraní.

WebSphere MQ API

Pro připojení k MQ je nejprve potřeba navázat spojení ke queue manageru který je reprezentovaný třídou com.ibm.mq.MQQueueManager. Pro tento účel je třeba znát a nastavit parametry připojení, jako je jméno queue managera, jméno fronty, IP adresa a port atd.. Toto lze udělat dvojím způsobem. Buď nastavit statická pole ve třídě com.ibm.mq.MQEnvironment (instance MQQueueManager si je načte při inicializaci), nebo parametry připojení naplnit do Hashtable a tu předat konstruktoru třídy MQQueueManager. Z nějakého důvodu mi druhý způsob nefungoval, takže jsem použil způsob první.

//nastaveni statickych poli
MQEnvironment.hostname = hostname;
MQEnvironment.port     = port;
MQEnvironment.channel  = channel;
MQEnvironment.CCSID    = ccsid;
MQEnvironment.userID   = userId;
//konstruktor cte z MQEnvironment
MQQueueManager qMgr = new MQQueueManager(queueManagerName);

Dalším krokem je vytvoření samotného spojení na MQ frontu, tj. vytvořit instanci třídy com.ibm.mq.MQQueue. Frontu je možné otevřít v několika modech (zejména: sdílené nebo exkluzivní čtení, zápis, prohlížení obsahu fronty) a lze nastavit další různé detaily jak se fronta bude chovat. Všechny tyto parametry se nastavují jako bitová maska a předávají se konstruktoru MQQueue.

int openOptions = MQC.MQOO_INQUIRE |= MQC.MQOO_INPUT_SHARED |= MQC.MQOO_BROWSE;
MQQueue queue = qMgr.accessQueue(this.queueName, openOptions);

Jakmile máme vytvořenou instanci MQQueue, můžeme číst zprávy z fronty. Pro čtení je opět potřeba nadefinovat sadu parametrů, které ovlivňují jak bude čtení probíhat; tyto parametry jsou reprezentovány třídou com.ibm.mq.MQGetMessageOptions. Původně jsem se snažil nastavit parametry tak, aby volání queue.get() klienta blokovalo do té doby, než se na frontě objeví zpráva, tudíž bez zbytečného pollingu, nějak takto:

MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.matchOptions = MQC.MQMO_NONE;
gmo.options  = MQC.MQGMO_WAIT;
gmo.waitInterval = MQC.MQWI_UNLIMITED;

Ovšem záhy se ukázalo, že potom není možné volání get() předčasně ukončit: interrupt na threadu nemá vliv, volat metodu close() na MQQueue také nelze, protože jak get() tak close() je synchronizováno na instanci MQQueue. Takže jsem se pollingu nevyhnul. Celý průbeh čtení z fronty vypadá následovně:

MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.matchOptions = MQC.MQMO_NONE; //nefiltrovat, cist vsechny zpravy ve fronte
gmo.options  = MQC.MQGMO_NO_WAIT | MQC.MQGMO_FAIL_IF_QUIESCING;
MQMessage messageBuffer = new MQMessage();
queue.get(messageBuffer, gmo);

Při takovéto konfiguraci se klient pokusí přečíst zprávu z fronty a pokud je fronta prázdná, volání neblokuje, ale vyhodí výjimku. Toto je nepříjemné, protože MQ klient loguje defaultně přímo do System.err, pak se v logu hromadí hlášení že nebyla nalezena zpráva: MQJE001: Completion Code 2, Reason 2033
Po delším googlování jsem nalezl dvě řešení, jak se vyhnout zahlcovaní logu. První způsob je přesměrovat logování nastavením statického pole com.ibm.mq.MQException.log (kdo má rád radikální řešení, lze nastavit na null a potlačit logování úplně). Ale více mi vyhovoval druhý způsob, filtrovat error kódy, které nechceme logovat:

MQException.logExclude(MQException.MQRC_NO_MSG_AVAILABLE);

Posledním krokem v implementaci adapteru je čtení těla zprávy, což už je jednoduchá věc.

byte[] buffer = new byte[messageBuffer.getDataLength()]; //MQMessage messageBuffer
messageBuffer.readFully(buffer, messageBuffer.getDataOffset(), messageBuffer.getDataLength());
String payload = new String(buffer, charset);

Boilerplate kód pre vlastný spring namespace pozostáva zo súborov META-INF/spring.handlers

http://www.company.com/schema/ourSchema=com.company.OurNamespaceHandler

a META-INF/spring.schemas

http://www.company.com/schema/ourSchema.xsd=META-INF/schema/ourSchema.xsd

V súbore META-INF/schema/ourSchema.xsd definujme štandardným spôsobom XML schému:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http://www.company.com/schema/ourSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:beans="http://www.springframework.org/schema/beans" targetNamespace="http://www.hypotecnibanka.cz/schema/scoreProc"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xsd:import namespace="http://www.springframework.org/schema/beans" />
 <xsd:element name="expr">
   <xsd:complexType>
     <xsd:simpleContent>
       <xsd:extension base="xsd:string">
         <xsd:attribute name="result" use="required" type="xsd:token" />
         <xsd:attribute name="id" type="xsd:ID" />
         <xsd:attribute name="name" type="xsd:string" />
       </xsd:extension>
     </xsd:simpleContent>
   </xsd:complexType>
 </xsd:element>
 <xsd:element name="foo">
   <xsd:complexType>
     <xsd:sequence minOccurs="1" maxOccurs="1">
       <xsd:element ref="expr" minOccurs="1" maxOccurs="unbounded" />
     </xsd:sequence>
   </xsd:complexType>
 </xsd:element>

V jave je potrebné implementovať dva interfacei: NamespaceHandler a BeanDefinitionParser. Spring framework nám samozrejme poskytuje potrebné abstraktné implementácie, ktoré je jednoduché upraviť:

public class OurNamespaceHandler extends NamespaceHandlerSupport {
 public void init() {
   ScoreBeanDefinitionParser parser = new OurBeanDefinitionParser();
   registerBeanDefinitionParser("foo", parser);
 }

Väčšinu práce vykonáva BeanDefinitionParser:

public class ScoreBeanDefinitionParser extends AbstractBeanDefinitionParser {
 @Override
 protected AbstractBeanDefinition parseInternal(Element scoring, ParserContext parserContext) {
   BeanDefinitionBuilder factory = BeanDefinitionBuilder.genericBeanDefinition(FooServiceImpl.class);
   factory.addPropertyValue("exprs", processExprs(DomUtils.getChildElementsByTagName(scoring, "expr")));
   return factory.getBeanDefinition();
 }
 private ManagedList<BeanDefinition> processExpressions(List<Element> expressions) {
   ManagedList<BeanDefinition> ret = new ManagedList<BeanDefinition>(expressions.size());
   for (Element element : expressions) {
     BeanDefinitionBuilder factory = BeanDefinitionBuilder.genericBeanDefinition(ExpressionProcessor.class);
     factory.addPropertyValue("expression", element.getTextContent());
     factory.addPropertyValue("result", CredScore.valueOf(element.getAttribute("result")));
     ret.add(factory.getBeanDefinition());
   }
   return ret;
 }

Z kódu je zrejmé, že Spring kontajner vytvorí beany dvoch tried, FooServiceImpl a ExpressionProcessor.

Implementácii ExpressionProcessora sa bude venovať druhá časť článku. Pre samotné vyhodnocovanie expressionov môže dobre poslúžiť akýkoľvek expression language (SPEL, MVEL, …). V našom konkrétnom prípade použijeme groovy, keďže má k expression jazykom blízko ale jeho syntax umožňuje silnejiše vyjadrovanie. ExpressionProcessor v základe implementujeme:

public class ExpressionProcessor {
  private String result;
  private String expr;
  public String getResult() {
     GroovyShell groovy = new GroovyShell();
     //priklad nastavenia premennej
     groovy.setVariable("foo", "bar");
     Boolean eval = (Boolean) groovy.evaluate(expr);
     if (eval) {
       return result;
     }
     log.debug("Evaluated to false, returning null");
     return null;
 }

V príklade je viditeľné využitie embedded Groovy, pomocou GroovyShell, nastavenie premennej do kontextu a vyhodnotenie expressionu. DSL jazyk v celej svojej paráde potom môže vyzerať nasledovne:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:proc="http://www.company.com/schema/ourSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.company.com/schema/ourSchema http://www.company.com/schema/scoreProc/ourSchema.xsd">
 <proc:foo>
   <proc:expr result="L">foo == bar</proc:expr>
   <proc:expr result="M">foo != bar</proc:expr>
 </proc:foo>
</beans>

Toto je už napríklad pre business analytika pochopiteľný formát a jednoducho do neho pridá ďalšie pravidlá atď.

Oproti vytváraniu DSL napríklad v čistom Groovy (postup je popísaný napríklad v knihe Groovy for Domain-Specific Languages) má tento postup výhodu v tom, že je relatívne nenáročný najmä pre vývojára, ktorý je Spring zručný a možnosť nasadiť ľubovoľný expression language zvyšuje flexibilitu.

Základní problém je, když potřebujete různé konfigurace pro různá prostředí (vývojové vs. produkční), nebo když potřebujete svůj produkt konfigurovat odlišně pro každého vašeho zákazníka. A přitom to nejde vyřesit nějak jednoduše třeba pomocí properties (PropertyPlaceholderConfigurer). Potřebujete úplně jinou konfiguraci pro jiné prostředí. V jednom bude aplikace nasazená na Tomcatu, v druhém na IBM WebSphere. Transakční konfigurace budou úplně odlišné. Nebo chcete do produktu implementovat autentizaci pomocí databáze i LDAPu, ale potom pro zákazníka jenom zvolit tu vhodnou.

Ve Springu 3.1 tedy existují profily. Pomocí nich můžete označit jednotlivé beany nebo celé konfigurační soubory, že budou aktivovány pouze pro daný profil. V XML může podpora pro dva způsoby autentizace ve Spring Security vypadat nějak takto:

<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="..."
	xsi:schemaLocation="...">
 <beans profile="auth-db">
   <bean id="authProvider" class="org.spring...DaoAuthenticationProvider">
    ...
   </bean>
 </beans>
 <beans profile="auth-ldap">
   <bean id="authProvider" class="org.spring...LdapAuthenticationProvider">
      ...
   </bean>
 </beans>
</beans>

Pokud ke konfiguraci používáte anotace, existuje nová anotace @Profile, pomocí níž můžete opět řídit v jakém profilu se komponenta použije.

@Service
@Profile("google")
public class GoogleStockLoader implements StockLoader {

Profily se aktivují několika způsoby. Buď pomocí API přímo na ApplicationContext nebo pro většinu projektů spíše ve web.xml nebo pomocí systémové proměnné spring.profiles.active.

ClassPathXmlApplicationContext ctx =
    new ClassPathXmlApplicationContext();
ctx.setConfigLocation("orinoco-security.xml");
ctx.getEnvironment().setActiveProfiles("auth-ldap");
ctx.refresh();

Doporučuji se podívat na SpringSource blog, kde je více informací o profilech a novinkách ve Springu 3.1. Doufám, že tahle verze vyjde brzo, abychom to mohli co nejdřív začít používat.

Druhá část blogu o psaní javovských testů v Groovy přinese méně slov a více kódu.

Témata:

• Deklarace testovacích metod s JUnit
• Implementace rozhranní “mapou”
• Capture
• Libovolné řetězce jako názvy metod
• shouldFail?
• Testování XML výstupů
• A další…
• Konfigurace Mavenu

Zkusili jste už psát testy v Groovy? K čemu dalšímu Groovy používáte? Podělte se o své zkušenosti v diskuzi pod článkem.

Deklarace testovacích metod s JUnit

Testovací metody můžeme označit @Test anotací tak, jak to zavedla JUnit 4. Druhou možností je psát testovací třídy jako potomky GroovyTestCase a testovací metody začínat prefixem “test”.

class Test1 {
  @Test
  void "notification message handling"() {
    Assert.fail()
  }
}
class Test2 extends GroovyTestCase {
  void test1() {
    fail("notification message not handled")
  }
}

GroovyTestCase dědí z třídy junit.framework.TestCase a přidává pár šikovných drobností navíc (shouldFail).

Implementace rozhranní “mapou”

V Groovy můžeme rozhranní implementovat pomocí closures a map. Pomocí closure:

def accountDao = { new Account(number: “AX001”, balance: 999G) } as AccountDao

Tato closure implementuje všechny metody AccountDao pomocí jednoho kódu (akademický, ale někdy užitečný příklad). Pokud bych chtěl brát v úvahu parametry metod, mohu je v closure deklarovat jako pole – Object[] params.

Implementace pomocí mapy:

def accountDao = [ get: { new Account(number: “AX001”, balance: 999G) } ] as AccountDao

Mapa implementuje jen metodu get. Rozhranní takto můžeme implementovat i jen částečně – volání neimplementovaných metod skončí NPE. Je to výborná zkratka pro implementaci různých testovacích stubů (nebo mocků, chcete-li).

Capture

Implementace rozhranní za pomoci map nebo closures může výrazně zjednodušit situace, kde bychom jinak v Javě museli použít např. EasyMock a jeho metodu capture. Jako příklad uvedu zjednodušený test z našeho blogu o testech metod tvořících objekty.

class UserServiceTest {
  @Test
  public void createUser() {
    def userService = new UserServiceImpl()
    userService.userDao = { User user -> assert "tomas" == user.username } as UserDao
    userService.createUser("tomas")
  }
}

Test ověří, že metoda UserService.createUser správně vytvoří instanci třídy User. Zkuste výsledný kód porovnat s implementací pomocí EasyMocku a capture (převzato z citovaného blogu).

public class UserServiceTest {
  private UserServiceImpl userService;
  private UserDao userDao;
  @Before
  public void setUp() {
    userService = new UserServiceImpl();
    userDao = createMock(UserDao.class);
    userService.setUserDao(userDao);
  }
  @Test
  public void createUser() {
    Capture<User> capturedUser = new Capture<User>();
    userDao.save(capture(capturedUser));
    replay(userDao);
    userService.createUser("pavel");
    User user = capturedUser.getValue();
    assertEquals("pavel", user.getUsername());
    verify(userDao);
  }
}

Java dobrý, Groovy lepší?

Libovolné řetězce jako názvy metod

Pěknou možností je nazývat metody libovolnými řetězci.

@Test void "notification message handling"() {
  // ...
}

Maven potom zobrazí výsledek běhu testu následujícím způsobem.

Failed tests:
  notification message handling(test.NotificationTest)

shouldFail?

Metody shouldFail třídy GroovyTestCase slouží pro přehledné řešení situací s výjimkami a elegantně obchází obvyklou konstrukci s try – catch blokem.

shouldFail(NullPointerException) {
  new Hashtable()["key"] = null
}
shouldFail(IllegalArgumentException) {
  new HashMap(-1)
}

A co jsem myslel obvyklou konstrukcí s try – catch blokem?

    try {
      Hashtable ht = new Hashtable();
      ht.put("key", null);
      fail();
    } catch (NullPointerException e) {
      // ok
    }
    try {
      new HashMap(-1);
      fail();
    } catch (IllegalArgumentException e) {
      // ok
    }

První příklad testuje vložení null hodnoty pod určitým klíčem do Hashtable – očekáváme, že pokus skončí výjimkou NPE (jinak fail). Podobně v druhém příkladu by vytvoření HashMap velikosti -1 mělo skončit výjimkou IAE.

Testování XML výstupů

Častým předmětem testů je ověření, jestli nějaký XML výstup odpovídá očekávanému tvaru. Groovy nabízí pro parsing XML mimojiné třídu XmlSlurper. Její použití znamená, že nepíšete XPath výrazy, neiterujete přes DOM, ale přistupujete k obsahu XML stále prostředky Groovy jazyka.

Příklad z dokumentace:

<records>
    <car name='HSV Maloo' make='Holden' year='2006'>
        <country>Australia</country>
        <record type='speed'>Production Pickup Truck with speed of 271kph</record>
    </car>
    <car name='P50' make='Peel' year='1962'>
        <country>Isle of Man</country>
        <record type='size'>Smallest Street-Legal Car at 99cm wide and 59 kg in weight</record>
    </car>
</records>

Použití třídy XmlSlurper:

def records = new XmlSlurper().parseText(...)
assert 2 == records.car.size()
def firstRecord = records.car[0]
assert 'car' == firstRecord.name()
assert 'Holden' == firstRecord.@make.text()
assert 'Australia' == firstRecord.country.text()

Co se čte lépe – //car[1][@name='HSV Maloo'] nebo car[0].@name.text() == “HSV Maloo”?

A další…

Mezi další killer vlastnosti Groovy patří vytváření nových instancí, buildery pro vytváření stromových struktur objektů nebo podpora pro práci s kolekcemi. Pěkně akční český přehled lze nalézt třeba v článku Groovy je žůžo.

Groovy má v arzenálu i podporu pro vytváření mock objektů. Standardní přístup mě jako uživatele EasyMocku nepřesvědčil, ale GMock stojí za to. A nezapomínejme na mapy, ty vyřeší mnoho potřeb.

I když toho Groovy nabízí hodně a ještě víc, rozhodnout se psát testy v Groovy neznamená opustit skvělou testovací infrastrukturu z Javy. Knihovny jako EasyMock, PowerMock, Hamcrest, … a libovolné jiné můžete stejným způsobem používat dál.

Konfigurace Mavenu

Podporu Groovy začleníme do projektu jednoduše jako závislost na Groovy artefaktu.

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy</artifactId>
    <version>1.7.5</version>
</dependency>

Pro správný běh testů je ještě třeba nakonfigurovat build plugin pro kompilaci testů v Groovy.

<plugin>
    <groupId>org.codehaus.gmaven</groupId>
    <artifactId>gmaven-plugin</artifactId>
    <version>1.3</version>
    <executions>
        <execution>
            <id>testCompile</id>
            <goals><goal>testCompile</goal></goals>
            <configuration>
                <sources>
                    <fileset>
                        <directory>${pom.basedir}/src/test/java</directory>
                        <includes><include>**/*.groovy</include></includes>
                    </fileset>
                </sources>
            </configuration>
        </execution>
    </executions>
</plugin>

Příklad popisuje možnost, kdy jsou .groovy zdrojáky ve stejném adresáři jako testy v Javě. Pokud bychom testy umístili do adresáře src/test/groovy, nebylo by třeba v konfiguraci zahrnovat uvedený fileset.