Problem z Bean Validation polega na tym, że nie za bardzo idzie wpiąć się do niego w taki sposób by walidatory były tworzone i zarządzane przez kontener DI. Nie wiem czy to jest tylko moje niedopatrzenie wraz z niechęcią do czytania dokumentacji czy też jakaś głębsza myśl związana z całym JSRem, ale generalnie obiekty walidatorów są tworzone poza naszym zasięgiem. Chcąc zatem coś wstrzyknąć do takiego obiektu należy się uzbroić w cierpliwość. Najprostsza metoda polega oczywiście na wywołaniu metody injector.injectMembers(this) w metodzie initialize walidatora. Tyle tylko, że jak mamy wiele walidatorów to zaczyna się robić nieciekawie. Dziedziczenie tu niewiele zmienia, bo i tak musimy zaśmiecać kod, tym razem wywołaniem super.initialize(). Jak się zapomni to dupa blada.
Rozwiązaniem jest użycie programowania aspektowego i wkompilowanie odpowiedniego kawałka kodu. Guice udostępnia oczywiście interfejs AOP, ale…

It is not possible to use method interception on instances that aren’t constructed by Guice.

źródło

czyli jeżeli walidatory nie są tworzone przez Guice to se można do usranej śmierci zwalczać NPE. Z pomocą przychodzi nam w tym przypadku AspectJ. Wystarczy machnąć taki oto prosty aspekcik:

listing 1. Wstrzyknięcie zależności do walidatora

@Aspect
public class ValidationInitAspect {

	@Pointcut("execution( * javax.validation.ConstraintValidator+.initialize(..))")
	public void initialize(){}

	@Around("initialize()")
	public Object around(ProceedingJoinPoint joinPoint) throws Throwable{
		System.out.println("Init");
		App.injector.injectMembers(joinPoint.getThis());
		return joinPoint.proceed();
	}

}

e’wiola jak mawiają Francuzi. Co się dzieje? Pointcut wskazuje na metodę initialize wszystkich klas będących ConstraintValidator. Wstrzykujemy oczywiście w miejsce wykonania, a nie wywołania. Jedynym fakupem jest konieczność zapewnienia sobie dostępu do injectora, tu realizowane jest to poprzez zrobienie go publicznym, statycznym polem w klasie głównej aplikacji.

Wiem, że hak, ale działa.

Dodaj do

Generalnie zarówno call jak i execution nie różnią się jeżeli chodzi o moment wywołania. Jeżeli zdefiniujemy, że mają być wkompilowane przed to zostaną wkompilowane przed. Jeżeli po to po. Kompilator zapewnia, że w danym przepływie sterowania aspekt będzie umieszczony w odpowiednim miejscu. Oczywiście przy założeniu, że nie ma tam jakiś dodatkowych aspektów. Różnica leży w tym gdzie kompilator umieszcza kod.

Położenie call

Jeżeli używamy call to kompilator umieści kod porady w miejscu gdzie wywoływana jest dana metoda. Czyli jeżeli metoda A.a woła metodę B.b to kod zostanie umieszczony w metodzie A.a.

Położenie execution

Jeżeli używamy execution to kompilator umieści kod w wywoływanej metodzie. Przykładowo jeżeli A.a woła B.b to kod zostanie umieszczony w B.b.

Gdzie jest to istotne

W praktyce jeżeli wrzucamy kod aspektowy do naszych klas to nie ma różnicy czy użyjemy call czy execution. Kompilator i tak musi przeorać cały kod źródłowy… no właśnie. Kod źródłowy… Jeżeli wasza metoda jest wywoływana przez jakaś zewnętrzną bibliotekę np. chcecie dodać kod aspektowy do testu oznaczonego @Test to użycie call skończy się komunikatem Xlint:adviceDidNotMatch. Kompilator nie doda waszej porady ponieważ nie pracuje na kodzie wywołującym metodę. Dotyczy to też sytuacji gdzie do wywołania metody używacie refleksji. W takim wypadku macie dwa wyjścia. Po pierwsze użyć execution, co jest prostsze, ale narusza wasz kod (przyjmuję tu pracę z weaveringiem w czasie kompilacji). Po drugie użyć call wraz z weaveringiem w czasie ładowania klas.

Dodaj do

Some time ago I tried to learn aspect oriented programming (AOP) but failed. When I was lend “AspectJ in Action” form Warsaw JUG library I promised myself – I start to use AOP.
Ramnivas Laddad wrote great book about AOP and the most advanced AOP solution – AspectJ. Book has two parts. The first (chapters 1-9) describes basic issues of AOP and their implementation in AspectJ. We learn for it most important ideas of AOP (Join Points, Aspects, Poitcutting, etc.) and AJ API. Author begins with the simplest of things and move to more complex issues e.g.Dynamic Weaving, Weaving Model. In the last chapter, in first part, has described the integration of Spring Framework and Spring proxy-based AOP.
The second part (chapters 10-17) deals with the practical application of AOP. Author shows not invasive methods of logging, tracing, securing and managing transactional API. Also describes basic design patterns used in AOP and testing AOP applications.
In conclusion “AspectJ in Action” by Ramnivas Laddad is a “must have” book. You should have this book in your library because it is one of the the best books about programming in Java ever.

