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.

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.

Tomu řešení se říká AOP a Spring má vestavěno několik zajímavých aspektů.

Začněme příkladem použití:

Výše uvedená konfigurace zajistí to, že všechny beany, které jsou ve stejném aplikačním kontextu a jejichž názvy končí řetězci „BusinessService“ a nebo „Bean“ (parametr beanNames u BeanNameAutoProxyCreator) budou automaticky obaleny dynamickou proxy, která bude aplikovat CustomizableTraceInterceptor. “’Tento interceptor zajistí“‘, že:
* bude zalogováno volání jakékoliv public metody beany včetně vstupních argumentů
* bude zalogována výstupní hodnota včetně času, které vykonání metody
* v případě ukončení volání vyjímkou, bude tato vyjímka také zalogována
* logování bude na TRACE levelu a pokud je nastaveno logování pouze na vyšší úrovni, nebude volání metod v podstatě nijak výrazně zpomaleno
* zalogované záznamy budou aplikovat původní název třídy jako název použitého loggeru (tzn. ignorují se názvy proxy class i interceptoru)

Zajímavých interceptorů připravených rovnou k použití poskytuje Spring více:

• ConcurrencyThrottleInterceptor – omezuje paralelní volání metod dané instance
• PerformanceMonitorInterceptor – umožňuje jednoduché logování výkonnostních otisků (tzn. jak dlouho trval běh konkrétního volání metody instance)
• DebugInterceptor – jednoduché (fixní) logování metod dané instance
• CustomizableTraceInterceptor – umožňuje customizovatelné transparentní logování volání metod dané instance

Jednoduché natolik, že LocalStatelessSessionProxyFactoryBean ví, jak vytvořit instanci Beanu, přes Home rozhraní, na které ukazuje JNDI. Existuje několik různých proxy factory, pro různé druhy EJBček.

V EJB3 je situace jiná, protože vůbec nemusíte implementovat Home rozhraní. Důsledkem je, že nemůžete používat LocalStatelessSessionProxyFactoryBean. Namísto toho, používáte standardní JndiObjectFactoryBean:

Princip je jednoduchý: najde EJB v JNDI, zaregistruje se jako spring Bean, a pak se přes autowiring předá tato reference do jiného beanu. To zní dobře.

Má to jeden zásadní problém: musíte definovat EJBčka v XML. Jednou z obrovských výhod EJB 3 je to, že nemusíte řešit žádné XML soubory (známe XML hell z EJB 2.x). A to se mi nechce měnit.

Naštěstí je tu řešení: BeanPostProcessors. BeanPostProcessors vám umožňuje dělat věci, nad jednotlivými beany po jeho vytvoření. A to třeba vyhledání metod, anotací apod. Například anotace @EJB

Zde je kód:

/** Look for EJB3-style annotations, and provide the corresponding values from the container. */
public class EjbBeanPostProcessor implements BeanPostProcessor {

  public Object postProcessAfterInitialization(Object bean, String beanName)
  throws BeansException {
    // do nothing; the EJBs are configured before initialization.
    return bean;
  }

  public Object postProcessBeforeInitialization(Object bean, String beanName)
  throws BeansException {
    Class beanClazz = bean.getClass();
    for (Method method : beanClazz.getMethods()) {
      if (method.isAnnotationPresent(EJB.class)) {
        setEjbRef(bean, method);
      }
    }
    return bean;
  }
  
  private  void setEjbRef(T bean, Method setter) {
    Class ejbClass = determineBeanClass(setter);
    Object ejbBean = lookupBean(ejbClass, determineJndiName(ejbClass, setter), bean);
    invoke(bean, setter, ejbBean);
  }
  
  /**
   * Determine the JNDI name for the EJB. By default, we assume that it is the simple class
   * name, but we allow the setter method to override this, using the 'mappedName' attribute.
   */
  private String determineJndiName(Class ejbClass, Method setter) {   
    EJB ejbAnnotation = setter.getAnnotation(EJB.class);
    if (ejbAnnotation.mappedName().equals("")) {
      return ejbClass.getSimpleName();
    }
    return ejbAnnotation.mappedName();
  }

  private Object lookupBean(Class ejbClass, String beanName, Object bean) throws BeansException {
    try {
      return new InitialContext().lookup("java:comp/env/ejb/" + beanName);
    } catch (NamingException e) {
      throw new EjbBeansException(bean, "Could not resolve EJB " + beanName, e);
    }
  }

  /**
   * Determine the type of the EJB. This is used to determine the JNDI name to look up. This
   * would normally be the type of the argument to the setter, but the EJB spec allows this
   * to be overriden (presumably to a subclass)
   */
  private Class determineBeanClass(Method setter) {
    EJB ejbRefAnnotation = setter.getAnnotation(EJB.class);
    if (ejbRefAnnotation.beanInterface() != null && 
        Object.class.equals(ejbRefAnnotation.beanInterface()) == false) {
      return ejbRefAnnotation.beanInterface();
    }
    Class otherBeanClass = setter.getParameterTypes()[0];
    return otherBeanClass;
  }

  private  void invoke(T bean, Method method, Object ... args) {
    try {
      method.invoke(bean, args);
    } catch (IllegalArgumentException e) {
      throw new EjbBeansException(bean, "Could not set EJB", e);
    } catch (IllegalAccessException e) {
      throw new EjbBeansException(bean, "Could not set EJB", e);
    } catch (InvocationTargetException e) {
      throw new EjbBeansException(bean, "error setting EJB reference", e.getCause());
    }
  }

  /** Simple exception detailing the type of problem that occured. */
  private static class EjbBeansException extends BeansException {
    public EjbBeansException(Object bean, String message, Throwable cause) {
      super(message + " [bean class: " + bean.getClass().getName() + "]", cause);
    }
  }
}

Tento krásný BeanPostProcessor ve Springu ho aktivujeme celkem snadno:

Teď si prostě přidáte anotaci @EJB odkazy do svého Spring beanu, a on se kouzelně naplní. Do žádného XML není potřeba nic definovat. Jak krásné.