Michał Mech - W stronę Java

Usługi sieciowe – szybki efekt dzięki CXF

Michał Mech — Mon, 01 Feb 2010 23:52:48 +0000

Mój nauczyciel matematyki zwykł mówić, że “dobry matematyk to leniwy matematyk”. Zwykł tak komentować karkołomne metody obliczeń stosowane w sytuacjach kiedy można coś zrobić prościej. Lubię tę zasadę stosować również w odniesieniu do programowania.

Kiedy przyszło mi niedawno stworzyć usługi sieciowe (ang. Web Services) w Javie pomyślałem o Apache CXF. CXF jest szkieletem (ang. framework) pomagającym budować usługi korzystające z API takich jak JAX-WS i zdolne do komunikacji używając protokołów SOAP, REST czy HTTP.

Kontrakt

Przy tworzeniu usług sieciowych można stosować dwa podejścia:

WSDL first – najpierw tworzymy kontrakt, jakim jest plik WSDL opisujący nasze usługi a następnie przechodzimy do implementacji;
Implementation first – najpierw implementujemy logikę a później wystawiamy ją w formie usług sieciowych i generujemy WSDL;

Ja osobiście lubię zabrać się do pracy kiedy wiem co mam zrobić, ot takie dziwactwo. Stąd zakładam sytuację kiedy najpierw definiujemy kontrakt jaki realizowała będzie moja usługa sieciowa.
Dla zaprezentowania CXF utworzę bardzo prostą usługę sieciową, która będzie odpowiadała na zadane pytanie. Zakładam otrzymać ciąg znaków i ciąg znaków odeślę w odpowiedzi (taka pogawędka).

Kontrakt WSDL mógłby wyglądać tak (talk.wsdl):

Aplikacja

Teraz przyda się Maven, którym utworzymy szybko projekt aplikacji internetowej i zajmiemy się zależnościami. Sam Maven nie jest przedmiotem tego wpisu więc wspomnę tylko, że zaczynamy od polecenia:

mvn archetype:generate

Po utworzeniu projektu plik talk.wsdl umieszczamy w zasobach naszego projektu: src/main/resources/
Oto kompletny plik POM, który zawiera zależności oraz informacje o budowaniu projektu:



	4.0.0
	pl.michalmech.cxfdemo
	wsdl-first
	1.0-SNAPSHOT
	war

	CXF Demo - WSDL-first

	
		
			org.apache.cxf
			cxf-rt-core
			2.2
		
		
			org.apache.cxf
			cxf-rt-frontend-jaxws
			2.2
		
		
			org.apache.cxf
			cxf-rt-transports-http
			2.2
		
		
			org.apache.cxf
			cxf-common-utilities
			2.2
		
		
			org.springframework
			spring-core
			3.0.0.RELEASE
		
		
			org.springframework
			spring-beans
			3.0.0.RELEASE
		
	
	
		
			
				org.apache.maven.plugins
				maven-compiler-plugin
				
					1.5
					1.5
				
			

			
				org.apache.cxf
				cxf-codegen-plugin
				2.1.4
				
					
						generate-sources
						generate-sources
						
							${basedir}/src/main/java
							
								
									src/main/resources/talk.wsdl
								
							
						
						
							wsdl2java
						
					
				
			

			
				org.mortbay.jetty
				maven-jetty-plugin
				6.1.22

Widzimy zależności od pakietów CXF oraz pluginu CXF Codegen, który odwali za nas trochę roboty. Spring Framework dostarczy nam swój kontener IoC a serwer Jetty przyda się do testowania aplikacji.

No dobrze czas na magię. Wspominałem o leniach no to wypadałoby teraz osiągnąć coś niewielkim nakładem pracy, co niniejszym czynimy wykonując polecenia:

mvn generate-sources
mvn eclipse:clean eclipse:eclipse

Pierwsze polecenie wygeneruje nam kod języka Java na podstawie kontraktu WSDL. Drugie utworzy pliki konfiguracyjne potrzebne do importu projektu do mojego ulubionego IDE. Na obecnym etapie projekt powinien wyglądać tak:

Zajmijmy się teraz implementacją naszej usługi. Nie będzie zbyt wyszukana:

package pl.michalmech.service;

import pl.michalmech.service.talk.Talk;

public class TalkImpl implements Talk {

	public String ask(String question) {
		return "I don't know answer for \"" + question + "\" question.";
	}
}

Aby nasza usługa sieciowa działała przyda nam się zdefiniowanie kontekstu aplikacji (applicationContext.xml) oraz deskryptora rozmieszczenia (web.xml):

src/main/webapp/WEB-INF/applicationContext.xml