Dodaj do

Wiemy już mniej więcej co to jest programowanie aspektowe i jak się to je. Wiemy jak zdefiniować poradę (i czym mniej więcej ona jest), umieścić ją w kodzie za pomocą punktu przecięcia i uruchomić program. Należałoby teraz powiedzieć czym są punkty przecięcia. Jednakże jest to dość skomplikowane i na razie musimy załapać trochę teorii.

Vox populi i moja teoria języków

W książce “AspectJ In Action” Ramnivas Laddad podaje pewne bardzo ciekawe podejście do problemu zdefiniowania czym jest punkt wejścia, a czym punkt przecięcia. Mekk w komentarzu do pierwszego tekstu o AspectJ prosił o dokładniejsze omówienie tego problemu. Zatem oto jestem

Każdy paradygmat programowania definiuje pewne ogólne pojęcia. W programowaniu obiektowym są to obiekty i ich interakcje pomiędzy sobą. W programowaniu proceduralnym mamy do czynienia z procedurami, a w przypadku programowania imperatywnego takim pojęciem jest instrukcja. W przypadku programowania aspektowego mamy do czynienia z aspektem, czyli pewnym elementem logiki programu, który można odseparować od reszty. W klasycznym modelu różne aspekty przeplatają się w programie tworząc coś w rodzaju warkocza (ang. tress). Rozumienie kodu jest podobne do rozplątywania warkocza. Proces ten jest żmudny i może być nieprzyjemny. W programowaniu aspektowym poszczególne elementy są splatane przez tkacza (ang.weaver) tak jak płótno. Dzięki czemu możemy łatwo wyciągnąć pojedynczą nić – aspekt. Idąc tym torem rozumowania stajemy jednak przed pytaniem czym są zatem punkty przecięcia i punkty wejścia w programowaniu aspektowym?
Wróćmy na chwilę do świata obiektów. W naszym Obiektowie (genialne pojęcie wymyślone przez Piotr Rajce przy tłumaczeniu
Head First Object-Oriented Analysis and Design) na poziomie abstrakcji mamy Obiekty i ich interakcje. Jeżeli jednak zejdziemy do dzielnicy Javowo to zobaczymy, że poza Obiektami mamy jeszcze Klasy, Interfejsy, Enumy, Adnotacje i wiele innych elementów języka. No właśnie… języka… Język programowania niezależnie od realizowanych paradygmatów można podzielić na dwa elementy – specyfikację i implementację. Specyfikacja jest to opis jak realizowane są paradygmaty, jakie elementy zawiera język w celu osiągnięcia tego celu i jak elementy języka mają się do modelu ogólnego. Implementacja znowuż to praktyczna realizacja specyfikacji.
W takim kontekście AspectJ jest rozszerzeniem języka Java o paradygmat aspektowy. Rozszerzenie to specyfikuje nowe elementy języka – punkty dostępu, punkty przecięcia, porady, deklaracje oraz ich interakcję z innymi, już istniejącymi, elementami, a także implementuje tą dodatkową specyfikację.
Uff… rozumiecie coś z tego? Jeżeli tak to dobrze, jeżeli nie to też dobrze.

Każdy programuje aspektowo

Każdy chyba liznął “programowania w html i css”. Można zatem powiedzieć, że w pewnym sensie miał już do czynienia z programowaniem aspektowym. Nie jasne? Wróćmy więc od teorii. Paradygmat aspektowy mówi nam o aspektach. Nie mówi nic o konkretnej realizacji. Jeżeli popatrzymy na zwykłe dokumenty html i css oraz to jak realizowana jest ich obsługa w przeglądarce to pewne skojarzenia zaczynają się same nasuwać. Po pierwsze dokument html jest zbiorem punktów dostępu. Każdy element dokumentu jest takim punktem ponieważ można dla niego stworzyć regułę CSS. Każdy zdefiniowany selektor w dokumencie CSS jest punktem przecięcia. Wskazuje on jaki punkt dostępu należy wybrać i zaaplikować mu poradę – zestaw stylów.
Podobnie można opisać bazę danych. Każda krotka jest punktem dostępu. Zapytanie języka danych jest punktem przecięcia. Rezultat jest poradą.

Punkt dostępu i punk przecięcia w Javie

