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

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.

import ...

@WebService(targetNamespace = "http://schemas/wsdl")
@SOAPBinding(style = SOAPBinding.Style.DOCUMENT, use = SOAPBinding.Use.LITERAL)
public interface Documentation {

    @WebMethod
    @WebResult(name = "receiveDocument")
    @XmlMimeType("application/octet-stream")
    DataHandler getDocument(
            @WebParam(name = "documentId",
                    targetNamespace = "http://schemas/wsdl",
                    mode = WebParam.Mode.IN) Integer documentId);
}

a následná implementace:

import ...

@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Pokud chceme používat SOAP attachmentů, můžeme využít implementace od SUNu (vlastně teď Oraclu). Souhrnně se této technice říká Message Transmission Optimization Mechanism (zkráceně MTOM) a právě SUN nabízí pro tyto účely implementaci pro JAX-WS (upozorňuji, že třeba v AXISu to funguje úplně jinak).

Vše se tváří naprosto triviálně – stačí jako jeden výstupní parametr použít s typem javax.activation.DataHandler, nastavit u tohoto parametru pomocí javax.xml.bind.annotation.XmlMimeType správný content type a celou třídu oanotovat pomocí @MTOM. Vše by mělo zázračně začít fungovat. Jenže ono to nefunguje.

Ač o tom není v dokumentaci ani zmínka záleží na tom, kde se anotace umístí. Tato anotace se totiž neumisťuje do interface, kde bych to očekával, ale přímo do třídy, která implementuje naše rozhraní této webové služby. Abychom nám začali fungovat attachmenty, upravíme příklad, který jsem uvedl na začátku tohoto článku:

import ...

@MTOM
@StreamingAttachment(parseEagerly = true, memoryThreshold = 40000L)
@WebService(serviceName = "Documentation", endpointInterface = "Documentation")
@SchemaValidation
public class DocumentationImpl  implements Documentation {

    @Override
    public DataHandler getDocument(Integer documentId) {
        return getService().getDocument(documentId);
    }
}

Přidal jsem dvě anotace: @MTOM a @StreamingAttachment(...). Ta první aktivuje tuto funkčnost a od nyní se všechny atributy typu DataHandler budou přenášet jako SOAP attachment. Anotaci @StreamingAttachment(...) využijeme v případě, že budeme přenášet skutečně velké soubory a posílání souboru nám bere moc paměti. A ještě jedna chytrá věc-v anotaci @MTOM je parametr threshold, který říká, od jaké velikosti se daný element pošle jako SOAP attachment a kdy se pošle přímo v elementu samotné zprávy.

Na závěr ještě ukázku, jak pak vypadají data ze služby:

HTTP/1.1 200 OK
Date: Sat, 06 Feb 2010 07:46:28 GMT
Transfer-Encoding: chunked
Content-Type: multipart/related;start="";type="application/xop+xml";boundary="uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e";start-info="text/xml"
X-Powered-By: Servlet/2.5 JSP/2.1

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: 
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Transfer-Encoding: binary



  
    
      
        
      
    
  

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e
Content-Id: <383e4726-8e85-4a46-a917-23811ec4ef3e@example.jaxws.sun.com>
Content-Type: application/pdf
Content-Transfer-Encoding: binary

%PDF-1.4
.
.
.
%%EOF

--uuid:783e56c7-ff09-40d8-91cd-d0ec0ce9555e-

Technologická platforma

Java EE 6 přináší nový koncept profilů a konfigurovatelnosti, které nyní mohou být designovány až na úroveň jednotlivých tříd. Co to vlastně je? Profil je v podstatě podmnožina Javy EE, která může být navíc doplněna o další technologie a toto vše slouží pak pro plnění určité úlohy. Například v aktualním releasu Javy EE byl uvolněn profil WebProfile, což je jakési redukované SDK, které slouží pouze pro provozování webových aplikací a „netahá“ na server věci,které pro provoz webové aplikace nepotřebuji (EJB, messaging apod.).

Rozšiřování platformy

Nová verze této platformy poskytuje mnohem více možností, jak rozšířit funkčnost SDK. Tuto oblast jsem však hluboce nestudoval, a tak pojďme dále.

Jednoduchost vývoje

Toto je asi oblast, která zajímá každého vývojáře, protože by mu měla usnadnit práci. Byla rozšířena sada nových anotací, které může vývojář využívat. Pro definovánáí webových komponent přibyla možnost snadné deklarace servletů (@WebServlet) nebo filtrů (@WebFilter). Dále byla standardizováno dependency injection, díky čemuž dojde ke sjednocení zápisu napříč všemi frameworky.

Další příjemnou záležitostí je to, že došlo ke zjednodušení požadavků na jednotlivé javové packages. Což v praxi například znamená, že dnes můžeme do *.war přibalit implementaci EJB.