src/main/webapp/WEB-INF/web.xml




	
		contextConfigLocation
		WEB-INF/*Context.xml
	

	
		org.springframework.web.context.ContextLoaderListener
	

	
		dispatcher
		org.apache.cxf.transport.servlet.CXFServlet
		1
	

	
		dispatcher
		/*

I znów nie musimy martwić się o servlet ponieważ o wszystko zadba za nas CXF.

Uruchomienie

Teraz przyda nam się Jetty. Uruchamiamy aplikację poleceniem:

mvn jetty:run

oraz sprawdzamy rezultaty w przeglądarce. Wyniki działania aplikacji powinny być następujące:
http://localhost:8080/wsdl-first

http://localhost:8080/wsdl-first/service/talk?wsdl
To wszystko co potrzebne było do uruchomienia prostej usługi sieciowej. Przykład jest trywialny i dotyka ledwie czubka góry lodowej zarówno możliwości CXF jak i zastosowań zamych usług sieciowych więc zachęcam do zabawy.

Do pobrania: wsdl-first.zip

Spring, JAXB oraz Maven – czyli łatwe i przyjemne budowanie oraz konfigurowanie aplikacji

Michał Mech — Tue, 29 Sep 2009 22:19:00 +0000

Jakiś czas temu stanąłem przed koniecznością napisania aplikacji, która miała mieć możliwość konfigurowania z zewnętrznego pliku XML. Wybór formatu XML był podyktowany złożoną strukturą informacji, które należało wczytać. Aplikacja była oparta o szkielet Spring a zależnościami i budowaniem zajmował się Maven. Pozostał wybór narzędzia, które przeniesie mi w wygodny sposób dane z pliku XML do aplikacji. Wybór padł na JAXB – Java Architecture for XML Binding. JAXB to technologia pozwalająca wygenerować klasy języka Java, które pomogą nam odwzorować plik XML na obiekty.

Nie będę się skupiał nadto na opisie każdego z wymienionych narzędzi lecz skupię się raczej na pokazaniu jak zaprząc je razem do działania.

Przykładowa aplikacja

Zacznę od przygotowania niewielkiej aplikacji testowej. W tym celu w konsoli wpisujemy:

mvn archetype:generate

Powyższe polecenie zainicjuje kreator, w którym wybieramy 15 (maven-archetype-quickstart) a później podajemy szczegóły. Ja podałem:

Define value for groupId: : pl.michalmech
Define value for artifactId: : jaxb-example
Define value for version:  1.0-SNAPSHOT: :
Define value for package:  pl.michalmech: :

Aplikacja testowa jest gotowa a po wykonaniu polecenia:

mvn eclipse:eclipse

można wygodnie zaimportować ją do Eclipse‘a.

Kolejnym krokiem jest konfiguracja zależności aplikacji w pliku POM. Jedyne czego potrzebujemy to Spring dlatego wyrzuciłem zależność od JUnit‘a oraz folder src/test.


    4.0.0

    pl.michalmech
    jaxb-example
    jar
    jaxb-example
    1.0-SNAPSHOT

    
        
            org.springframework
            spring
            2.5.6.SEC01

Teraz czas na skonfigurowanie i wczytanie kontekstu Springa. Na razie pustego ale niebawem wypełnimy go ziarnami. Najpierw przygotowujemy plik src/main/resources/context.xml:

Następnie zmieniamy klasę App:

public class App {
    public static void main(String[] args) {
        @SuppressWarnings("unused")
        ApplicationContext context = new ClassPathXmlApplicationContext("context.xml");
    }
}

Należy pamiętać o

mvn eclipse:eclipse

żeby Eclipse odświeżył biblioteki po zmianie pliku pom.xml. Próba uruchomiania () aplikacji nie powinna sprawić problemu.

Schemat XML

Założyłem, że aplikacja ma korzystać z klas wygenerowanych za pomocą JAXB‘a. Potrzebujemy więc schematu XML, na podstawie którego klasy zostaną wygenerowane. Dla przykładu skorzystamy z takiego schematu:

Zapisujemy plik pod nazwą config.xsd w src/main/resources. W dużym skrócie powyższy schemat opisuje plik XML, w którym spodziewamy się węzła zawierającego parametry oraz węzła zawierającego miasta. Parametr to element posiadający atrybut name oraz value natomiast miasto to element posiadający atrybut name oraz postCode. Atrybut postCode jest dodatkowo ograniczony wzorcem wyrażenia regularnego.

Chcielibyśmy aby oczekiwane klasy, opisujące schemat config.xsd zostały wygenerowane w locie podczas budowania aplikacji. Skorzystamy w tym celu z pluginu do Mavena. Zmieniamy plik pom.xml dodając do niego poniższą konfigurację budowania projektu:


    
        
            org.apache.maven.plugins
            maven-compiler-plugin
            
                1.5
                1.5
            
        
        
            org.codehaus.mojo
            jaxb2-maven-plugin
            
                
                    
                        xjc
                    
                
            
            
                ${project.groupId}.config
                ${basedir}/src/main/resources
                ${basedir}/src/main/generated-resources

jaxb2-maven-plugin wyszuka wszystkie schematy plików XML znajdujące się w lokalizacji wskazanej przez schemaDirectory a następnie wygeneruje klasy umieszczając je w paczce pl.michalmech.config oraz zapisze w lokalizacji wskazanej przez outputDirectory.
Użycie pluginu maven-compiler-plugin jest wymagane ponieważ JAXB korzysta z adnotacji więc kompilacja musi odbyć się w Javie, w wersji nie niższej niż 1.5.

No to do dzieła! Wykonujemy polecenie:

mvn clean compile eclipse:clean eclipse:eclipse

oraz odświeżamy projekt w IDE. Zawartość projektu powinna prezentować się teraz jak na załączonym poniżej obrazku.

Konfiguracja kontekstu

Nasza aplikacja kompiluje się i uruchamia, nadal jednak żadnej konfiguracji nie wczytujemy. Do tego przede wszystkim potrzebujemy pliku XML zgodnego z utworzonym wcześniej schematem. Takiego jak ten:

Umieszczamy go, tak jak pozostałe zasoby, w src/main/resources i nadajemy nazwę config.xml. Aby mieć pewność, że podczas budowania aplikacji dostarczany plik konfiguracyjny jest poprawny dołożymy jeszcze jeden plugin do POM‘a:


    org.codehaus.mojo
    xml-maven-plugin
    
        
            
                validate
            
            validate
        
    
    
        
            
                ${basedir}/src/main/resources
                
                    config.xml
                
                ${basedir}/src/main/resources/config.xsd
                http://www.w3.org/2001/XMLSchema
                true

Plugin ten zweryfikuje czy dostarczany plik XML jest zgodny ze schematem.

Do wczytania konfiguracji pozostało już bardzo niewiele. Posłużymy się narzędziami znajdującymi się w pakiecie org.springframework.oxm. W tym celu poprosimy Mavena o dostarczenie nam wymaganych źródeł dopisując odpowiednie zależności w pliku pom.xml:


    org.springframework.ws
    spring-ws
    1.5.2

Teraz zajmiemy się kontekstem aplikacji. Do tej pory wszystko za mnie robiło jakieś narzędzie czy biblioteka. Nie będę burzył tego porządku i inicjacją odpowiednich obiektów oraz wczytaniem zawartości pliku config.xml do aplikacji zajmie się Spring. Aby to zrobił, konieczna jest ingerencja w deskryptor kontekstu context.xml. Zmieniamy jego zawartość na:




    
        
        
            
                pl.michalmech.config.Config

Obiektem klasy ClassPathResource posłużymy się jak fabryką po to by wydobyć strumień zawierający zawartość pliku config.xml. Strumień tenże zostanie użyty w obiekcie fabrycznym Jaxb2Marshaller do naniesienia zawartości pliku config.xml na obiekt klasy Config.

Ostatnią czynnością jest pobranie obiektu Config z kontekstu i wyświetlenie przykładowych danych dostarczonych za pomocą pliku XML. Zmodyfikujmy więc aplikację do postaci:

public class App {
    public static void main(String[] args) {
        ApplicationContext context = new ClassPathXmlApplicationContext("context.xml");

        Config config = (Config) context.getBean("config");

        for (Parameter parameter : config.getParameters().getParameter()) {
            System.out.println(parameter.getName() + ":" + parameter.getValue());
        }

        for (City city : config.getCities().getCity()) {
            System.out.println(city.getName() + " - " + city.getPostCode());
        }
    }
}

Uruchomienie aplikacji () da następujący wynik w konsoli:

jakiś:parametr
inna:opcja
Warszawa - 03-481
Łęczna - 21-010

Podsumowanie

To wszystko co chciałem przekazać. Nie zagłębiałem się w szczegóły każdego z użytych narzędzi bo wpis musiałby być dużo dłuższy. Zależało mi na tym by podać gotowy przepis na użycie JAXB‘a w projekcie opartym na szkielecie Spring. Poniżej zamieszczam źródła projektu, które przydadzą się do samodzielnego uruchomienia aplikacji.

Do pobrania: jaxb-example.zip

Po pobraniu najwygodniej jest wykonać:

mvn compile eclipse:eclipse

oraz zaimportować projekt do Eclipse‘a.

Nelli Rokita jest głupia

Michał Mech — Thu, 25 Jun 2009 10:34:56 +0000

Zanim rozwinę swoją myśl zawartą w tytule tego wpisu, chciałbym podać definicję słowa “głupi“. Słownik Języka Polskiego definiuje to pojęcie następująco:

ograniczony i naiwny; też: świadczący o takich cechach;
pot. bezwartościowy intelektualnie;
pot. świadczący o czyimś zakłopotaniu;
pot. dający się wykorzystywać;
pot. niemający znaczenia;
pot. kłopotliwy, niezręczny;

Pani Nelli Rokita w programie “Kropka nad i” w dniu 24. czerwca 2009r. wypowiadała się między innymi na temat niepłodności oraz na temat leczenia niepłodności – metody in vitro. Uznała też, że niepłodność nie jest chorobą, czym obraziła niemałą rzeszę Polaków zmagających się z tym problemem.

“Pani redaktor, bezpłodność nie jest chorobą. To jest wymysł najnowszych naukowców, że bezpłodność jest chorobą”

Otóż pani Rokita, prawdopodobnie będąc nieprzygotowaną merytorycznie, pominęła fakt, że niepłodność jest zapisana w Międzynarodowej Statystycznej Klasyfikacji Chorób i Problemów Zdrowotnych ICD-10. Podważyła tym samym, wiele naukowych faktów. W końcu klasyfikacja jasno mówi o niepłodności kobiecej (N97) oraz męskiej (N46). Podejrzewam, że bardzo szybko dostrzegła swoją gafę i wycofała się z tego stwierdzenia zamieniając ja na inną, głupią tezę, że niepłodność może i jest chorobą ale występującą w naszych głowach, chorobą psychiczną. Bulwersujące były również insynuacje pani Rokity, że niepłodność to problem kobiet, które poddawały się wcześniej aborcji.

“Nie może być tak, że chcemy prawa do aborcji, a jak już nam to nie pasuje, żądamy in vitro”

Nigdy nie chciałem komentować na blogu wydarzeń politycznych ale czuję się obrażony wypowiedziami pani Rokity. Jest ona posłem na Sejm i pobiera wynagrodzenie za podatki, które płacę. Postanowiłem więc głośno wypowiedzieć się co o niej myślę. Cytując Wikipedię:

“Uważa się, że problem dotyczy 1 na 6 par i w 40% jest zależny od kobiety, w 30% od mężczyzny, a za pozostałe odpowiadają oboje, lub nie da się określić przyczyny (niepłodność idiopatyczna)”

Nie może być tak, że osoba, której swoje poparcie udzieliło zaledwie 6367 osób wypowiada się i decyduje w temacie, o którym nie ma zielonego pojęcia. Nie może być tak, że taka osoba decyduje o losie bardzo wielu ludzi w kraju.

Java Killers #001

Michał Mech — Wed, 17 Jun 2009 22:43:42 +0000

Na blogu Pawła Szulca (również w wersji polskiej) można czasem znaleźć zagadki związane z Javą. Paweł nazywa je Java Killers.
Bardzo lubię je czytać a teraz sam mam taką zagadkę. Mam nadzieję, że dla Was będzie to choć trochę ciekawostka, ja byłem zdziwiony.

Oto kod:

public class Main {

    public static void main(String[] args) {
        Integer i1 = 1000;
        Integer i2 = 1000;

        if (i1 != i2) {
            System.out.println("i1 and i2 are not the same");
        }

        Integer i3 = 10;
        Integer i4 = 10;

        if (i3 == i4) {
            System.out.println("i3 and i4 are the same");
        }
    }
}

A oto wynik:

i1 and i2 are not the same
i3 and i4 are the same

Co się takiego stało, że 1000 to nie 1000 ale 10 to już 10?

Otóż mechanizm z jakim mamy tu do czynienia to autoboxing, który został wprowadzony w Javie 1.5. W skrócie autoboxing to mechanizm, który pozwala traktować typy proste jak obiekty i na odwrót a konwersja dzieje się automatycznie w zależności od potrzeby (boxing i unboxing). Każdy typ prosty posiada swoją klasę opakowującą (ang. wrapper) go w obiekt zawierający wartość o typie prostym. Dzięki temu obiekty typu Integer możemy traktować jak int. Szerzej o mechanizmie autoboxing być może jeszcze napiszę w przyszłości teraz wyjaśnię tylko powyższą sytuację.

Deklarujemy obiekty typu Integer. Dwa obiekty są takie same (w sensie ==) jeśli to są te same obiekty. Ale nie w przypadku klas opakowujących (ang. wrapper) typy proste. W takim przypadku dwa obiekty są takie same jeśli przechowują takie same typy proste i są jednymi z poniższych:

Boolean;
Byte;
Character (znaki od \u0000 do \u007f);
Short lub Integer ale tylko o wartościach od -128 do 127

Wartość 1000 przekracza 127 stąd powyższa “anomalia”.

Automatyczne wstrzykiwanie bean’ów w Springu

Michał Mech — Tue, 16 Jun 2009 21:13:25 +0000

Jednym z najważniejszych modułów frameworka Spring jest jego kontener odwrócenia sterowania (ang. Inversion of Control, IoC), który dostarcza nam możliwości wstrzykiwania zależności (ang. Dependency Injection, DI). Jest to miejsce gdzie dzieje się magia :-)

Taki kontener należy odpowiednio skonfigurować, aby bean‘y zarządzane przez framework były odpowiednio zainicjowane oraz ze sobą połączone. Nie będę opisywał wszystkich aspektów konfiguracji kontenera IoC, gdyż to zadanie na niekrótką książkę. Skupię się tylko na definiowaniu powiązań między bean‘ami za pomocą automatycznego wstrzykiwania (ang. autowire).

Tytułem krótkiego wprowadzenia zaimplementujmy dwa bardzo proste bean‘y:

package pl.michalmech.autoexample.bean;

public class Parent {

    private Integer simpleNumber;

    private Property propertyObject;

    public Parent() {}

    /* setters&getters */
}