Popatrzmy zatem na kod Javy. Każda metoda jest punktem dostępu. Punktami takimi w rozumieniu AspectJ – czyli konkretnej implementacji aspektowej, są też – inicjacja klasy (jej ładowanie), obiektu (jego tworzenie), porada (tak jak metoda) oraz aspekt (tak jak klasa – aspekty są domyślnie singletonami). Dość specyficznymi w “załapaniu” punktami dostępu są też miejsca odczytu i przypisania wartości do pola obiektu. AspectJ nie umieszcza na liście punktów dostępu elementów kodu takich jak pętle, instrukcje warunkowe, bloki kodu, etykiety (tak w Javie mamy etykiety).
Punktem przecięcia jest zdefiniowany, za pomocą specjalnego języka, podzbiór punktów dostępu. Punkt przecięcia używa w swoich definicjach składni podobnej do tej znanej z sygnatur metod. Mamy zatem możliwość wyboru punktu dostępu na podstawie nazwy lub jej części np. * *.set*(..) – oznacza dowolną metodę, której nazwa zaczyna się od set, modyfikatora dostępu, nazwy pakietu, ilości oraz rodzaju argumentów w metodzie, adnotacji, użytych typów generycznych, zwracanych wyjątków, hierarchii dziedziczenia np. * NKWD+ oznacza każdą klasę dziedziczącą po NKWD (wybór tylko w dół hierarchii). Do punktu przecięcia, a w praktyce do wszystkich wybranych przez niego punktów dostępu, stosuje się poradę.

Podsumowanie

Zrozumienie modelu w jakim pracują punkty przecięcia jest bardzo trudne, ale to kluczowy element AspectJ. Na całe szczęście można pociąć ten temat na mniejsze i prostsze dawki. Na początek wystarczy to co już widzieliśmy, czyli dostęp do metod i typów na podstawie nazwy lub dodanej im adnotacji.
Na chwilę obecną nie będę poruszał problemu punktów przecięcia dla kontekstu wywołania.

Dodaj do

Rodzaje porad

Porada jest to pojedyncza operacja wstawiana w odpowiedni punkt przecięcia. Generalnie istnieją trzy rodzaje porad (i ich zrozumienie jest naprawdę proste w porównaniu z definicjami punktów przecięcia). Pierwszy to znana nam już porada before. Wstawiana jest w kod przed wykonaniem danego działania. Po jej wykonaniu wykonywany jest kod punktu przecięcia.
Drugim rodzajem porad są porady after. Tu sprawy trochę się komplikują. Po pierwsze mogą wystąpić trzy podrodzaje porady. Pierwsze to zwykłe porady. Wykonane będą zawsze po kodzie punktu przecięcia. Jeżeli wysypie się on z jakimkolwiek błędem nasza porada zostanie wykonana i dopiero po niej zostanie wyrzucony błąd. Drugie to porady afterthrowing, które wykonają się wtedy i tylko wtedy, gdy kod punktu przecięcia wywali wyjątek. Kod porady wykona się przed zwróceniem wyjątku lub po, bo całość nie jest jakoś specjalnie synchronizowana. Trzeci rodzaj to porady afterreturning, które to wykonają się tylko wtedy gdy kod w punkcie przecięcia zakończy się prawidłowo. Poniżej przykładowy aspekt, który ilustruje działanie wszystkich tych dróg:

Listing 1. Porada typu after

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.AfterThrowing;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class ErrorHandlerAspect {

	@Pointcut("execution(* NKWD.*(..))")
	public void handleError(){}

	@After("handleError()")
	public void handleErrorAdvice(){
		System.out.println("Metoda wyrzuca błąd");
	}

	@AfterThrowing(value = "handleError()", throwing = "runtimeException")
	public void handleErrorThrowsAdvice(RuntimeException runtimeException) {
		System.out.println("Metoda wyrzuciła błąd: "
				+ runtimeException.getLocalizedMessage());
	}

	@AfterReturning("handleError()")
	public void handleErrorNotThrowAdvice(){
		System.out.println("Metoda nie wyrzuciła błędu");
	}
}

Pobaw się z dodawaniem deklaracji wyjątku do klasy NKWD i zobacz co się stanie.
Trzeci rodzaj porad to porady around. Są one szczególnie przydatne wszędzie tam, gdzie zazwyczaj do wykonywania jakiś czynności wykorzystujemy wzorzec metody szablonowej. Jednocześnie szablon nie realizuje samego algorytmu, a jedynie pozwala na wykonanie czynności takich jak logowanie startu i końca akcji, blokowanie obiektów (ukochany ReadWriteLock), rozpoczynanie i kończenie transakcji, proste profilowanie. Kolejnym wzorcem, który można zastąpić tym rodzajem porady jest dekorator. Bardzo dobrym pomysłem jest dekorowanie obiektów w sposób przezroczysty dla klienta. Niestety klient musi w takim wypadku korzystać z interfejsu do komunikacji z obiektem (co jest bardzo fajne) i uzyskiwać obiekty z jakiejś fabryki (co jest upierdliwe zarówno dla klienta jak i programisty). Oczywiście jest Spring, EJB3.x czy Pico, ale jakoś nie widzę sensu ich użycia tylko dla jednego małego dekoratora (pamiętaj, używanie frameworków powoduje gwałtowne rozrastanie się kodu wynikowego). Zresztą nie zawsze da się użyć frameworku.
Problemem z tym rodzajem porady jest konieczność wstawienia jakiegoś elementu, który pozwalał by na określenie jaki kod ma być wykonany przed, a jaki po wykonaniu kodu punktu przecięcia. AspectJ dostarcza odpowiedniego pseudo słowa kluczowego proceed(). Jest to pseudo słowo kluczowe ponieważ w praktyce jest to metoda
Napiszmy profiler, który będzie sprawdzał ile czasu zajmuje użytkownikowi wpisanie hasła. Przy okazji mały refaktoring kodu NKWD:

Listing 2. Nowa wersja NKWD

package pl.koziolekweb.blog.aspectj;

import java.util.Scanner;

public class NKWD {

	private boolean isAuth = false;

	public void auth(){
		if (isAuth) {
			return;
		} else {
			String password = readPassword();
			isAuth = validatePassword(password);
			if (!isAuth) {
				throw new RuntimeException("Wypad na Łubiankę");
			}
		}
	}

	private String readPassword() {
		System.out.print("podaj hasło: ");
		Scanner scanner = new Scanner(System.in);
		String password = scanner.next();
		return password;
	}

	private boolean validatePassword(String password) {
		return "dupa".equals(password);
	}
}

Czas na nasz nowy aspekt

Listing 3. Aspekt profilujący.

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class InputProfilingAspect {

	@Pointcut("call(* java.util.Scanner.next(..))")
	public void profile() {
	}

	@Around("profile()")
	public Object profileAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
		long start = System.nanoTime();
		Object processResult = joinPoint.proceed();
		long stop = System.nanoTime();
		System.out.println("Czas wpisania hasła: "
				+ ((stop - start) * 0.000000001) + " sekundy");
		return processResult;
	}
}

Kolejnym problemem jest konieczność zachowania sygnatury dekorowanej metody. Zatem w przypadku wykorzystania składni @AspectJ jak i .aj należy zadbać by porada zwracała odpowiedni obiekt. Na całe szczęście proceed zwraca Object, a odpowiednie rzutowanie zostaje wykonane poza naszą ingerencją przez weavera. Co jednak w przypadku gdy metoda przyjmuje parametry? Sprawdźmy ile czasu zajmie wypisanie komunikatu powitalnego dla konkretnego użyszkodnika.

Listing 3. Aspekt profilujący z parametrami.

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class MessageProfilingAspect {

	@Pointcut("call(* Service.welcome(String)) && args(string)")
	public void profile(String string){}

	@Around("profile(string)")
	public void proflieAdvice(ProceedingJoinPoint joinPoint, String string) throws Throwable{
		long start = System.nanoTime();
		joinPoint.proceed(new Object[]{string});
		long stop = System.nanoTime();
		System.out.println("Czas wpisania wiadomości: "
				+ ((stop - start) * 0.000000001) + " sekundy");
	}

}

Jak widać coś jest nie tak. Czasy się nie zgadzają. Czas wypisania komunikatu jest dłuższy niż czas wpisywania hasła. Wniosek, czas jest liczony globalnie. Cóż… takie życie. Wynika to z modelu jaki przyjęto dla tworzenia aspektów. Opisze to później, a na teraz należy pamiętać, że domyślnie aspekty są tworzone jako singletony.

Podsumowania

Wiemy już jakie mamy rodzaje porad. Jeżeli nie rozumiesz jak to działa to nie przejmuj się. Zrozumienie tego modelu tak jak zrozumienie modelu punktów przecięcia wymaga dużo czasu i jeszcze więcej praktyki. W następnej części omówię właśnie model punktów przecięcia. Jest to bardzo ważna i bardzo trudna rzecz. Dlatego też skupię się na podstawowych rodzajach punktów przecięcia.

Dodaj do

Aspekt jako klasa Java

Każdy plik .java jest prawidłowym plikiem dla kompilatora ajc. Z drugiej strony plik .aj nie jest akceptowany przez kompilator java, chyba że nie ma w nim żadnych elementów aspektowych (co jest głupie w takim przypadku). Mamy jednak do dyspozycji mechanizm adnotacji, który pozwala na tworzenie kodu aspektów za pomocą standardowych mechanizmów języka. Sięgając do przykładu ze wczoraj przepiszmy nasz aspekt na czysty kod javowy.

Listing 1. Aspekt jako klasa Java

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class SecurityAspect {

	private NKWD nkwd = new NKWD();

	@Pointcut("call( * Service.welcome(..))")
	public void auth() {
	}

	@Before("auth()")
	public void authBefore() {
		System.out.println("NKWD działa");
		nkwd.auth();
	}

}

Jak widać wszystko jest bardzo przejrzyste i jasne. Jedynym wrzodem na dupie jest tu konieczność tworzenia nadmiarowego kodu do definiowania punktów przecięcia. Po co ta pusta metoda? Ja nie wiem i nie rozumiem.
Generalnie wszytko bangla. Co ciekawe jak w linii poleceń zrobimy sobie coś takiego:

Listing 2. Aspekt kompilowany javac