Další nové funkčnosti, které bych rád představil můžeme rozdělit do následujících kategorií: Prezentační vrstva, dependency injection a data validation, služby a perzistenční vrstva.

Prezentační vrstva

Za nejzásadnější změnu považuji implementaci specifikace Servlet 3.0. Tato nová specifikace, kromě spousty jiného, přináší podporu asynchronního zpracování nebo tzv. long-lived spojení.

Další novinkou na prezentační vrstvě je nová specifikace JSF. JSF 2.0 zjednodušuje tvorbu jednotlivých stránek pomocí faceletů, šablon a pod. Výhodou je, že tyto funkšnosti byly konečně standardizovány a neřeší si to každý framework po svém. Dále se objevila vestavěná podpora Ajaxu a anotací.

Součástí release Java EE 6 je i nová specifikace JSP 2.2.

Dependency Injection a Data Validation

The Contexts and Dependency Injection for the Java EE Platform (CDI) je definován v JSR 299 a zavádí standardizovanou formu dependency injection. CDI dále zjednodušuje interoperabilitu mezi JSF a EJB, kdy umožňuje použití EJB místo managed beans.

Bean Validation (JSR 303) zavádí validace, které byly standardizovány a navíc mohou být sdíleny mezi všemi vrstvami aplikace (webová vrstva, služby nebo doménový model).

Služby a konponenty

Novinkou je určitě nová verze EJB 3.1 a nativní podpora RESTových služeb.

V EJB 3.1 nyní kromě spousty jiného najdeme:

• Není dále potřeba vytvářet interface pro jednotlivé EJB
• Nová anotace, kterou je možné definovat singleton (@Singleton)
• Stejně jednoduše jako singleton se zajistí asynchronní služby. Na beanu se pouze použije anotace @Asynchronous.

Perzistenční vrstva

V nové vezi Javy EE se konečně dočkáme nové verze JPA 2.0. Došlo k rozšíření JPQL a nabízí zcela nové API pro definici kriterií (Criteria API). V nové verzi JPA dále programátor získává přístup k vlastnímu metamodelu.

Zajímavostí je zavedení podpory kolekcí. Slouží pro to dvě anotace @ElementCollection(definuje vlastní objekt, který má být v dané kolekci) a @CollectionTable (popisuje vlastní tabulku, kde bude ona kolekce uložena).

Snad se mi alespoň z části podařilo popsat ty, z mého pohledu, nejzajímavější novinky v Javě EE. Pokud jste narazili na další chytré novinky, budu rád za to, když se o ně podělíte v komentářích.

Definice říká, že se jedná o anonymní funkci, která není izolována od okolního světa tak, jak to známe běžně v Javě. Navíc má takováto funkce přístupné všechny proměnné, které jsou přístupné ve scope, ve kterém byla tato „funkce“ volána.

Tolik definice. Vlastní closures vznikly v jazyce Lisp a postupně se rozšířily do dalších jazyků – zejména funkcionálních. Kolega mi doporučil, abych se podíval na jazyk Ruby, který je prý dokonalý – uvidíme. V rámci studia Ruby se pokusím closures pochopit nejprve v jazyce, kde to již funguje – tedy právě v Ruby. A pak se podíváme na to, jak by se to dalo používat v Javě.

Začněme příkladem, který bude simulovat funkci unixové aplikace grep. V Ruby se to dá implementovat celkem snadno:

IO.foreach("test.txt") do |line| 
	if (line =~ /total: (d+)/)
		puts $1;
	end
end

Tento kód projde soubor test.txt a vypíše řádky, které ty, které odpovídají patternu. První příjemné překvapení v Ruby je to, jak některé věci jdou snadno. Otevření souboru a jeho proiterování po řádcích zajistí příkaz IO.foreach.

Pojďme dále. Zapouzdříme si toto volání do samostatné operace, která bude očekávat na vstupu název souboru a pattern, který budeme vyhledávat.

class File
	def File.grep(filename, pattern)
		IO.foreach(fileName) do |line|
			if matchData = pattern.match(line)
				yield matchData;
			end
		end
	end
end
	
File.grep("test.txt", /total: (d+)/) { |matchData| puts matchData[1]; }

Teď už to vypadá zajímavěji. Voláme funkci File.grep s tím, že definujeme funkci, která se má provést uvnitž volané funkce. Jak toto zajistit? Všimněte si příkazu yield. Ten zajistí předání proměnné matchData do closure a její vyvolání. Doufám, že jsem to popsal dostatečně srozumitelně.

Zastánci těchto konstrukcí říkají, že tyto konstrukce velmi zjednodušují vývoj. Velmi častým příkladem je konstrukce foreach. Argumentem je to, že v Javě se konstrukce foreach objevila teprve v Javě 5. Kdyby měla closures, nebylo by nutné foreach vůbec řešit. Když to srovnáme s Ruby, zjistíme, že tento jazyk tyto konstrukce vůbec neřeší. Nemusí, protože tyto věci jsou řešeny právě prostřednictvím closures.

