{"id":2,"date":"2006-08-01T18:36:17","date_gmt":"2006-08-01T17:36:17","guid":{"rendered":"http:\/\/euve3303.vserver.de\/stefan\/blog\/?p=5"},"modified":"2011-12-02T20:36:12","modified_gmt":"2011-12-02T19:36:12","slug":"springs-aop-proxies","status":"publish","type":"post","link":"https:\/\/cogito-ergo-blog.de\/blog\/2006\/08\/01\/springs-aop-proxies\/","title":{"rendered":"Spring’s AOP Proxies"},"content":{"rendered":"

Wenn Spring’s AOP Framework Proxies erzeugt um eigene Klassen mit zus\u00e4tzlichen Features zu versehen, kann das mitunter seltsame Effekte haben. Beispielsweise w\u00fcrde man doch vermuten, dass eine SpringBean die auf folgende Weise definiert ist:<\/p>\n

<\/p>\n\n\n\n
\n
<bean name="testBean" class="com.rinke.solutions.spring.test.SpringTestImpl" \/><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
sich in einer Applikation immer in etwa in der Art verwenden l\u00e4\u00dft: <\/p>\n
<\/p>\n
\n
package <\/span>com.rinke.solutions.spring.test;<\/p>\n
<\/span>import <\/span>org.springframework.context.ApplicationContext;
\n<\/span>import <\/span>org.springframework.context.support.ClassPathXmlApplicationContext;<\/p>\n
<\/span>public class <\/span>TestSpring <\/span>{<\/p>\n
    <\/span>\/**
\n     * <\/span>@param <\/span>args
\n     *\/
\n    <\/span>public static <\/span>void <\/span>main<\/span>(<\/span>String<\/span>[] <\/span>args<\/span>) {
\n        <\/span>ApplicationContext ctx = <\/span>new <\/span>ClassPathXmlApplicationContext<\/span>(
\n                <\/span>new <\/span>String<\/span>[] {<\/span>"applicationContext.xml" <\/span>})<\/span>;
\n        
\n        SpringTestImpl myBean = <\/span>(<\/span>SpringTestImpl<\/span>) <\/span>ctx.getBean<\/span>(<\/span>"testBean"<\/span>)<\/span>;
\n        <\/span>\/\/ ... do something
\n    <\/span>}<\/p>\n
}<\/span><\/tt><\/p>\n<\/blockquote>\n
Weit gefehlt! <\/p>\n
<\/p>\n
Je nach dem, ob die Klasse ein Interface implementiert oder nicht, funktioniert der Cast auf "SpringTestImpl" nicht mehr, sondern liefert eine ClassCastException. <\/p>\n
Dieses Verhalten r\u00fchrt daher, dass Spring beim Erzeugen von Proxies auf zwei unterschiedliche Mechanismen zur\u00fcckgreift: <\/p>\n
    \n
  1. Die dynamischen Proxies aus dem JDK (seit Version 1.4) <\/li>\n
  2. Auf dynamisch erzeugte Subclasses deren Bytecode zur Laufzeit mit der CGLib generiert wird. <\/li>\n<\/ol>\n
    Das erste Verfahren ist das per Default bevorzugte, funktioniert aber nur, wenn die in Frage stehende Klasse wenigstens ein Interface implementiert. Wieso kommt es nun zu der ClassCastException? Ganz einfach, der erzeugte Proxy ist ein Proxy eines Interfaces, welches die Klasse implemeniert und dieser ist vom Typ her nicht auf die Implementierungsklasse "herunter castbar". Obwohl man also weiss, dass eine ganz bestimmte Implementierung hinter einer Bean steckt, kann sie auf diesen Typ nicht gecastet werden. <\/p>\n
    Jetzt mag man einwenden, dass es sowieso besserer Stil ist ein Interface zu definieren gegen das man programmiert. Aber die Alttag l\u00e4\u00dft einen oft genug diesen Schritt \u00fcberspringen, wenn weiter kein Nutzen davon entsteht, weil dieses Interface keine zus\u00e4tzlich Abstraktion bringt. Der Fehler kommt dann "durch die Hintert\u00fcr", wenn die Implementierungsklasse aus anderen Gr\u00fcnden ein Interfaces implementieren muss (z.B. "Serializable"). Pl\u00f6tzlich entstehen so Exceptions, die da vorher nicht zu sehen waren. <\/p>\n
    Ausweg? <\/h2>\n
    Schaut man einigermassen tief in die Spring Dokumentation, so findet sich eine Konfigurationseinstellung, die bewirkt, das das Erzeugen der Proxies immer<\/i> mit Hilfe der CGLib gemacht wird. Das bewirkt als Nebeneffekt, dass der Cast aus dem Beispiel oben wieder funktioniert, denn nun ist der erzeugte Proxy eine echte Subklasse von SpringTestImpl und damit auch "castbar". <\/p>\n
    Die vollst\u00e4ndige BeanFactory Konfiguration sieht dann z.B. so aus: <\/p>\n\n\n\n
    \n
    <?xml version="1.0" encoding="UTF-8"?><\/font><\/code>
    <!DOCTYPE beans PUBLIC "-\/\/SPRING\/\/DTD BEAN\/\/EN" "http:\/\/www.springframework.org\/dtd\/spring-beans.dtd">\r\n\r\n<\/font><<\/font>beans<\/font>>\r\n\r\n<\/font>     <\/font><<\/font>bean <\/font>class<\/font>="<\/font>org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator<\/font>"><\/font><\/code>
              <\/font><<\/font>property <\/font>name<\/font>="<\/font>proxyTargetClass<\/font>" <\/font>value<\/font>="<\/font>true<\/font>"\/><\/font><\/code>
         <\/font><\/<\/font>bean<\/font>>\r\n\r\n<\/font>     <\/font><<\/font>bean <\/font>class<\/font>="<\/font>com.rinke.solutions.spring.test.aop.AnnotationSourceAdvisor<\/font>"><\/font><\/code>
              <\/font><<\/font>property <\/font>name<\/font>="<\/font>annotationToCheck<\/font>" <\/font>value<\/font>="<\/font>com.rinke.solutions.spring.test.Writing<\/font>"\/><\/font><\/code>
              <\/font><<\/font>property <\/font>name<\/font>="<\/font>advice<\/font>" <\/font>ref<\/font>="<\/font>writeableCheckInterceptor<\/font>"\/><\/font><\/code>
         <\/font><\/<\/font>bean<\/font>>\r\n\r\n<\/font>     <\/font><<\/font>bean <\/font>id<\/font>="<\/font>writeableCheckInterceptor<\/font>" <\/font>class<\/font>="<\/font>com.rinke.solutions.spring.test.aop.WriteableCheckInterceptor<\/font>"><\/font><\/code>
              <\/font><<\/font>property <\/font>name<\/font>="<\/font>readOnly<\/font>" <\/font>value<\/font>="<\/font>true<\/font>"\/><\/font><\/code>
              <\/font><<\/font>property <\/font>name<\/font>="<\/font>exceptionToThrow<\/font>" <\/font>value<\/font>="<\/font>com.rinke.solutions.spring.test.ReadOnlyException<\/font>"\/><\/font><\/code>
         <\/font><\/<\/font>bean<\/font>>\r\n\r\n<\/font>     <\/font><<\/font>bean <\/font>name<\/font>="<\/font>testBean<\/font>" <\/font>class<\/font>="<\/font>com.rinke.solutions.spring.test.SpringTestImpl<\/font>" \/>\r\n\r\n<\/<\/font>beans<\/font>><\/font>\r\n<\/code><\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
    Der entscheidende Konfiguration Schalter ist hier <property name="proxyTargetClass" value="true"\/><\/font> womit eben immer auf CGLib zur\u00fcckgegriffen wird. <\/p>\n","protected":false},"excerpt":{"rendered":"
    Wenn Spring’s AOP Framework Proxies erzeugt um eigene Klassen mit zus\u00e4tzlichen Features zu versehen, kann das mitunter seltsame Effekte haben. Beispielsweise w\u00fcrde man doch vermuten, dass eine SpringBean die auf folgende Weise definiert ist: <bean name="testBean" class="com.rinke.solutions.spring.test.SpringTestImpl" \/> sich in … Weiterlesen →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"_links":{"self":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/2"}],"collection":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/comments?post=2"}],"version-history":[{"count":1,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/2\/revisions"}],"predecessor-version":[{"id":10014,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/posts\/2\/revisions\/10014"}],"wp:attachment":[{"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/media?parent=2"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/categories?post=2"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cogito-ergo-blog.de\/blog\/wp-json\/wp\/v2\/tags?post=2"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}