package pl.michalmech.autoexample.bean;

public class Property {

    private String simpleText;

    public Property() {}

    /* setters&getters */
}

Jak widać to bardzo niewyszukane byty pozostające w banalnej zależności. Swoją mini aplikację uruchamiam przez przeglądarkę. W związku z tym dołożyłem sobie prosty kontroler:

package pl.michalmech.autoexample.web;

public class HelloController implements Controller {

    protected final Log logger = LogFactory.getLog(getClass());

    private Parent parentObject;

    @Override
    public ModelAndView handleRequest(HttpServletRequest request,
            HttpServletResponse response) throws Exception {

        logger.info(parentObject.getSimpleNumber());
        logger.info(parentObject.getPropertyObject().getSimpleText());

        return new ModelAndView("index.jsp");
    }

    /* setters&getters */
}

Tytle tytułem wstępu. Czas zabrać się za definicję bean‘ów i ich właściwości w deskryptorze. Oto one:

I tu pierwsze pytanie: Co się stanie kiedy uruchomimy teraz kontroler? Oczywiście, dostaniemy po oczach wyjątkiem NullPointerException z bardzo prostej przyczyny. Poza definicją bean‘ów należy je jeszcze wstrzyknąć sobie nawzajem czyli określić relację między nimi.

Automatyczne wstrzykiwanie na podstawie nazwy.