C:\Documents and Settings\Asia\workspace\SimpleAspectJ\src>javac -d ..\bin pl\koziolekweb\blog\aspectj\*.java -classpath g:\Bartek\eclipse\plugin\org.aspectj.runtime_1.6.6.20090930185500\aspectjrt.jar;.

To po uruchomieniu kodu całość będzie działać, a jedyną różnicą będzie brak aspektów. No właśnie jak działa kompilator…

Mechanizm waevingu AspectJ

Istnieją trzy metody wstrzykiwania kodu aspektu do kodu programu. Pierwszy z nich to mechanizm statyczny oparty o analizę kodu źródłowego. Jest on bardzo dobry jeżeli chcemy wstawić kod “na mur beton”. Dodatkowo za pomocą analizy statycznej można rozszerzyć klasę o dodatkowe interfejsy wraz z implementacją (też będzie o tym). Z drugiej strony statycznie nie uzyskamy kontekstu wywołania aspektu co powoduje, że odpadają nam pewne fajne feature’y. Metoda ta jest stosowana przez bezpośrednie wywołanie kompilatora ajc w eclipse.
Drugą metodą jest wstawianie w bytecode. Jeżeli mamy skompilowany kod javowy i aspektowy w osobnych bibliotekach to za pomocą kompilatora ajc możemy dokonać modyfikacji kodu bajtowego i wstawić kod aspektu. To też jest mechanizm statyczny, jednak umożliwia wykonanie wiązania na kodzie do którego nie mamy źródeł. Jest to bardzo przydatne rozwiązanie gdy chcemy dokonać reverse engineeringu na małą skalę tzn. chcemy zmienić sposób działania biblioteki bez modyfikacji źródeł i pisania kodu związanego (rozszerzającego) z tą biblioteką. Mechanizm ten można porównać do linkera znanego z C/C++. Nie jest to to samo, ale generalnie efekt jest zbliżony.
Trzecią metodą jest dynamiczne wiązanie kodu aspektu z kodem aplikacji. Jest to upierdliwe, ale bardzo dobre jeżeli zależy nam na aspektach wykonywanych w ramach kontekstu wykonania (o tym też będzie). Generalnie sprowadza się to do napisania pliku XML i umieszczeniu go w katalogu META-INF. Następnie wystarczy uruchomić JVM z odpowiednim parametrem.

Listing 3. Plik aop-ajc.xml

Listing 4. Użycie agenta

C:\Documents and Settings\Asia\workspace\SimpleAspectJ\bin>java -classpath g:\Bartek\eclipse\plugins\org.aspectj.runtime_1.6.6.20090930185500\aspectjrt.jar;.;.\META-INF -javaagent:g:\Bartek\eclipse\plugins\org.aspectj.weaver_1.6.6.20090930185500\aspectjweaver.jar pl.koziolekweb.blog.aspectj.Main

Tu uwaga ważna jest kolejność parametrów najpierw classpath, potem javaagent, a na końcu klasa uruchamiana. Inaczej nie będzie banglać.
Ostatnim elementem naszej zabawy w dniu dzisiejszym będzie odpowiedź na pytanie jak używać aspektów odnośnie klas adnotowanych. Skoro już umiemy definiować aspekty jako klasy java za pomocą adnotacji to należy uzupełnić ten kawałek wiedzy.

Po co nam adnotacje?

W naszym przykładzie byliśmy proszeni o hasło przed uruchomieniem metody welcome(), ale chcemy, żeby system jednak pozwalał nam na wyświetlenie komunikatu powitalnego i po zalogowaniu komunikatu dla konkretnego użyszkodnika. W pierwszym odruchu można zmienić definicję punktu przecięcia, ale jest to do dupy. Dwa główne powody to ograniczenie zasięgu aspektu do metod o konkretnej nazwie co może i jest fajne, ale niestety mało przydatne oraz pozbawianie się przenośności. W dużym systemie ten drugi powód jest szczególnie widoczny, ponieważ musimy definiować punkty przecięcia dla wielu klas z różnych pakietów. Powoduje to niepotrzebną komplikację kodu i utrudnia późniejszą jego konserwację.
Na początek dopiszmy jeszcze jedną klasę, które będzie siedziała w innym pakiecie niż nasza aplikacja oraz będziemy wykorzystywać jej metody podobnie jak klasy Service:

Listing 5. Klasa SomeService

package pl.koziolekweb.blog.aspectj.services;

public class SomeService {

	public void message() {
		System.out.println("wiadomość");
	}

	public void messageToHex(Long long1) {
		System.out.println("Wartość hex: " + Long.toHexString(long1));
	}
}
// zmiany w Main
	service.welcome("Koziołek");
	SomeService someService  = new SomeService();
	someService.message();
	someService.messageToHex(new Long(666l));

Jeżeli teraz trzeba było by dla każdej metody, którą chcemy zabezpieczyć, definiować pountcut to jedyną słuszną drogą było by pocięcie się. Zdefiniujmy sobie zatem adnotację @Secure

Listing 5. Adnotacja Secure

package pl.koziolekweb.blog.aspectj;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.METHOD,ElementType.TYPE})
public @interface Secure {

}

