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.

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.

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.

• jaxb-api-2.1.jar
• jaxws-api-2.1-1.jar

Poté je nutné modifikovat systémovou proměnnou MAVEN_OPTS takto:

set MAVEN_OPTS=-Xbootclasspath/p:%M2_HOME%endorsedall.zip

Pozn. Já ještě musím zvednout paměť pro JRE, takže má osobní konfigurace vypadá takto:

set MAVEN_OPTS=-Xbootclasspath/p:%M2_HOME%endorsedall.zip -Xms64m -Xmx512m

Pakliže máte srávně nainstalovaný Maven a korektně nastavenou proměnnou M2_HOME, nyní by JRE mělo brát obsah souboru all.zip v potaz a JAXWS API 2.1 začne fungovat. Podobně si můžete přibalovat další JARy – podle toho, jak bude potřeba.