Ale i přesto bylo potřeba do této implementace doimplementovat několik požadavků. Rozhodl jsem se nejprve stávající implementaci pokrýt testy tak, abych tím, co tam doplním nerozbil to, co již funguje. A zde jsem trochu narazil. Implementace tohoto modulu je velice těsně spjata s JMS implementací Weblogicu a navíc tak, že se jedná o několik front, které jsou vzájemně propojeny a zpráva zkrze ně postupně „propadává“ podle definovaných pravidel.

Abych to celé byl tedy schopen spustit jako unit test, musel jsem vyřešit pár „drobností“, a to poskytovatele JNDI kontextu, transaction manager a vlastní implementaci JMS. Pro JNDI kontextu jsem jednoduše využil prostředků Springu. Pro transakční manager jsem využil Bitronix Transaction Manager a pro messagingové služby padlo rozhodnutí na Apache ActiveMQ.

JNDI kontext

Vytvoření vlastního JNDI kontextu je ve Springu triviální úloha. Já jsem si pro to napsal jednoduchou utilitku, která mi ji ještě více zjednodušuje:

package eu.kratochvil.utils.spring;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.mock.jndi.SimpleNamingContextBuilder;

import java.util.HashMap;
import java.util.Map;

/**
 * Simple implementation of JNDI context that should be used in unit-tests
 * within Spring context.
 * 

 * Basic usage is simple:
 * 
 * <bean id="jndiContext" class="cz.isvs.reg.ros.ws.repository.util.MockSpringJndiContext">
 *   <property name="jndiContext">
 *      <map>
 *          <entry key="ros.VstupniFronta" value-ref="destinationVstupniFronta"/>
 *          <entry key="ros.VystupniFronta" value-ref="destinationVystupniFronta"/>
 *          <entry key="weblogic.jms.XAConnectionFactory" value-ref="activeMQConnectionFactory"/>
 *      </map>
 *   </property>
 * </bean>
 *
 * There isn't needet to use something like jndi.properties because jndi context is define
 * directly inside spring context. 
 *
 * @author Jiri Kratochvil (jiri.kratochvil@jetminds.com)
 */
public class MockSpringJndiContext implements InitializingBean {

    public static final Logger logger = LoggerFactory.getLogger(MockSpringJndiContext.class);

    Map jndiContext = new HashMap();

    public void setJndiContext(Map jndiContext) {
        this.jndiContext = jndiContext;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        logger.info("Initializing JNDI context");
        SimpleNamingContextBuilder builder = SimpleNamingContextBuilder.emptyActivatedContextBuilder();
        for (Map.Entry entry : jndiContext.entrySet()) {
            logger.debug("Binding {} in JNDI context", entry.getKey().toString());
            builder.bind(entry.getKey().toString(), entry.getValue());
        }
    }
}

Použití je pak naprosto triviální:

Inicializací tohoto springového beanu se vytvoří JNDI kontext, který obsahuje dvě JMS fronty a ještě connection factory, o které budu mluvit dále. Pokud použijete Spring není potřeba dále definovat jak se k JNDI kontextu připojit, což se běžně dělá pomocí property souboru jndi.properties umístěném na classpath.

JMS server

Dále tedy potřebujeme vytvořit instanci embedovaného JMS serveru. Pro mé účely jsem zvolil Apache ActiveMQ, který jde snadno inicializovat pomocí Springu, kde to vypadá následovně:

Popis co a proč je použito v předchozím listingu jsou přímo v něm, tedy ve stručnosti. Vytvořili jsme si instanci message brokeru, který nám nahrazuje vlastní JMS server v aplikačním serveru, následně jsme zadefinovali jednotlivé fronty, které jsou použity ve vlastní implementaci business logiky a konečně connection factory, která nám umožní napojení vlastních listenerů JMS front a zároveň přes ni budeme posílat testovací zprávy z našit unit testů.

Nyní bych se ještě vrátil k tomu, proč jsem do JNDI kontextu umístil weblogic.jms.XAConnectionFactory. Důvod je takový, že aplikace, které využívají JMS ve Weblogiku by měli referenci na connection factory získávat právě z JNDI.