Powyższy deskryptor wymaga dwóch poprawek. Pierwsza to wstrzyknięcie obiektu klasy Parent do kontrolera HelloController:

Jest to najczęściej stosowany sposób definiowania zależnościami pomiędzy bean‘ami. W jawny sposób mówimy, że bean o nazwie parentObject powinien zostać wstrzyknięty w pole kontrolera o tej samej nazwie.
Koleją zależność zdefiniujemy nieco inaczej:

Obiekt parentObject klasy Parent posiada jedno pole typu prostego i je tutaj pomijam bo nie ma znaczenia przy omawianiu automatycznego wstrzykiwania, które tyczy się tylko obiektów. Zadeklarowanie bean‘a jako autowire=”byName” sprawi, że Spring automatycznie wyszuka bean‘a o nazwie takiej jak nazwa inicjowanego pola. W tej sytuacji w pole propertyObject zostanie wstrzyknięty bean o nazwie propertyObject. Sprawa jest dość prosta i klarowna. Warto zwrócić jednak uwagę na trzy kwestie:

Niezgodność typów. W przypadku kiedy bean o pasującej nazwie próbuje być wstrzyknięty jako wartość pola ale nie jest zgodny z jego typem dostaniemy wyjątek BeanCreationException, spowodowany przez TypeMismatchException:

Caused by: org.springframework.beans.TypeMismatchException: Failed to convert property value of type [pl.michalmech.autoexample.bean.FakeProperty] to required type [pl.michalmech.autoexample.bean.Property] for property 'propertyObject'; nested exception is java.lang.IllegalArgumentException: Cannot convert value of type [pl.michalmech.autoexample.bean.FakeProperty] to required type [pl.michalmech.autoexample.bean.Property] for property 'propertyObject': no matching editors or conversion strategy found

Brak bean‘a o szukanej nazwie. Jeśli kontener nie znajdzie bean‘a wymaganej nazwie to, jak łatwo się domyślić, nic nie wstrzyknie. Pole nadal będzie miało wartość null;

Niejednoznaczność nazwy bean‘a. To problem, który może wystąpić i który nie jest związany bezpośrednio z automatycznym wstrzykiwaniem. Dwa bean‘y o tej samej nazwie to prosty błąd konfiguracji, który sprowadza się do BeanDefinitionParsingException.

Automatyczne wstrzykiwanie po typie.

Kontener IoC pozwala nam automatycznie wstrzyknąć zależności nie tylko bazując na nazwach bean‘ów ale również na podstawie ich typów. Zmodyfikujmy konfigurację automatycznego wstrzykiwania dla bean‘a parentObject następująco:

Zmienił się typ automatycznego wstrzykiwania zależności. W obecnej sytuacji Spring natrafiając na pole propertyObject bean‘a parentObject będzie starał się wstrzyknąć bean‘a o typie Property. W moim prostym przykładzie mamy oczywiście takiego bean‘a więc wszystko uda się bez problemu.

W przypadku wstrzykiwania po typie nie musimy kompletnie martwić się o nazwę bean‘a. Podobnie nie musimy się martwić jeśli bean o żądanym typie nie zostanie odnaleziony. Po prostu nic nie zostanie wstrzyknięte.

Niestety całkowicie wbrew powiedzeniu “Od przybytku głowa nie boli” musimy się martwić o nadmiar bean‘ów o typie zgodnym z typem pola do którego Spring będzie chciał wstrzyknąć zależności.
Załóżmy, że mam dwa bean‘y o tym samym typie:

Próba uruchomienia tak skonfigurowanej aplikacji skończy się na BeanCreationException spowodowanym przez UnsatisfiedDependencyException:

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'parentObject' defined in ServletContext resource [/WEB-INF/AutoExample-servlet.xml]: Unsatisfied dependency expressed through bean property 'propertyObject': : No unique bean of type [pl.michalmech.autoexample.bean.Property] is defined: expected single matching bean but found 2: [propertyObject, secondPropertyObject]; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [pl.michalmech.autoexample.bean.Property] is defined: expected single matching bean but found 2: [propertyObject, secondPropertyObject]

Pomimo tego, że streszczenie wyjątku jest w jednej, długiej linii to dostarcza wielu informacji. Spring podpowiada, że znalazł aż dwa bean‘y pasujące typem do pola oraz podaje ich nazwy co pozwala na szybkie wytropienie błędu.

Automatyczne wstrzykiwanie za pomocą konstruktora.

Kolejnym sposobem na automatyczne wstrzyknięcie zależności do bean‘a jest użycie konstruktora. Zmodyfikujmy klasę Parent w następujący sposób:

package pl.michalmech.autoexample.bean;

public class Parent {

    protected final Log logger = LogFactory.getLog(getClass());

    private Integer simpleNumber;

    private Property propertyObject;

    public Parent(Property propertyObject) {
        this.propertyObject = propertyObject;

        logger.info("propertyObject field set by constructor");
    }

    public Property getPropertyObject() {
        return propertyObject;
    }

    public void setPropertyObject(Property propertyObject) {
        this.propertyObject = propertyObject;

        logger.info("propertyObject field set by method");
    }

    /* setter&getter for simpleNumber */
}

W stosunku do oryginału zmieniły się dwie rzeczy:

Usunięty został domyślny konstruktor;
Dodany został konstruktor inicjujący pole propertyObject;

Zmieńmy jeszcze sposób automatycznego wstrzykiwania. Zmiana deskryptora wygląda następująco:

Próba uruchomienia aplikacji zakończy się sukcesem a w konsoli ujrzymy następujący napis:

propertyObject field set by constructor

Na podstawie tego przykładu widać doskonale, że automatyczne wstrzykiwanie za pomocą konstruktora niewiele różni się od wstrzykiwania na podstawie typu. Również w tym przypadku kontener wyszukuje bean‘a o odpowiednim typie lecz zamiast odpowiedniej metody do wstrzyknięcia używa konstruktora.

Sposób ten w odróżnieniu od byType niesie ze sobą więcej potencjalnych problemów. Pierwszym z nich jest sytuacja kiedy konstruktor posiada więcej argumentów. Załóżmy więc, że konstruktor przyjmuje nie tylko jeden argument o typie zgodnym z polem do którego będzie wstrzyknięta wartość (w tym przypadku Property) lecz posiada jeszcze jeden:

    public Parent(Integer simpleNumber, Property propertyObject) {
        this.simpleNumber = simpleNumber;
        this.propertyObject = propertyObject;
    }

W takiej sytuacji próba uruchomienia aplikacji zakończy się wyrzuceniem znanego już wyjątku UnsatisfiedDependencyException z komunikatem podobnym do:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [java.lang.Integer] is defined: Unsatisfied dependency of type [java.lang.Integer]: expected at least 1 matching bean

Oznacza to, że aby kontener IoC mógł skorzystać z naszego konstruktora potrzebuje wszystkich argumentów. Co zresztą wcale nie dziwi. W związku z tym, że nie mamy bean‘a o typie Integer, dostajemy wyjątek.
Podobnie stałoby się gdybyśmy potrzebowali wstrzyknąć dwa lub więcej obiekty a żaden z konstruktorów nie posiadałby ich pełnej listy w swoich argumentach.

Jak już wcześniej się okazało przybytek nie zawsze jest dobry. Co się stanie w sytuacji kiedy będziemy mieli więcej konstruktorów, z których Spring mógłby skorzystać do wstrzykiwania zależności? Załóżmy więc taką sytuację:

    public Parent(Integer simpleNumber, Property propertyObject) {
        this.simpleNumber = simpleNumber;
        this.propertyObject = propertyObject;
    }

    public Parent(String fakeString, Property propertyObject) {
        this.propertyObject = propertyObject;
    }

Uruchomienie aplikacji na takich warunkach uda się bez problemu a do wstrzyknięcia zależności użyty zostanie pierwszy konstruktor. Dlaczego? No coż, nie mam pewności ale z moich obserwacji wynika, że użyty zostanie pierwszy pasujący konstruktor.

Automatyczny wybór sposobu wstrzykiwania.

Poza trzema omówionymi strategiami automatycznego wstrzykiwania zależności jest jeszcze jedna, polegająca na autodetekcji:

Autodetekcja polega na tym, że kontener wybierze sam pomiędzy constructor a byType. Kryterium wyboru to obecność domyślnego konstruktora. Jeśli kontener IoC go znajdzie, to skorzysta ze wstrzykiwania na podstawie typu, jeśli nie, to spróbuje wstrzyknąć zależności za pomocą konstruktora.