Oznaczymy teraz za jej pomocą metodę Service.welcome(String) i klasę SomeService. Następnie zmieńmy nasz aspekt na taki jak poniżej:

Listing 6. Nowa wersja aspektu.

package pl.koziolekweb.blog.aspectj;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class SecurityAspect {

	private NKWD nkwd = new NKWD();

	@Pointcut("execution( @Secure * *(..)) || call( * (@Secure *).*(..))")
	public void auth() {
	}

	@Before("auth()")
	public void authBefore() {
		System.out.println("NKWD działa");
		nkwd.auth();
	}

}

Uruchamiamy

Listing 7. Wynik działania programu

Witamy w systemie
NKWD działa
podaj hasło: dupa
Witaj Koziołek
NKWD działa
wiadomość
NKWD działa
Wartość hex: 29a

Jak widać wszystko zadziałało zgodnie z oczekiwaniami. Jedynym dużym wrzodem jest tutaj definicja podana w punkcie przecięcia, ale brak mi jeszcze wprawy by zapisać ładniej warunek. Z drugiej strony jest on moim zdaniem jaśniejszy, bo w kolejnych elementach wyrażenia warunkowego widać co odnosi się do metody, a co do typu.
Ostatnią kwestia jest różnica pomiędzy execution i call. Generalnie żadna nie jest widoczna w działaniu. W przypadku execution kod aspektu wstawiany jest do ciała metody (na początku lub końcu). W przypadku call kod jest wstawiany w każdym miejscu wywołania.

Podsumowanie

Jak widać programowanie aspektowe daje ogromne możliwości, a odpowiednie zastosowanie jego elementów ułatwia życie.

Dodaj do

Instalacja softu

Z tej strony pobieramy odpowiedni dla nas pakiecik i restartujemy Eclipse. Zakładam, że wiesz jak instalować plugin eclipsowy za pomocą Update Site. Jeżeli nie to sorry Winnetou. Kurs będzie mocno Eclipse only.
Następnie tworzymy nowy projekt AspectJ. Zostaniemy zapytani czy chcemy włączyć mechanizm weaveringu i zrestartować Eclipse. Oczywiście włączamy go i restartujemy IDE.

Podstawowe pojęcia

W tradycyjnym modelu obiektowym gdy zaczynamy pisać program to okazuje się, że w pewnym momencie należy do naszego kodu dodać kilkanaście różnych ciekawych czy nie, ale wymaganych funkcjonalności. Zazwyczaj jest to logowanie, kontrola dostępu, jakieś duperele związane z profilowaniem. Robiąc to za pomocą klasycznych metod zazwyczaj łamiemy dwie zasady. Po pierwsze SRP ponieważ nasza klasa zaczyna mieć wiele odpowiedzialności. A to logowanie, a to security, a tu jeszcze admin mówi, żeby włączyć profilowanie w jednym miejscu i natłuc raportów. Poza tym robi się burdel w kodzie. Oczywiście w pewnym momencie dochodzimy do wniosku, że większość z tych bajerów nie jest nam potrzebna i łamiemy OCP. Ponieważ by je wyłączyć zaczynamy grzebać w oryginalnym kodzie. Tu z pomocą przychodzą nam aspekty. Aspekt jest to moduł aplikacji zawierający jakąś funkcjonalność, która jest wtłaczana do kodu za pomocą kompilatora aspektowego. Aspekt jest opisany za pomocą specjalnego języka, na którego podstawie kompilator odpowiednio modyfikuje kod wynikowy w procesie kompilacji. Poniżej kilka ważnych pojęć
Punkt dostępu – ang. Join Point – dowolny punkt w kodzie, w którym kompilator aspektowy może wstawić kod aspektu. To czym jest ten punkt zależy od konkretnej implementacji języka aspektowego. W przypadku AspectJ są to metody, klasy, pola.
Punkt przecięcia – ang. Pointcut – konkretny punkt dostępu do którego stosowany jest dany aspekt.
Porada – ang. advice – kod który jest wstawiany.
Wiem, że osoby, które miały do czynienia z programowaniem aspektowym uznają ten opis za uproszczony, ale KISS MY ASS (Keep Is Simple Stupid. Mayby You Are Support Soft).

Co to jest AspectJ?

Znowu upraszczając jest to rozszerzenie języka Java o kilka słów kluczowych i mechanizm weaveringu, czyli właśnie wkompilowywania kodu. Inaczej rzecz ujmując jest to biblioteka, która zawiera specjalny kompilator, będący rozszerzeniem kompilatora javy o funkcjonalność jaką jest obsługa aspektów. Zawiera specjalnego agenta JVM, który może wykonać pracę kompilatora w trakcie ładowania kodu. Jest to zacne i przydatne rozwiązanie.
AspectJ wspiera dwa rodzaje składni. Pliki .aj, które są “naturalne” w jego środowisku oraz mechanizm oparty o adnotacje i zwykłe klasy javy. Przy czym każdy prawidłowy plik java jest prawidłowym plikiem aspektowym. Koniec końców AspectJ jest tylko rozszerzeniem języka (trochę jak C++ do C), a nie czymś całkowicie nowym.