Transaction Manager

Poslední věc, kterou musíme vyřešit bez aplikačního serveru je transaction manager – tedy „něco“, co nám bude řídit vlastní transakce. Na to jsem použil Bitronix Transaction Manager což je celkem mocná implementace transakčního manažeru. Pro naše účely bude použití triviální:

Závěrem

Kouzlo tohoto použití je v tom, že nyní stačí spustit unit test, který inicializuje springový kontext a zároveň načte definici kontextu vlastní aplikace, která právě využívá JNDI pro získání referencí na fronty a vše by mělo fungovat stejně, jako kdybychom tuto implementaci měli deployovanou přímo na aplikačním serveru. Pro úplnost dodávám ukázku definice kontextu přímo v aplikaci:

Na celém tomto cvičení je pěkné to, že jednoduchou springovou konfigurací jsme schopni rozchodit určitou část aplikace, která za normálních okolností nelze bez aplikačního serveru spustit, a my si tak můžeme napsat testy, které lze snadno spouštět bez neustálého a otravného redeploymentu na aplikační server.

   ...
    
   ...
        
            javax.xml
            jaxws-api
            2.0EA3
            provided
        
        
            com.sun.xml
            jaxws-rt
            2.0EA3
            provided
        
   ...
    
 

Jako scope těchto knihoven uvedeme, že jsou provided, což v praxi znamená, že knihovny budou použity pro kompilaci, ale nezaintegrují se do výsledného balíku. To proto, že Weblogic má tyto knihovny vlastní a naším cílem je použít právě implementaci aplikačního serveru.

Implementace webových služeb

Nyní si vytvořime a vystavíme vlastní webové služby. Služby budou definovány svým rozhraním a implementací. Rozhraní webové služby pak může vypadat třeba takto:

package eu.kratochvil.clanky.ws;

import javax.jws.*;

@WebService(targetNamespace = "http://schema.kratochvil.eu", name = "TestService")
public interface TestService {

    @WebMethod
    String sayHello(@WebParam(name = "name") String name);

}

A ještě implementace vlastní „business logiky“:

package eu.kratochvil.clanky.ws;

import javax.jws.WebService;

@WebService(endpointInterface = "eu.kratochvil.clanky.ws.TestService")
public class TestServiceImpl implements TestService {

    @Override
    public String sayHello(String name) {
        return "Hello " + name + "!";
    }
}

Z implementace je zřejmé, co naše služba dělá a není potřeba nějak složitě popisovat. Důležité jsou anotace WebService a WebMethod, které nám popisují vlastní rozhraní webové služby. Další anotace, jako je například WebParam a podobně složí k přesnému popsání a definici kontraktu webové služby a v budoucnu o tom napíšu nějaký článek. Do té doby doporučuji použít dokumentaci.

Posledním krokem je konfigurace našeho webového archívu. K tomu slouží znamý web.xml, který je klasicky umístěn v adresáři WEB-INF naší aplikace a ještě sun-jaxws.xml.

Soubor _web.xml_ bude obsahovat následující:

    
        
            com.sun.xml.ws.transport.http.servlet.WSServletContextListener
        
    
    
        jaxws
        com.sun.xml.ws.transport.http.servlet.WSServlet
    
    
        jaxws
        /testService
    