Kolekcje a automatyczne wstrzykiwanie.

Zbliżając się ku końcowi wrócę jeszcze do tego przybytku od, którego głowa bolała. Mechanizm autowire radzi sobie bardzo dobrze z kolekcjami.

Kiedy wstrzykiwaliśmy na podstawie typu (autowire=”byType”) a bean‘ów o poszukiwanym typie było więcej niż jeden, framework raczył nas wyjątkiem UnsatisfiedDependencyException. Nie działoby się tak jeśli mielibyśmy do czynienia z tablicą, kolekcją (Collection) lub mapą:

package pl.michalmech.autoexample.bean;

    public class Parent {

    private Integer simpleNumber;

    private Set propertyObjects;

    public Set getPropertyObjects() {
        return propertyObjects;
    }

    public void setPropertyObjects(Set propertyObjects) {
        this.propertyObjects = propertyObjects;
    }

    /* setter&getter for simpleNumber */
}

W takiej sytuacji kontener wrzuci do kolekcji wszystkie znalezione bean‘y o pasującym typie. W powyższym przykładzie jest zbiór ale mechanizm zadziała również z tablicą oraz dowolną inną kolekcją (Collection). W przypadku mapy ważne jest by jej kluczem były obiekty typu String ponieważ to nazw bean‘ów Spring używa do wypełnienia mapy. W przeciwnym wypadku framework po prostu nic do niej nie wstrzyknie.

Kandydaci do wstrzyknięcia.

Użycie kolekcji zamiast pojedynczego bean‘a nie zawsze jest rozwiązaniem pozwalającym ominąć problem nadmiarowej ilości bean‘ów. Co w sytuacji kiedy po prostu chcemy wstrzyknąć jednego bean‘a i bardzo chcemy użyć automatycznego wstrzykiwania na podstawie typu? Otóż są jeszcze dwa rozwiązania.
Pierwsze z nich to wykluczenie części bean‘ów z kandydatury na bycie wstrzykniętym. Oto jak to się robi:

Tak skonfigurowany bean nie będzie nam przeszkadzał w automatycznym wstrzykiwaniu, ponieważ nie będzie wzięty pod uwagę.
Innym sposobem jest określenie głównego bean‘a o danym typie:

Jeśli jestkilka bean‘ów o danym typie i tylko jeden z nich jest primary to on zostanie wstrzyknięty.

Podsumowanie.

Jak widać automatyczne wstrzykiwanie zależności to trochę jak pudełko czekoladek, nigdy nie wiadomo co się trafi (tak mawiał Forrest Gump). Nawet dokumentacja zaznacza, że należy się zastanowić czy warto stosować mechanizm autowire przy dużych wdrożeniach, ponieważ nie jest łatwo wtedy utrzymać całkowitą jednoznaczność i kontrolę nad bean‘ami. Mi się jednak ten echanizm podoba. Zobaczymy jak w przyszłości.

P.S.

Mechanizmem automatycznego wstrzykiwania zależności można również sterować za pomocą adnotacji dostępnych w Javie od wersji 1.5. Postanowiłem jednak pominąć je w tym wpisie ponieważ urósłby on do zbyt dużych rozmiarów.

Bye bye Blogger

Michał Mech — Tue, 09 Jun 2009 19:58:41 +0000

Drogi czytelniku jeśli jesteś tutaj n-ty raz zauważyłeś zapewne, że zmieniła się szata graficzna.

Postanowiłem podziękować za współpracę platformie Blogger‘a na rzecz własnej instalacji Wordpress‘a. Początkowo był to Blogger ponieważ chciałem po prostu pisać i nie przejmować się aplikacja, instalacją, e.t.c. Z czasem okazało się, że Blogger to zbyt uboga platforma i nie spełnia moich oczekiwań. Na przykład kuleje możliwości wklejania listingów, których jest sporo w moich wpisach.
Wordpress daje nieporównywalnie dużo więcej możliwości, chociażby z tego powodu, że instalacja stoi na “moim” serwerze i mogą z nią robić co chcę.

Jak widać udało mi się bez większego bólu zaimportować treści, które były opublikowane jeszcze za Blogger‘a.

Starałem się zachować stan bloga tak aby migracja była niezauważalna dla osób, które subskrybują kanał RSS lub mają mój adres zapisany w zakładkach. Nie mniej jednak kilka linków zmieniło adresy. Za utrudnienia najmocniej przepraszam. Proszę informować mnie o problemach, postaram się je naprawić. Takie są koszty lenistwa i pójścia na łatwiznę, czym był wybór Blogger‘a.

P.S.
Po przenosinach oraz po wielu innych wydarzeniach, które się ostatnio działy w moim życiu mogę znów zabrać się do nauki, a co z tym się wiąże, do publikowania kolejnych wpisów.

Budowanie aplikacji za pomocą Mavena

Michał Mech — Wed, 08 Apr 2009 19:19:00 +0000

Kiedy pisałem o instalacji Seama wspomniałem, o instalacji narzędzia Maven, które może mi się przydać w przyszłości. I oto nadeszła ta chwila. Czytając jakiś czas temu poradnik Developing a Spring Framework MVC application pomyślałem, że fajnie byłoby zamienić narzędzie do budowania projektu z Anta na Mavena, który zajmie się przy okazji zależnościami.

Korzystam z Eclipse‘a jako IDE więc do zabawy przydadzą mi się dwa pluginy:

Spring IDE – Przyda się do utworzenia Hello World oraz na przyszłość;
Maven Integration for Eclipse – Zautomatyzuje nam to trochę czynności oraz dostaniemy bardzo ładny edytor plików POM.

Po zainstalowaniu powyższych tworzymy zalążek projektu w Eclipse. Wybieramy File > New > Other a później Spring Project. Podajemy nazwę projektu, niech to jExample oraz zmieniamy lokalizację Source Folder Name z src na src/main/java a Output Folder Name z bin na target/classes. Zmiany te wynikają z domyślnych ustawień pluginów Mavena, z których będziemy korzystać.