Dalším pádným argumentem pro closures je použití patternu command v Javě, kdy dnes musíme v parametru metody předávat novou instanci objektu.

Tolik tedy výhody. Na první pohled se zdá, že closures jsou skvělou věcí. Jenže když se na to podíváme z jiného úhlu pohledu, nebudou se tyto konstrukce zdát tak dokonalé.

První věcí je, že se mění syntaxe jazyka. Podle mého názoru musí být pro změnu syntaxe jazyka opravdu pádný důvod s tím, že současné řešení je naprosto nedostatečné (například annotace). Změna syntaxe totiž přináší spoustu nepříjemností. Kromě toho, že ztrácíme zpětnou kompatibilitu, komplikujeme život programátorům tím, že se snižuje čitelnost tohoto kódu.

Další věcí je že tyto konstrukce patří dle mého názoru spíše do světa funkcionálních jazyků, boří striktnost objektového programování. Navíc se podle všeho Java bude chovat tak, že onu konstrukci closure převede do „staré konstrukce“. Díky tomu se stále častěji budeme setkávat s tím, že nám bude docházet PerGemSpace, protože pokud si programátoři closures oblíbí a začnou je masivně používat, budou vznikat mraky objektů.

Jak se v Javě closures budou používat? Pojďme se tedy podívat na jednoduchý příklad, který na příkladu CollectionUtils ukazuje použití closures v Javě.

public Collection getAdminList(Collection users) {
    return select(users, {User user =>
        user.isAdmin()
    });
}

/**
 * Vraci seznam objektu T z kolekce, kde closure vraci true.
 *
 * @param source kolekce objektu T nesmi byt null
 * @param predicate vraci true pro zadany objekt T, ktery ma byt ve vysledne kolekci
 * @return vraci seznam objektu T z kolekce, kde closure vraci true
 */
public static  Collection select(Collection source,
        {T=>Boolean} predicate) {
    Collection result = new ArrayList();
    for (T o : source) {
        if (predicate.invoke(o)) {
            result.add(o);
        }
    }
    return result;
}

A ještě jeden příklad použití. Bývá jím použití komparátoru jako closure. Díky tomu získáme možnost řadit si objekty v kolekci podle toho, jak potřebujeme.

public static void sortByTitle(Collection books) {
    sort(books, {Book book =>
        book.getTitle()
    });
}

/**
 * Sorts the given list of T objects, using the block to compare
 * individual elements of the list.
 *
 * @param l
 *            list to be sorted
 * @param block
 *            returns the value of a property of the given T object
 *            that should be used for sorting
 */
public static  void sort(List l,
        {T=>Comparable} block) {
    sort(T o1, T o2 : l) {
        block.invoke(o1).compareTo(block.invoke(o2));
    }
}

To, zda jsou closures dobrá nebo špatná věc, nechám na uvážení každého. Osobně s tímto konceptem nejsem smířen a nelíbí se mi. Na druhou stranu nepopírám, že rozumné použití closures může vést ke zjednodušení kódu aplikace. Otázkou zůstává, zda tyto změny syntaxe nepovedou k tomu, aby se z Javy stal jazyk typu PHP…

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.

javax.xml.ws.WebServiceException: javax.net.ssl.SSLKeyException: 
[Security:090477]Certificate chain received from mw.company.com - 10.0.0.1 
was not trusted causing SSL handshake failure.

Jak z toho wen? Musíme náš server naučit pracovat s certifikátem protistrany. Weblogic pro práci s certifikáty využívá několik cest. Já si pro dosažení kýženého cíle zvolil standardnější cestu, a to přes java key store.

Začneme s tím, že si vytvořime náš serverový certifikát:

keytool -genkey -file ./app_server.jks

Tím se nám na aplikačním serveru vytvoří keystore s naším serverovým certifikátem. Následně musíme získat veřejný certifikát protistrany. Buď nám jej pošle hodný správce serveru nebo si jej stáhneme (například pomocí webového browseru). Tento server si naimportujeme do jiného key store:

keytool  -keystore ./micros_trust.jks -import -file ./alsb.cer

(soubor alsb.cer obsahuje veřejný klíč protistrany)

Nyní už nám nezbývá nic jiného, než nakonfigurovat Weblogic. V menu zvolíme Enviroment->Servers. Vybereme si node, na kterém máme nadeployovanou aplikaci a následně zvolíme záložku Keystores.

V combo boxu zvolíme volbu Custom Identity and Custom Trust.

Následně si nastavíme cesty v jednotlivým keystore, vyplníme typ (JKS) a hesla.

A to je vše. Od této chvíle bude Weblogic věřit pouze certifikátům, které máme v našem keystore. Navíc budou SSL spojení na náš server zabezpečena certifikátem, který jsme si vyrobili v prvním kroku.