Tímto donutíme weblogic, aby vystavil servlet, který bude handlovat naše webové služby. Samozřejmě je možné použít v definici patternu znaky wildcard například takto:

    
        jaxws
        /ws/*
    

Pak budou servletem pro webové služby zpracován jakýkoliv požadavek, podle zadané masky (například /ws/users nebo /ws/loans).

Poslední konfigurační soubor, který musíme vytvořit, aby nám začaly korektně fungovat webové služby je sun-jaxws.xml, který je také umístěn v adresáři WEB-INF naší aplikace. Jeho podoba je následující:

Zabezpečení webové služby

Nyní se konečně dostáváme k tomu, jak zabezpečit webové služby pomocí standardních prostředků aplikačního serveru Weblogic. Nejprve se přihlásíme do konzole aplikačního serveru, kde se proklikáme na správu uživatelů přes menu pomocí položky Security Realms. Následně vybereme konkrétní realm (defaultně myrealm). Na záložce Users and Groups si založíme uživatele, kterým se chceme autentizovat pro využívání našich webových služeb.

V našem případě jsme si vytvořili uživatele test, kterého zařadíme do nějaké, námi vytvořené skupiny (například TestGroup).

Tímto máme základní konfiguraci aplikačního serveru hotovou a dalším krokem bude nastavení naší aplikace. Úplně nejjednodušší cestou je přidání následujících několika řádků do souboru web.xml:

    
        Security for WS
        
            WSPOST
            
            
            /testService
            POST
        
        
            TestGroup
        
    
    
        BASIC
        myrealm
    
    
        TestGroup
    

Zde definujeme, co chceme zabezpečit, jaká skupina uživatelů je oprávněna používat naše služby apod. Pokud náš projekt nyní zkompilujeme a nasadíme na aplikační server, měli bychom být dotázání na heslo ve chvíli, kdy se pokusíme zavolat naši webovou službu, což si můžete vyzkoušet například pomocí skvělého nástroje SoapUI.

V článku jsem záměrně nepoužíval nic jiného než jen JAX-WS, tedy žádný Spring Security ani nic podobného. Výhodou je, že se vám tímto přístupem zjednoduší deployment a hlavně získáte skvělé možnosti, jak vaší aplikaci zaintegrovat do firemní infrastruktury, bez složitého nastavování. Weblogic vám totiž nastaví admin serveru, který Vám zároveň vytvoří i nějakou roli, kterou pak následně budete ve své aplikaci využívat. No a správa uživatelů a hesel pro aplikace, které vaše služby budou využívat je také věc administrátora. Navíc lze samozřejmě aplikační server klientské aplikace nastavit tak, aby autentizaci prováděl pro aplikaci transparentně, takže odpadá složitá správa hesel na obou stranách, ale o tom zase někdy příště.

At first we have to create a keystore with a server certificate:

keytool-genkey-alias-jetty6 keyalg RSA-keystore target / jetty-ssl.keystore-storepass changeit-keypass changeit-DNAME "CN = Your Domain Name"

Then modify the configuration of the Maven pom.xml:

    org.mortbay.jetty
    maven-jetty-plugin
    
        /context
        5
        
            
                8080
                60000
            
            
                8443
                60000
                ${project.build.directory}/jetty-ssl.keystore
                changeit
                changeit
            
        
    

In the previous configuration, we defined the connection on port 8080 and port 8443 for SSL connections.

If we did not want to manually generate a server certificate, you can use other Maven plugin as shown below.

    org.codehaus.mojo
    keytool-maven-plugin
    
        
            generate-resources
            clean
            
                clean
            
        
        
            generate-resources
            genkey
            
                genkey
            
        
    
    
        ${project.build.directory}/jetty-ssl.keystore
        cn=localhost
        changeit
        changeit
        jetty6
        RSA
    

Now, when we invoke mvn jetty: run command, plug-in automatically creates a certificate that is then used in Jetty.

In this article we will create a self-signed certificate and then configure Tomcat to use the certificate. This configuration is enough for development.

For creating a server certificate, we will use keytool utility of the JDK.

On Windows

%JAVA_HOME%binkeytool-genkey-alias tomcat-keyalg RSA

On Linux

$JAVA_HOME/bin/keytool-genkey-alias tomcat-keyalg RSA

Then uncomment the file server. (XML configuration file of Tomcat) this section:

And thats all. Your server supports both in SLL and non-SSL connections.

Forcing SSL

In case you need to make all connections to your application has been secured with SSL, and even when a user enters the address only as http you can use the following.

Edit the web.xml file of your application by adding the following element:

        AppOverSSL
        
            
                ResourceName
            
            /
            POST
            GET
        
        
            CONFIDENTIAL
        
    

Don’t forget to define right port number for SSL in your server.xml file in attribute redirectPort of element that is defined your unsecured connection:

Now when users use non-secured connection is redirected on HTTPS connection.

So what was the problem? Once I tried to deploy to Tomcat, I got this error message:

java.lang.ClassNotFoundException: [Ljava.lang.String;
at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java: 1645)
at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java: 1491)
at com.sun.faces.config.ConfigureListener.configure (ConfigureListener.java: 635)
at com.sun.faces.config.ConfigureListener.configure (ConfigureListener.java: 422)
        ...

I tried various queries, but I was not successful. When I lost hope, I found the following link, which is described bug in JDK .

Before I come across this error, because the last one was a web application to JDK 1.5, where everything works fine. So if anybody knows this bug, I offer the „official workaround.

Just pass the JVM startup parameter:

-Dsun.lang.ClassLoader.allowArraySyntax = true

Nejprve trochu terminologie. Samotný termín Scrum je odvozen od názvu tzv. mlýnu, který sportovní fanoušci mohou znát z rugby. Pro nesportovce (jako jsem třeba já)- jedná se o takový útvar, kdy se hráči postaví do zástupu a rozehrávají hru tím, že se mezi ně hodí míč a oni se o něj poperou. Dalšími termíny jsou pigs (prasata) a chickens (kuřata). Pigs jsou programátoři a chicken ti nad nimi (projekťáci, architekti, sponzoři projektu…).

Celý proces vývoje se dělí na tzv. sprinty, což jsou období dlouhá několik týdnů (obyčejně tři až čtyři, ale může to být i delší). Pro tento sprint existuje plán úkolů, který se připraví do tzv. backlogu. V rámci sprintu si programátoři berou jeden úkol za druhým a postupně je realizují. Důležité je, aby doba realizace jednotlivých úkolů trvala ideálně jeden den. Navíc programátoři mohou do backlogu přidávat další úkoly, které je nutné realizovat během vývoje.

Jak to celé funguje?

Na počátku každého sprintu/etapy se svolá plánovací schůzka. Výsledkem této schůzky je plán pro příští sprint v takové formě, že s ním souhlasí každý člen týmu. Tento plánovací meeting je naplánován na celý den a povinně se účastní všichni „pigs“. Mohou být pozváni i zástupci z řad „chicken“, ti však nejsou oprávněni diskutovat. Je také vhodné pozvat zástupce z řad „business vlastníka“ (zadavatel nebo analytik)

Tento meeting může být rozdělen do dvou částí. V první části se prochází jeden úkol backlogu za druhým a diskutuje se o tom, jak jej implementovat, co to má vlastně dělat apod. Jak bylo již uvedeno, právě pro tuto fázi je ideální, aby se této části meetingu zúčastnili i zástupci z business analytiků. Ti jsou tak však pouze od toho, aby zodpovídali dotazy.

V druhé části se jednotlivé úkoly ohodnocují body podle náročnosti. K tomuto účelu jsme s výhodou využili klasických hracích karet, kdy každý z členů měl k dispozici karty v hodnotě A, 2, 3, 5, 8 a K. Karty (kromě K) značí bodovou hodnotu, Král znamená „nelze realizovat“. Členové týmu u každého požadavku naráz ukáží kartu s jejich předpokladem (naráz proto, aby se nemohli ovlivňovat). Tuto „hru“ můžeme nazvat třeba „hodnotící poker“. Důležité je, aby ve výsledku všichni členové týmu souhlasili s výslednou bodovou hodnotou. Tyto hodnoty se zapisují ke každému požadavku a stávají se závaznými. V našem týmu jsme tyto dvě etapy sloučili do jedné a přišlo mi to efektivnější.

Při hodnocení je důležité určit si převodní jednotku – tedy to, co vlastně znamená právě jeden bod. U nás je problém, že se nám nepodařilo úkoly rozdělit na tak atomické úkoly, že by měl jeden zabrat maximálně jeden den. Stanovili jsme tedy, že jeden bod znamená 0,5MD.

Dalším důležitým krokem určení tzv. velocity, což je zjednodušeně řečeno výkonnost týmu. Ta se počítá v různých jednotkách. V našem případě ji přepočítáváme na body, které reflektují pracnost úkolu, kterou jsme si určili na plánovacím meetingu pomocí hodnotícího pokeru. Vlastní velocita pak říká, kolik těchto bodů jsme schopni zrealizovat během jedné iterace (sprintu).

Během vlastní iterace(sprintu) se každý den uspořádá schůzka, které se říká scrum a vede ji Scrummaster. Délka této schůzky je striktně omezena na 15 minut. Během této schůzky každý vývojář odpoví na tři otázky:

• Co jsi udělal od poslední schůzky?
• Co plánuješ udělat dnes?
• Vyskytly se nějaké překážky, které bránily dokončení Tvého předhozího úkolu?

Důležité je, že na této schůzce se případné problémy pouze identifikují, jejich řešení probíhá mimo scrum. Důvod je logický – nebudeme zdržovat ostatní členy týmu záležitostmi, které se jich přímo nedotýkají. A poslední věc: Scrumy je potřeba provádět ve stoje. Důvod je jednoduchý, relativně snadno se tím zabrání tomu, aby se účastníci scrumu rozpovídali (pokud nezabírá pořádat scrum ve stoje, pořádejte ho třeba v ruštině-uvidíte, že všichni budou rázem stručnější). Pokud je více týmů/scrumů, pořádá se ještě tzv. Scrum of Scrum. Na této schůzce Scrummasteři reportují problémy a status ze „svých“ scrumů. A ještě jedna důležitá věc ke scrumům. Scrumy jsou určeny pouze pro členy týmů-projekťáci, sponzoři apod. se zúčastnít mohou, ale nesmí do schůzky nikterak zasahovat.

Na konci sprintu se pak uspořádá schůzka, kde se zhodnotí uplynulá iterace a diskutují se problémy, které se vyskytly během právě uplynulé iterace a hledá se jejich řešení.

Výhodou této metodiky je to, že zapojíme programátory přímo do procesu vývoje, navíc programátoři získají část zodpovědnosti za realizaci díla, termíny a kvalitu. Díky tomu nemají pocit, že by byli jen cvičenými opicemi. Další celkem důležitou záležitostí je fakt, že manažeři projektu ztratí část pravomocí, které se deleguje přímo na projektový tým. Manager pak má pouze funkci kontrolní, což ne vždy může být pro projektového manažera akceptovatelné. S tím se pojí nejdůležitější věc na celém procesu zavedení této metodiky. Vedení projektu musí plně důvěřovat vývojovému týmu, tomuto procesu vývoje a nesnažit se zavádět do této metodiky postupy, které znají ze své běžné praxe.

Uvidíme na konci projektu, jestli nám tato metodika pomohla lépe a s větší efektivitou zvládnout tu obrovskou horu práce, kterou realizujeme-určitě pak podám report. A co Vy? Používáte nějaké agilní metodiky vývoje (nebo i konzervativní)? Pokud ano, jaké s nimi máte zkušenosti?

long startTimeMillis = System.currentTimeMillis();

// do something ...

long endTimeMillis = System.currentTimeMillis();
log.debug("Volani trvalo: " + (endTimeMillis - startTimeMillis) + " ms");

Ve springu tedy existují již zmíněné „stopky“. Výhodou jejich použití je zejména zvýšení čitelnosti kódu. Jen upozornění – StopWatch není thread safe (což znamená, že je nutné pro každé měření použít novou instanci této třídy).

Příklad použití:

StopWatch stopWatch = new StopWatch("PrikladPouziti");
try {
    try {
        stopWatch.start("Krok1");
        // do something ...
    } finally {
        stopWatch.stop();
    }
    try {
        stopWatch.start("Krok2");
        // do something else ...
    } finally {
        stopWatch.stop();
    }
} finally {
    log.info(stopWatch.toString());
}

Ten nejzákladnější výstup pak bude následující:

INFO StopWatchTest:34 - StopWatch 'PrikladPouziti': running time (millis) = 437;
                                        [Krok1] took 250 = 57%;
                                        [Krok2] took 187 = 43%

Jenže tahle utilitka umí mnohem více, ale to už nechám na objevení každého z vás.

Vím, že podobná funkčnost je i v balíku Apache Commons Lang, ale tohle je článek o Springu

[poll id=“1″ type=“result“]

Jak pak v unit testech toto vyřešit? Ideální by bylo, vytvořit si nějakým způsobem vlastní JNDI kontext, který pak bude naše aplikace využívat. Spring nám k tomu nabízí rozumné prostředky. Pojďme se tedy podívat, jak na to.

/**
 * InitialContext factory for test purposes - it simulates JNDI context.
 */