W następnej kolejności aktywujemy zarządzanie projektem za pomocą Mavena. W tym celu wybieramy Maven Enable Dependency Managment po uprzednim kliknięciu prawym klawiszem myszy na projekcie.

Kluczowym elementem pracy z Mavenem jest plik POM, który stanowi konfigurację zawierającą informacje o projekcie, jego zależnościach, e.t.c. Kreator tworzenia pliku POM uruchomi się zaraz po aktywacji Mavena. Jedyną zmianą jakiej dokonujemy to zamiana pakowania projektu z jar na war. Oto plik, który będzie wynikiem:



    4.0.0
    jExample
    jExample
    war
    0.0.1-SNAPSHOT

Utwórzmy teraz naprawdę bardzo prostą aplikację internetową. Niech jej jedyną funkcją będzie przywitanie nas słowami … Hello World. W pierwszej kolejności tworzymy deskryptory.

src/main/webapp/WEB-INF/web.xml:




    
        jExample
        org.springframework.web.servlet.DispatcherServlet
        1
    

    
        jExample
        *.html
    

    
        index.html

src/main/webapp/WEB-INF/jExample-servlet.xml:

Oraz src/main/webapp/WEB-INF/applicationContext.xml

Dodajemy jeszcze szybko widok (src/main/webapp/index.jsp):


    
        jExample
    
    
        jExample :: Hello World

Oraz na koniec niewielki kontroler:

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.web.servlet.ModelAndView;
import org.springframework.web.servlet.mvc.Controller;

public class HelloController implements Controller {

    protected final Log logger = LogFactory.getLog(getClass());

    public ModelAndView handleRequest(HttpServletRequest request,
            HttpServletResponse response) throws Exception {

        logger.info("Returninag hello view");

        return new ModelAndView("index.jsp");
    }
}

Niestety jedyne co ma dla nas Eclipse to błędy wynikające z braku klas, których potrzebujemy:

Jest to okazja do wykorzystania wreszcie Mavena, który dostarczy nam zależności, których potrzebujemy. Chcielibyśmy przede wszystkim skorzystać ze Spring MVC (niech to będzie najnowsza wersja) oraz API związanego z sewletami. Dodajemy do pliku POM następujący wpis (możemy oczywiście w tym celu użyć edytora plików POM):


    
        org.springframework
        spring-webmvc
        2.5.6
    
    
        javax.servlet
        servlet-api
        2.5
        provided

