Beiträge für Juli, 2008

21Jul

Wenn man in Spring-Anwendungen zum Beispiel den Aufruf von Methoden loggen will, aber nicht in jeder gewünschten Methode eine Log-Anweisung einfügen möchte, kann man das Logging zentral als Aspekt definieren. Es können damit die Methodenaufrufe aller Klassen geloggt werden, die als Bean durch Spring verwaltet werden.

Zu Beginn sollte die Bean für den Interceptor (advice) definiert werden.

<bean id="methodLoggingInterceptor" class="MethodLoggingInterceptor"/>

Danach kann eine advisor verwendet werden, der auf den Interceptor (advice) verweist und die joinpoints (die gewüschten Methoden) über einen regulären Ausdruck engrenzt.

<bean id="wsMethodLogger" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
     <property name="advice">
          <ref local="methodLoggingInterceptor"/>
     </property>
     <property name="patterns">
          <list>
               <value>de.communardo.*get.*</value>
               <value>de.communardo.*process.*</value>
          </list>
     </property>
</bean>

Dann muss den betreffenden Beans der neue Interceptor hinzugefügt werden. Hierbei ist auf die Reihenfolge zu achten.

<bean id="profileWebservice">
    ...
    <property name="interceptorNames">
         <list>
              <value>serviceTransactionInterceptor</value>
              <value>hibernateInterceptor</value>
              <value>wsMethodLogger</value>
         </list>
    </property>
</bean>

Die Interceptor-Klasse kann zum Beispiel die Interfaces MethodBeforeAdvice, AfterReturningAdvice und ThrowsAdvice implementieren. In den entsprechenden Methoden kann dann je nach Aufrufzeitpunkt eine geeignete Meldung ins Log geschrieben werden.

import java.lang.reflect.Method;
import org.apache.log4j.Logger;
import org.springframework.aop.AfterReturningAdvice;
import org.springframework.aop.MethodBeforeAdvice;
import org.springframework.aop.ThrowsAdvice;

public class MethodLoggingInterceptor implements MethodBeforeAdvice, AfterReturningAdvice,
ThrowsAdvice {
    private Logger log = null;
    public MethodLoggingInterceptor() {
    }
    public void before(Method method, Object[] args, Object object) throws Throwable {
        log = Logger.getLogger(object.getClass());
        log.debug("Beginning method: " + method.getName());
    }
    public void afterReturning(Object returnValue, Method method, Object[] args, Object target)
    throws Throwable {
        log = Logger.getLogger(target.getClass());
        log.debug("Ending method: " + method.getName());
    }
    public void afterThrowing(Method method, Object[] args, Object target, Throwable ex) {
        log = Logger.getLogger(target.getClass());
        log.debug("Exception in method: " + method.getName() + " Exception is: " + ex.getMessage());
    }
}

Hinweis für AndroMDA-Nutzer: Für Klassen, die über den Stereotyp <<Service>> verfügen, existiert der tagged value @andromda.spring.service.interceptors. Darüber lassen sich den Services im Modell zusätzliche Interceptors hinzufügen, die in die Liste der interceptorNames aufgenommen werden. Die Spring-Konfiguration der beteiligten Beans kann anhand des applicationContext merge-point in den Application Context integriert werden.

Technorati Tags: , , , ,

14Jul

Auch die zweite Veranstaltung der Java User Group Saxony kann als voller Erfolg bezeichnet werden. Shaun Smith, Project Lead des EclipseLink Projektes und Produktmanager für Oracle TopLink, gab am 09.07.2008 einen Überblick über die Features und die Funktionsweise von EclipseLink.

Die Firma ubigrate hat diese Veranstaltung an der Informatik Fakultät der TU-Dresden in Zusammenarbeit mit dem JUG Saxony Team für die hiesige User Group organisiert und somit mehr als 50 Teilnehmern einen informativen und unterhaltsamen Abend ermöglicht.

Shaun Smith ging während seines Vortrages detailliert auf die Java Persistence API und die Referenzimplementierung EclipseLink ein. Dabei ist insbesondere die Vielseitigkeit des Frameworks hervorzuheben. Neben Objekt-Relationalem Mapping (ORM) stellt es Funktionen zum Objekt-XML Mapping (in Version 1.0 noch nicht 100% JAXB 2.0 kompatibel) sowie Unterstützung für Service Data Objects (SDO) 2.1 zur Verfügung. Sollte dies noch nicht genügen kann EclipseLink leicht um weitere Mapping Ziele erweitert werden wie Shaun Smith anhand eines JSON Beispiels demonstriert hat.

Neben der Vorstellung von technischen Details und der ein oder anderen Anekdote aus dem Projektgeschäft (wer sich dafür interessiert sollte die kommenden JUG Veranstaltungen nicht verpassen ;-) ) wurden auch die verschiedenen Mappings und das Zusammenspiel mit den Eclipse Dali JPA Tools im Rahmen von Live Demonstrationen vorgeführt.

Am Tag unserer Veranstaltung wurde EclipseLink 1.0 veröffentlicht und somit für den Produktiveinsatz freigegeben. Einen genaueren Blick ist es auf alle Fälle wert.

Das nächste Treffen der JUG Saxony ist für Oktober 2008 geplant. Das Thema lautet Rich Client Platform (RCP) Entwicklung mit Java.

Informationen zur kommenden Veranstaltung gibt es demnächst auf der Webseite der JUG Saxony unter http://www.jugsaxony.de. Die Folien zum EclipseLink Vortrag sind ebenfalls auf dieser Seite zu finden.

Einen Bericht zum Treffen in englischer Sprache gibt es im ubigrate Blog.

Technorati Tags: , , , , , ,