public class TestInitialContextFactory implements InitialContextFactory {
    /**
     * Creates an Initial Context for beginning name resolution.
     * Special requirements of this context are supplied
     * using environment.
     *

     * The environment parameter is owned by the caller.
     * The implementation will not modify the object or keep a reference
     * to it, although it may keep a reference to a clone or copy.
     *
     * @param environment The possibly null environment
     *                    specifying information to be used in the creation
     *                    of the initial context.
     * @return A non-null initial context object that implements the Context
     *         interface.
     * @throws javax.naming.NamingException If cannot create an initial context.
     */
    public Context getInitialContext(Hashtable environment) throws NamingException {

        // Vytvorime si datasource, ktery chceme publikovat v JNDI
        DriverManagerDataSource ds = new DriverManagerDataSource(
                "oracle.jdbc.driver.OracleDriver",
                "jdbc:oracle:thin:@localhost:1521:TES_DB",
                "test",
                "password");

        try {
            // Tady zacneme tvorit vlastni kontext
            SimpleNamingContextBuilder builder = new SimpleNamingContextBuilder();

            // Pridame nas datasource do kontextu
            builder.bind("jdbc/MyDataSource", ds);

            builder.activate();
            return builder.createInitialContextFactory(null).getInitialContext(null);
        } catch (NamingException e) {
            e.printStackTrace();
        }
        return null;
    }
}