Zapisanie pliku sprawi, że Maven pobierze ze swojego lokalnego repozytorium wymagane zależności i dostarczy do projektu. W przypadku braku wymaganych paczek, zostaną one wcześniej pobrane z sieci (http://repo2.maven.org/maven2) oraz zainstalowane w repozytorium lokalnym Mavena. Warto zaznaczyć, że Maven dostarczył nam również inne wymagane pośrednio zależności: commons-logging, spring-core, e.t.c. My nie musimy się niczym martwić. Projekt już nie świeci się na czerwono od błędów.

W związku z tym, że dążymy do ujrzenia naszej aplikacji działającej przydałoby sie teraz utworzyć plik WAR. W tym celu wykonujemy w konsoli (będąc w loklizacji, w której znajduje się nasz projekt) polecenie:

mvn clean package

Wynikiem wykonania tego polecenia powinno być coś takiego:

F:\workspace\jExample>mvn clean package
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Unnamed - jExample:jExample:war:0.0.1-SNAPSHOT
[INFO]    task-segment: [clean, package]
[INFO] ------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory F:\workspace\jExample\target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 1 source file to F:\workspace\jExample\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [war:war]
[INFO] Packaging webapp
[INFO] Assembling webapp[jExample] in [F:\workspace\jExample\target\jExample-0.0.1-SNAPSHOT]
[INFO] Processing war project
[INFO] Webapp assembled in[171 msecs]
[INFO] Building war: F:\workspace\jExample\target\jExample-0.0.1-SNAPSHOT.war
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5 seconds
[INFO] Finished at: Wed Apr 08 23:51:16 CEST 2009
[INFO] Final Memory: 11M/20M
[INFO] ------------------------------------------------------------------------

Teraz krótkie wyjaśnienie. Maven w pierwszej kolejności wyczyścił wszystko to co mogło być do tej pory skompilowane i umieszczone w folderze target. Po to było polecenie clean. W dalszej części Maven zajmuje się pakowaniem projektu (polecenie package). Plan tej czynności zakłada wykonanie kilku czynności wcześniej. Jest to przede wszystkim kompilacja źródeł, zebranie zasobów, wykonanie testów jednostkowych oraz wreszcie zebranie wszystkiego do kupy w WAR Pomimo tego, że w tym przypadku niewiele faktycznie jest do zrobienia, Maven informuje nas o każdej czynności i wynikach jej wykonania.
Każda z czynności jest realizowana przez oddzielny plugin Mavena, który możemy w szczególności skonfigurować wedle naszych życzeń.

Do Hello World krzyczącego do nas z okna przeglądarki zostało bardzo niewiele. Podobnie jak w tutorialu, o którym wspomniałem na początku, my również skorzystamy z kontenera aplikacji Apache Tomcat (instalacja jest niezwykle prosta więc pominę jej opis).

Przy tej okazji chciałbym zwrócić uwagę na konfigurację zależności servlet-api. Przestrzeń (ang. scope) jest zdefiniowana jako provided. Dzieje się tak ponieważ Tomcat dostarcza już tą paczkę wśród swoich bibliotek więc aplikacja, która jest rozmieszczana (ang. deploy) na serwerze nie musi jej zawierać.

W folderze domowym instalacji Mavena, w folderze conf znajduje się plik z globalną konfiguracją: settings.xml. W bloku zawierającym definicje serwerów servers/servers dodajmy opis lokalnego Tomcata:


    tomcat.local
    admin

Identyfikator serwera jest dowolny natomiast login oraz hasło (a dokładniej jego brak) wynika z domyślnych wartości dla standardowej instalacji Tomcataa. Aby umieścić naszą aplikację na serwer skorzystamy z pluginu Tomcat Maven Plugin. Aby wykonać całą robotę, czyli kompilację, spakowanie oraz rozmieszczenie (ang. deploy) projektu na serwer wystarczy wykonać polecenie:

mvn clean package tomcat:deploy

W zasadzie to wystarczy ponieważ Maven pobierze ze swojego repozytorium i zainstaluje wspomniany plugin jak tylko będzie go potrzebował. Podczas wykonywania polecenia zobaczymy to w konsoli:

[INFO] Searching repository for plugin with prefix: 'tomcat'.
[INFO] org.codehaus.mojo: checking for updates from central
[INFO] artifact org.codehaus.mojo:tomcat-maven-plugin: checking for updates from central
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/tomcat-maven-plugin/1.0-beta-1/tomcat-maven-plugin-1.0-beta-1.pom
5K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/mojo-parent/20/mojo-parent-20.pom
18K downloaded
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/tomcat-maven-plugin/1.0-beta-1/tomcat-maven-plugin-1.0-beta-1.jar
48K downloaded

Niemniej jednak gdybyśmy chcieli wskazać jakieś inne repozytorium, które Maven ma przeszukiwać w chwili kiedy czegoś potrzebuje, możemy je zdefiniować w pliku POM:


    
        mojo
        Mojo Project
        http://repository.codehaus.org

Podobnie ma się rzecz z uruchomieniem plugin. Użyta będzie domyślna konfiguracja. Aby ją zmienić powinniśmy odpowiednio zmodyfikować POM. Oto przykład jak jawnie podać nazwę serwera, na którym umieszczamy (ang. deploy) aplikację:


    
        
            org.codehaus.mojo
            tomcat-maven-plugin
            
                tomcat.local

Konfiguracja oczywiście będzie będzie wzięta z ustawień globalnych Mavena.

W zasadzie to wszystko. Wykonanie wspomnianego polecenia (mvn clean package tomcat:deploy) powinno dać następujący wynik:

...
[INFO] Building war: F:\workspace\jExample\target\jExample-0.0.1-SNAPSHOT.war
[INFO] [tomcat:deploy]
[INFO] Deploying war to http://localhost:8080/jExample
[INFO] OK - Deployed application at context path /jExample
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Uruchomienie w przeglądarce adresu http://localhost:8080/jExample/index.html pozwoli nam upewniść się, że aplikacja działa.

To co opisałem, to zaledwie kropla w morzu możliwości Mavena, który posiada ich oczywiście dużo więcej, dzięki różnorodnym pluginom. Możemy dzięki niemu nie tylko zarządzać budowaniem projektu i zależnościami ale również generować dokumentację czy nawet sprawdzać styl kodowania.

Reguły nawigacji w deskryptorze stron Seam’a

Michał Mech — Sun, 01 Mar 2009 13:41:00 +0000

We wprowadzeniu do dokumentacji frameworka JBoss Seam twórcy podkreślają, że uciekają jak tylko się da od konfiguracji za pomocą plików XML na rzecz przekazywania informacji do kontenera za pomocą adnotacji. Nie mniej jednak każdy projekt napisany z pomocą Seam’a zawiera kilka plików konfiguracyjnych, jednym z nich jest deskryptor stron: pages.xml.

W pliku deskryptora (znajduje się on wewnątrz folderu WEB-INF) mamy możliwość definiowania naturalnych konwersacji (ang. natural conversation), stron błędów dla wyjątków (ang. exception handling) oraz zasad nawigacji dla stron (ang. page navigation). Ja skupię się na nawigacji.

Pusty deskryptor (zawierający jedynie węzeł główny) wygląda następująco:

W deskryptorze możemy umieścić dowolną ilość węzów , które stanowią definicję stron. Podstawowa definicja strony to podanie jej identyfikatora. Definicja taka wiele nie wnosi więc podam od razu przykład jak zdefiniować akcję dla strony (ang. page action):

Tak podana definicja spowoduje wykonanie akcji sampleAction komponentu testComponent tuż przed wyrenderowaniem strony testPage. Oczywiście zawsze istnieje możliwość wykonania kilku akcji (także z różnych komponentów) na okoliczność żądania strony samplePage.xhtml:

Wykonanie akcji możemy obwarować warunkiem logicznym (zapisanym oczywiście za pomocą języka EL). Służy do tego opcjonalny atrybut if, na przykład:

Akcje wykonywane są w kolejności zapisania ich w pliku. Ważne jest to by pamiętać o tym, że po każdej akcji realizowane są reguły nawigacji dla strony, co oznacza, że koniec końców nie każda akcja może mieć szanse uruchomienia. A wspomniane reguły definiuje się następująco:

Każda akcja może zwrócić wartość, wynik (ang. outcome). To właśnie ta wartość posłuży to testowania zasad nawigacji dla strony. Niech komponent testComponent, do którego odwołania występują w przykładach wygląda tak:

@Name("testComponent")
public class TestComponent {
    @Logger private Log log;

    public String sayHello() {
        log.info("akcja sayHello zwraca outcome hello");
        return "hello";
    }

    public String sayHi() {
        log.info("akcja sayHi zwraca outcome hi");
        return "hi";
    }
}

Prześledźmy sytuację. Jeśli zażądamy strony testPage.xhtml, wykonana zostanie akcja sayHello(), której outcome to hello. W tej sytuacji wyrenderowana zostanie strona home.xhtml, co zmieni podmiot odwołania i akcja sayHi() nie będzie miała okazji się uruchomić. Wystarczy jednak zmienić kolejność akcji w pliku aby nastąpiło przekierowanie na stronę logowania – login.xhtml. Osiągniemy to jeśli najpierw wykona się sayHi():