Zajawka

Dzisiejszą część poświęcimy tylko na prostą aplikację w tylu “hello world”, ale pozwoli ona załapać Ci jak działa programowanie aspektowe. Na początek mamy kod taki jak poniżej:

Listing 1. Bazowa aplikacja

package pl.koziolekweb.blog.aspectj;

public class Main {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Service service = new Service();
		service.welcome();
		service.welcome("Koziołek");
	}

}
//....
package pl.koziolekweb.blog.aspectj;

public class Service {
	public void welcome() {
		System.out.println("Witamy w systemie");
	}

	public void welcome(String name) {
		System.out.println("Witaj " + name);
	}
}

Naszym zadaniem jest zabezpieczyć aplikację przed niepożądanymi wywołaniami. Posłuży nam do tego specjalna klasa NKWD:

Listing 2. Klasa NKWD – odpowiada za bezpieczeństwo

package pl.koziolekweb.blog.aspectj;

import java.util.Scanner;

public class NKWD {

	private boolean isAuth = false;

	public void auth() {
		if (isAuth) {
			return;
		} else {
			System.out.print("podaj hasło: ");
			Scanner scanner = new Scanner(System.in);
			String password = scanner.next();
			if ("dupa".equals(password)) {
				isAuth = true;
			}
			else{
				throw new RuntimeException("Wypad na Łubiankę");
			}
		}
	}
}

Pytanie co zrobimy w klasycznym podejściu? Pewno wystarczy utworzyć fabrykę obiektów NKWD, która będzie dbała o to by do każdego wątku był przyporządkowany odpowiedni obiekt NKWD. Będziemy go pobierać w każdej metodzie i w razie czego sprawdzać… no cóż… chłopaki od php zapewne by na tym poprzestali, ale mają łatwiej, bo jest u nich funkcja require_once i przetwarzanie skryptu zatem można takie sztuki robić. My niestety używamy języka programowania i zastosujemy programowanie aspektowe.
Stworzymy zatem aspekt, który będzie przed każdym wywołaniem metody welcome sprawdzał czy wszystko śmiga.

Listing 3. Nasz pierwszy aspekt

package pl.koziolekweb.blog.aspectj;

public aspect SecurityAspect {
	private NKWD nkwd = new NKWD();

	pointcut auth() : call( * Service.welcome(..));

	before() : auth() {
		System.out.println("NKWD działa");
		nkwd.auth();
	}
}

Kompilujemy i uruchamiamy jako aplikację AspectJ. Efekt:

Listing 4. wyniki działania naszego pierwszego aspektu

NKWD działa
podaj hasło: dupa
Witamy w systemie
NKWD działa
Witaj Koziołek

Chwila ze składnią

Za pomocą słowa pointcut definiujemy miejsce przecięcia. Format jest dość swobodny w przypadku AspectJ zazwyczaj używamy składni bardzo zbliżonej do UMLowego definiowania sygnatur metod. Znak * oznacza dowolne słowo, a .. dowolną ilość słów.
Słowo before wskazuje, że dana porada będzie uruchamiana przed wywołaniem dowolnej metody pasującej do wskazanego punktu przecięcia.

Podsumowanie

Czytam “AspectJ in Action” i mam nadzieję, że powstanie kacusiowa recenzja.

Dodaj do

Dziś stanąłem przed poważnym problemem. Jak przetestować narzędzie do komunikacji z Google Translate zza proxy. Niby prosta rzecz. Wystarczy tylko przy odpalaniu mavena dać mu odpowiednie ustawienia. Tylko, że ja jestem cholernie leniwy (cnota programisty). Dlatego też poszukiwałem rozwiązania, które pozwoli mi zastąpić każdorazowe klepanie konfiguracji proxy.

Własny plugin = epic fail

Co tu dużo mówić. Straciłem 2 godziny bo zapomniałem, że JUnit odpala się w ramach odizolowanego środowiska co oznacza, że nie może przejmować ustawień w stylu System.setProperty(). W każdym bądź razie wiem już jak pisać i testować pluginy do mavena. Zawsze coś.

AspectJ to Malleus Maleficarum^W

Idea wydaje się na pierwszy rzut granatu poroniona. Programowanie aspektowe jest w swej istocie dość skomplikowanym procesem, a w przypadku Javy to naprawdę wyższa szkoła jazdy na kucykach. Jednak jeżeli pomyślimy przez chwilę to okazuje się, że nie taki diabeł straszny. Szczególnie, że jeżeli weźmiemy pod uwagę fakt, że jeżeli źle coś napiszemy to okazuje się iż testy po prostu nie zadziałają.
Na czym polega myk? Otóż wystarczy, że wstrzykniemy kod przed każdym wykonaniem metody before(). W sumie nie ma znaczenia fakt, że wydłuży to testy. Testy są po to by mieć czas na kawę, a nie po to by były szybkie.