Nyní už jen zbývá si v aplikaci nastavit, jak se má kontext vytvářet. To zajistíme konfigurací v souboru jndi.properties:

java.naming.factory.initial=eu.kratochvil.blog.ukazky.TestInitialContextFactory

Jak tuto problematiku řešíte na svých projektech? Budu rád, když mi odpovíte prostřednictvím komentáře.

org.apache.commons.dbcp.SQLNestedException: Cannot create JDBC driver of class 'oracle.jdbc.driver.OracleDriver' for connect URL 'http://maven.apache.org'
	at org.apache.commons.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1150)
	at org.apache.commons.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880)
	at org.hibernate.ejb.connection.InjectedDataSourceConnectionProvider.getConnection(InjectedDataSourceConnectionProvider.java:46)
	at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)

To nejdivnější bylo to, že se aplikace snažila připojovat na URL: ‚http://maven.apache.org‘ místo toho, aby se připojovala na URL, která byla v konfiguraci.

Dalším pátráním jsem zjistil, že se v „targetu“, tedy místě, kam se ukládají zkompilované zdrojáky, vyskytuje soubor, definující springový kontext, a v něm se vyskytovalo následující (v property url):

Jak se tam to mohlo dostat, když ve zdrojáku je něco úplně jiného:

Začali jsme tedy pátrat, jak se tam mohl tento řetězec dostat, a měla to na svědomí tahle konstelace:
V POMu projektu byla definováno něco takového:

    4.0.0
    cz.csas.clf
    clf-micros-product-configurator
    war
    ${version.micros}
    clf-micros-product-configurator
    http://maven.apache.org 
       ...
    
        
           ...
            
                src/main/resources
                true
            
        
          ...

Co je na předchozím POMu zajímavých několik věcí. Je nastaveno filtrování resourců pro adresář, kde je uložen soubor s konfigurací a v projektu byl definován parametr url.

Díky chybě v mavenu došlo k nahrazení placeholderu ${jdbc.url} za property url, která navíc nebyla property

Naštěstí pomohl upgrade na nejnovější verzi mevenu (2.2.1), kde se chyba už nevyskytla. Zvláštní je, že jsem v žádných release notes nebo něčem podobným nenašel o tomto problému žádnou zmínku.