Das Applikation Framework Spring bringt ein sehr n\u00fctzliches Feature mit: Autoproxing. Damit lassen sich Spring Beans – also eigentlich jede POJO-Klasse – um Aspekte erweitern. Aspekte sind gem\u00e4ss AOP Belange eines Programms die sich quer zur eigentlichen Programmlogik erstecken (Cross-Cutting-Concerns). <\/p>\n
In der Aspektorientierten Programmierung kann man diese Aspekte getrennt vom Rest des Programms formulieren und erst die AOP Umgebung "verwebt" den Aspektcode mit dem eigentlichen Programmcode. Hier gibt es prinzipiell zwei unterschiedliche Vorgehensweisen 1. zur Compile-Time (w\u00e4hrend des Kompilierens) oder 2. zur Run-Time (w\u00e4hrend der Laufzeit). <\/p>\n
Der bekannteste Vertreter der 1. Variante ist sicher AspectJ, welches eine eigene Sprache formuliert und folglich auch einen eigenen Compiler mitbringt. Dieser Compiler sorgt f\u00fcr das Zusammenweben von Aspekten und restlichem Programmcode. Die Sprache liefert alle Mittel um Aspekte zu formulieren und dar\u00fcber hinaus festzulegen an welchen Stellen der Aspect-Code eingebunden werden muss (Definition von sogenannten Pointcuts). <\/p>\n
Beim Spring-Framework wird der Aspect-Code erst zur Laufzeit dem restlichen Programm hinzugef\u00fcgt. Wie kann man sich das vorstellen? Da Spring Bean-Instanzen immer \u00fcber die BeanFactory erzeugt werden, kann die Factory die erzeugten Instance beliebig ver\u00e4ndern, solange sie f\u00fcr die Applikation nur "so aussehen" wie eine Bean vom Type XY. Bei Beans die ein bestimmtes Interface implentieren, bedeutet das, das die erzeugte Instance eben immer noch diese Interface implementieren muss. Wird kein Interface implementiert, so wird eine abgeleitete Klasse mindestens die gleichen "Public-Methods" bieten, wie die Basis-Klasse. <\/p>\n
<\/p>\n
Mit Hilfe dieser Logik arbeitet das Proxy-Feature von Spring: Bei Klassen die ein Interface implentieren verwendet Spring sogenannte Dynamic-Proxies (seit JDK 1.4) ansonsten wird mit Hilfe der "Code-Generating-Library" CGLib dynamisch eine abgeleitete Klasse gebildet und diese instanziiert. <\/p>\n
Auf diese Weise kann Spring nun auf Wunsch jeden Methodenaufruf einrahmen (wrappen), um vor oder nach dem Methodenaufruf (oder beides) Aspektcode auszf\u00fchren. <\/p>\n
Damit man dieses Verhalten nun nich explizit in die BeanFactory bei allen Bean konfigurieren muss, kennt Spring das AutoProxy-Feature. Einmal aktiviert, wird bei jeder Bean automatisch \u00fcberpr\u00fcft, welche Methoden mit welchen Aspekten zu versehen sind. <\/p>\n
Dieser Zusammenhang wird nun nicht mit einer speziellen Sprache wie bei AspectJ festgelegt, sondern in nomalem Java "ausprogrammiert". Man schreibt einen sogenannten "Advisor", der das Interface org.springframework.aop.PointcutAdvisor<\/b> implementiert. Sobald Spring nun einen potentiellen Kandidaten f\u00fcr das AutoProxing instanziieren soll, wird der Advisor der Reihe nach bei allen Methode gefragt, ob und mit welchem "Advise" die Methode versehen werden soll. <\/p>\n
Das Nutzen von Aspekten soll nun besonders einfach gestaltet werden in dem man Annotationen verwendet. \u00dcber Annotationen k\u00f6nnen Klassen oder Methoden (ja selbst Parameter) mit Metainformatonen versorgt werden, die mit Hilfe des neuen Reflection API von Java 5 auch zur Laufzeit abgefragt werden k\u00f6nnen. <\/p>\n
Leider bin ich bei meinem ersten Ansatz mit einem SpringAdvisor auf Probleme gestossen: <\/p>\n
Solange es sich um Klassen handelte, die kein Interface implementierten und von daher mittels Code-Generation erweitert werden k\u00f6nnen, funktionierte noch alles wie erwartet. <\/p>\n
Ein Problem trat auf als eine Klasse mit Annotationen versehen wurde, die ein oder mehrere Interfaces implementierte. Wenn man die Calls an den Advisor mitprotokolliert, kann man sehn, dass f\u00fcr Methoden, die Teil des Interfaces sind, der Advisor "zweimal" aufgerufen wird: einmal f\u00fcr die konkrete Implementierung der Klasse, die Spring konkret instanziiert, einmal f\u00fcr die abstracte Interface-Methode. <\/p>\n
Ein solcher einfacher Advisor sieht so aus: <\/p>\n
\npackage <\/span>com.rinke.solutions.spring.test.aop;<\/p>\n
<\/span>import <\/span>java.lang.annotation.Annotation;
\n<\/span>import <\/span>java.lang.reflect.Method;<\/p>\n<\/span>import <\/span>org.springframework.aop.support.StaticMethodMatcherPointcutAdvisor;<\/p>\n
<\/span>\/**
\n * advisor that adds advice to a class od method, when a special annotation is present.
\n * <\/span>@author <\/span>ster
\n *\/
\n<\/span>public class <\/span>SimpleAnnotationSourceAdvisor <\/span>extends <\/span>StaticMethodMatcherPointcutAdvisor <\/span>{<\/p>\n<\/span>\/** stores the annatation class to check.*\/
\n <\/span>private <\/span>Class<? <\/span>extends <\/span>Annotation> annotationToCheck;
\n
\n <\/span>public <\/span>void <\/span>setAnnotationToCheck<\/span>(<\/span>Class<? <\/span>extends <\/span>Annotation> annotationToCheck<\/span>) {
\n <\/span>this<\/span>.annotationToCheck = annotationToCheck;
\n <\/span>}<\/p>\n<\/span>public <\/span>boolean <\/span>matches<\/span>(<\/span>Method method, Class clazz<\/span>) {
\n <\/span>return <\/span>method.isAnnotationPresent<\/span>(<\/span>annotationToCheck<\/span>)<\/span>;
\n <\/span>}
\n }<\/span><\/tt>\n<\/p><\/blockquote>\nEs wird einfach nur gepr\u00fcft, ob bei der betroffenen Methode die "annotationToCheck" vorhanden ist. <\/p>\n
Wenn der Advisor nun "den Fehler" macht, den Advice nicht auch f\u00fcr die abstracte Methode des Interfaces zu setzen, dann wird der sp\u00e4tere Aufruf aus der Applikation, immer dann ohne <\/i>den Advice ausgef\u00fchrt, wenn der Caller nur<\/i> mit dem Interface arbeitet. <\/p>\n
Da der Advisor sich nach den Annotationen richtet, mit denen die Methode versehen ist, kann man dem dadurch begegnen, dass man auch die abstrakte Interface-Methode annotiert. Allerdings ist es oft gar nicht m\u00f6glich oder w\u00fcnschenswert, das Interface zu annotieren. Der Aspekt ist Teil der konkreten Implementierung und hat mit dem Interface nichts zu tun. <\/p>\n
Man kann dem aus dem Weg gehen, wenn man den Advisor etwas erweitert: <\/p>\n
\npackage <\/span>com.rinke.solutions.spring.test.aop;<\/p>\n
<\/span>import <\/span>java.lang.annotation.Annotation;
\n<\/span>import <\/span>java.lang.reflect.Method;
\n<\/span>import <\/span>java.lang.reflect.Modifier;<\/p>\n<\/span>import <\/span>org.aopalliance.aop.Advice;
\n<\/span>import <\/span>org.springframework.aop.support.StaticMethodMatcherPointcutAdvisor;<\/p>\n<\/span>\/**
\n * advisor that adds advice to a class od method, when a special annotation is present.
\n * <\/span>@author <\/span>ster
\n *\/
\n<\/span>public class <\/span>AnnotationSourceAdvisor <\/span>extends <\/span>StaticMethodMatcherPointcutAdvisor <\/span>{<\/p>\n<\/span>\/** stores the annatation class to check.*\/
\n <\/span>private <\/span>Class<? <\/span>extends <\/span>Annotation> annotationToCheck;
\n
\n <\/span>\/**
\n * default ctor.
\n *\/
\n <\/span>public <\/span>AnnotationSourceAdvisor<\/span>() {
\n <\/span>super<\/span>()<\/span>;
\n <\/span>}
\n
\n <\/span>\/**
\n * sets the advice
\n * <\/span>@see <\/span>org.springframework.aop.support.StaticMethodMatcherPointcutAdvisor#setAdvice(org.aopalliance.aop.Advice)
\n *\/
\n <\/span>public <\/span>void <\/span>setAdvice<\/span>( <\/span>Advice advice <\/span>) {
\n <\/span>super<\/span>.setAdvice<\/span>(<\/span>advice<\/span>)<\/span>;
\n <\/span>}
\n
\n <\/span>\/**
\n * <\/span>@param <\/span>clazz the current class to check
\n * <\/span>@param <\/span>method the current method to check
\n * <\/span>@return <\/span>true, if the specified method has the annotation.
\n * <\/span>@see <\/span>org.springframework.aop.MethodMatcher#matches(java.lang.reflect.Method, java.lang.Class)
\n *\/
\n <\/span>public <\/span>boolean <\/span>matches<\/span>(<\/span>Method method, Class clazz<\/span>) {
\n <\/span>\/\/ this is tricky
\n <\/span>if<\/span>( <\/span>clazz.equals<\/span>(<\/span>method.getDeclaringClass<\/span>())) {
\n <\/span>return <\/span>method.isAnnotationPresent<\/span>(<\/span>annotationToCheck<\/span>)<\/span>;
\n <\/span>} <\/span>else <\/span>{
\n <\/span>\/\/ if the methods declaring class is not the same as the implmenting class
\n \/\/ check the annotations on the implementing method not the asked method
\n <\/span>boolean <\/span>r = <\/span>false<\/span>;
\n <\/span>if<\/span>( <\/span>Modifier.isAbstract<\/span>(<\/span>method.getModifiers<\/span>() ) ) {
\n <\/span>\/\/ try to get the implementing method from the real instance
\n <\/span>try <\/span>{
\n <\/span>Method methodToCheck = clazz.getDeclaredMethod<\/span>(<\/span>method.getName<\/span>()<\/span>,method.getParameterTypes<\/span>())<\/span>;
\n <\/span>if<\/span>( <\/span>methodToCheck != <\/span>null <\/span>) {
\n <\/span>r = methodToCheck.isAnnotationPresent<\/span>(<\/span>annotationToCheck<\/span>)<\/span>;
\n <\/span>}
\n } <\/span>catch <\/span>(<\/span>SecurityException e<\/span>) {
\n } <\/span>catch <\/span>(<\/span>NoSuchMethodException e<\/span>) {
\n }
\n }
\n <\/span>return <\/span>r;
\n <\/span>}
\n<\/span>
\n}<\/p>\n<\/span>public <\/span>Class getAnnotationToCheck<\/span>() {
\n <\/span>return <\/span>annotationToCheck;
\n <\/span>}<\/p>\n<\/span>public <\/span>void <\/span>setAnnotationToCheck<\/span>(<\/span>Class<? <\/span>extends <\/span>Annotation> annotationToCheck<\/span>) {
\n <\/span>this<\/span>.annotationToCheck = annotationToCheck;
\n <\/span>}<\/p>\n}<\/span><\/tt>\n<\/p><\/blockquote>\n
Jetzt wird unterschieden, ob die Methode um die es geht, von der instanzieerten Klasse selbst stammt oder eben in einem Interface deklariert wurde. Wenn die Methode nicht von der Klasse selst stammt, dann wird die Annotation nicht auf der Methode gesucht, die dem Advisor \u00fcbergeben wurde, sondern auf der Methode, die die Interface-Methode implementiert. <\/p>\n
Auf diese Weise funktioniert die Annotation auf der Implementierungsklasse auch dann, wenn diese Klasse ein oder mehrere Interfaces implementiert. <\/p>\n
Ein vollst\u00e4ndiges Beispiel l\u00e4\u00dft sich hier<\/a> herunterladen. <\/p>\n","protected":false},"excerpt":{"rendered":"
Autoproxing mit Spring Das Applikation Framework Spring bringt ein sehr n\u00fctzliches Feature mit: Autoproxing. Damit lassen sich Spring Beans – also eigentlich jede POJO-Klasse – um Aspekte erweitern. Aspekte sind gem\u00e4ss AOP Belange eines Programms die sich quer zur eigentlichen … Weiterlesen