Praktyka

Klasa testująca wygląda w następujący sposób:

Listing 1. Nieszczęśliwy test

/**
 *
 */
package pl.koziolekweb.translator.engine;

import junit.framework.Assert;

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

import pl.koziolekweb.translator.engine.googleimpl.Language;
import pl.koziolekweb.translator.engine.googleimpl.TranslatorImpl;

/**
 * @author koziolek
 *
 *
 */
// Info: $Id: TranslatorTest.java 161 2009-03-16 22:26:47Z bjkuczynski $
public class TranslatorTest {

	public static Translator translator;

	public static final String PL_TEXT = "nie";
	public static final String EN_TEXT = "no";
	public static final Language DEFAULT_LANGUAGE = Language.POLISH;

	@Test
	public void testTranslateToNativeFromAuto() throws Throwable {
		Assert.assertEquals(PL_TEXT, translator.translate(PL_TEXT));
	}

	@Test
	public void testTranslateToNativeFromSet() throws Throwable {
		Assert.assertEquals(PL_TEXT, translator.translate(EN_TEXT,
				Language.ENGLISH));
	}

	@Test
	public void testTranslateToSetFromSet() throws Throwable {
		Assert.assertEquals(EN_TEXT, translator.translate(PL_TEXT,
				Language.POLISH, Language.ENGLISH));
	}

	@Before
	public void before() {
		translator = new TranslatorImpl(DEFAULT_LANGUAGE);
	}

	@After
	public void after() {
		translator = null;
	}
}

Metoda translate() wykonuje m.n. połączenie z jakimś zdalnym serwisem tłumaczącym. W tym przypadku jest to Google Translate. W aplikacji będą odpowiednie ustawienia, ale w czasie testów nie chcemy ich tworzyć. Jednocześnie nie chcemy ingerować w kod testów ani kombinować z dynamicznym ładowaniem ustawień w testach. Dlatego też piszemy aspekt, który rozwiązuje nam ten problem. Oto on:

Listing 2. Nieszczęśliwy aspekt

package pl.koziolekweb.translator.engine;

import java.io.FileInputStream;
import java.util.Properties;

public aspect ProxyConfig {

	private String proxySet;
	private String proxyHost;
	private String proxyPort;

	public ProxyConfig() {
		Properties properties = new Properties();
		try{
		properties.load(new FileInputStream(
				"./src/test/resources/proxy.properties"));
		}
		catch(Exception e){
			throw new RuntimeException(e);
		}
		proxySet = properties.getProperty("proxySet");
		proxyHost = properties.getProperty("proxyHost");
		proxyPort = properties.getProperty("proxyPort");
	}

	pointcut config():
		execution( void pl.koziolekweb.translator.engine.*Test.before());

	before(): config() {
		System.out.println("[ASPECT] Configure Proxy: ");
		System.out.println("[ASPECT] Use Proxy   : " + proxySet);
		System.out.println("[ASPECT] Proxy Host  : " + proxyHost);
		System.out.println("[ASPECT] Proxy Port  : " + proxyPort);

		System.getProperties().put("proxySet", proxySet);
		System.getProperties().put("proxyHost", proxyHost);
		System.getProperties().put("proxyPort", proxyPort);
		System.out.println("[ASPECT] Proxy Configured ");
	}
}

Jak widać za trudne to nie jest. Nie powinno się też jakoś magicznie wywalać. Kolejny krok to konfiguracja w pom.xml kompilatora AspectJ.

Listing 3. Nieszczęśliwy pom.xml

<profiles>
	<profile>
		<id>proxy</id>
		<build>
			<plugins>
				<plugin>
					<groupId>org.codehaus.mojo</groupId>
					<artifactId>aspectj-maven-plugin</artifactId>
					<version>1.1</version>
					<configuration>
						<source>1.5</source>
						<target>1.5</target>
					</configuration>
					<executions>
						<execution>
							<id>test</id>
							<phase>test-compile</phase>
							<goals>
								<goal>test-compile</goal>
							</goals>
						</execution>
					</executions>
				</plugin>
			</plugins>
		</build>
	</profile>
</profiles>

I bangla.

Podsumowanie

Dlaczego tak kombinuję? Przecież skoro mam możliwość konfiguracji proxy w aplikacji to mogę wywołać metodę i skonfigurować je w testach. Tyle tylko, że jeżeli tak zrobię to uzależniam test od mechanizmu testowanego. Co jeżeli ustawianie proxy nie działa? Jeżeli tamte testy padną? Tu mam możliwość sprawdzenia czy wszystko działa za pomocą odpowiednich narzędzi. Odpowiedni dobór narzędzia umożliwił mi w tym przypadku maksymalizację zysków przy minimalnych kosztach. Istotne jest to, że konfigurację testów przerzucam poza testy. Całość jest nieinwazyjna i nie zakłóca “logiki biznesowej” testów.

//
Poza tym szukałem pretekstu by poznać AspectJ i nauczyć się pisania pluginów do mavena.

Dodaj do