Den Anfang machte Ralf Ebert (Freelancer) mit seinem Vortrag zur EclipseRCP. Ihm folgte Stefan Saring (Saxonia Systems AG) mit der Vorstellung des Swing Application Frameworks (JSR 296). Beschlossen wurde der Abend durch Geertjan Wielenga (NetBeans/SUN) mit NetbeansRCP. Nach drei Stunden voller Informationen und praktischer Vorführungen lautete das Fazit: Alle drei Frameworks haben ihre Daseinsberechtigung. Entwickler mit SWT Background greifen zu EclipseRCP, Swing Fans je nach benötigtem Funktionsumfang und Projektgröße zum Swing Application Framework (kleinere bis mittlere Projekte) oder zu NetBeans RCP (mittlere und größere Projekte).

Wir hoffen am 27.11.2008 mit der vierten Veranstaltung  der JUG Saxony – diesmal zum Thema Rational Jazz/Team Concert - erneut allen Besuchern ein ansprechendes Programm zu bieten.

Auch für das Jahr 2009 sind bereits fünf Vorträge in Vorbereitung.

Leider waren damit der erste Konferenztag und unser Besuch der Berlin.jar schon vorbei. Am Tag zwei haben wir u.a. die Vorträge der ubigrate GmbH (Drahtwanderung: WIIr machen den NäXTen Schritt) und der buschmais GbR (Integrationsmuster am Beispiel von Apache Camel, Paradigmenhochzeit: Felix und ServiceMix in trauter Zweisamkeit vereint, Modellierung statischer Domänenmodelle mit Xtext) verpasst, aber vielleicht gibt es ja schon bald ein Wiedersehen bei der JUG Saxony

Dieses wird es auf alle Fälle im kommenden Jahr bei der zweiten Ausgabe der Berlin.jar geben.

Die Tücken der Technik

In meinem letzten Projekt zeigte sich jedoch ein interessantes Phänomen: Ich erstellte eine Klasse mit Annotation und einer Autoincrement-Sequence zum Hochzählen der Id.

@Entity
@SequenceGenerator(name = "user_seq", sequenceName = "user_id_seq")
public class User implements Serializable { ... }

Zunächst schien alles zu funktionieren, als ich aber einige Zeit später in die Datenbank schaute entdeckte ich seltsame Sprünge zwischen den Ids:

Nach einigem Probieren stellte ich fest, dass die Sprünge stets nach dem Neustart der Anwendung auftraten. Das Problem konnte ich schließlich nach etwas Recherche im Internet ausmachen. Für den SequenceGenerator existiert ein Parameter allocationSize, welcher die definierte Sequenz um den angegeben Wert erhöht und anschließend diese Nummern vergibt. Erst wenn alle verbraucht sind, wird die Sequenz erneut aufgerufen. Der Nachteil dieser performanten Vorgehensweise ist, dass bei einem Neustart der Anwendung die zwischengspeicherten Werte verloren gehen und dadurch Lücken zwischen den Id’s entstehen. Standardmäßig ist diese Einstellung auf 50 gesetzt, was auch den Abstand in der Datenbank erklärt. Die nachfolgende Einstellung schafft also Abhilfe:

@Entity
@SequenceGenerator(name = "user_seq", sequenceName = "user_id_seq" allocationSize=1)
public class User implements Serializable { ... }

Nun wird zur Generierung des nächsten Primary-Keys immer die Datenbanksequenz bemüht, was die Performance zwar etwas mindert, jedoch bleiben die Lücken aus.

Links: http://www.galileocomputing.de/artikel/gp/artikelID-328

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.

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.

Vorbereitungen

Um das eigene Projekt fit für den Groovy-Code zu machen, muss zunächst einmal die groovy-all-1.5.4.jar in den Build-Path aufgenommen werden. In der Regel findet sich diese Library im Verzeichnis der Groovy-Installation im Ordner \embeddable. Verwendet man Eclipse, so funktioniert das in etwa so ‘Project > Properties > Java Build Path > Libraries > Add External JARs…‘, wobei man es vorziehen sollte die Bibliothek in ein eigenes Projektverzeichnis zu kopieren (/lib) und von dort aus zu verlinken.

Theoretisch könnte es jetzt auch schon losgehen, aber ich denke die Wenigsten wollen beim Programmieren auf lieb gewonnene Features wie z.B Syntax Highlighting verzichten. Es gibt für die gängigsten IDE’s bereits Groovy-Plugins und ein paar Links dazu finden sich am Ende des Beitrages, wer mit Eclipse arbeitet kann mal einen Blick hierauf werfen. Die Plugins an sich sind zwar noch nicht 100% ausgereift und Autocompletion vermisst man stellenweise auch, aber hey - ich habe vor kurzem mit dem vi programmiert, auch das ging

Der erste Kontakt

Um einen schnellen Einstieg zu bekommen, soll ein kleines Beispielprojekt in Form eines Autohandels den Integrationsprozess veranschaulichen. Nachfolgend findet sich ein Listing zweier Interfaces die als Schnittstelle zur Groovy-Welt dienen.

package de.j2g.interfaces;

public interface ICar {
    public String getMake();
    public String getModel();
    public String getType();
    public double getPrice();
}

package de.j2g.interfaces;

import java.util.ArrayList;

public interface IGarage {
    public ArrayList<ICar> getCars();
}

Nachdem die Struktur steht, geht es an die Implementierung der Groovy-Klassen. In einem separaten Package wird die Klasse Car.groovy erzeugt, welche das Interface ICar implementiert:

package de.j2g.groovy

import de.j2g.interfaces.ICar;

class Car implements ICar {
    String make
    String model
    String type
    double price
}

Nein, hier wurde nicht vergessen die Methoden des Interfaces hinzuschreiben. Da Groovy die Getter- und Setter-Methoden zur bei Kompilierung selbst hinzufügt, müssen lediglich die Instanzvariablen definiert werden. Als Nächstes kommt die Implementierung der Garage.groovy:

package de.j2g.groovy

import de.j2g.interfaces.IGarage;
import de.j2g.interfaces.ICar;
import java.util.ArrayList;

class Garage implements IGarage {
    public ArrayList<ICar> getCars() {

    def cars = new ArrayList<ICar>()

    def car1 = new Car()
    car1.make = “Ford”
    car1.model = “SHELBY GT500″
    car1.type = “Sports Car”
    car1.price = 89000.00

    def car2 = new Car()
    car2.make = “Ford”
    car2.model = “Taurus”
    car2.type = “Full-Size”
    car2.price = 21000.00

    cars.add(car1)
    cars.add(car2)

    return cars
    }
}

Der Groovy-Teil steht, jetzt fehlt noch der Aufruf aus der Java-Welt. In der Main-Klasse werden als erstes die benötigten Groovy-Klassen über den mitgelieferten GroovyClassLoader geladen. Da nur die Methode getCars() der Garage.groovy angesprochen wird, muss auch nur diese Klasse explizit geladen werden. Alle abhängigen Klassen, in diesem Fall nur die Car.groovy, werden automatisch mitkompiliert und geladen. Ist die Klasse geladen, erzeugt man davon eine neue Instanz und castet diese auf das zuvor angelegte Interface IGarage.

package de.j2g.main;

import groovy.lang.GroovyClassLoader;
import groovy.lang.GroovyObject;

import java.util.ArrayList;

import org.codehaus.groovy.control.CompilationFailedException;

import de.j2g.interfaces.ICar;
import de.j2g.interfaces.IGarage;

public class CarDealer {

    public static void main(String[] args) {
        System.out.print(”Loading groovy classes… “);
        ClassLoader parent = CarDealer.class.getClassLoader();
        GroovyClassLoader loader = new GroovyClassLoader(parent);

        Class gGarage = null;

        try {
            gGarage = loader.loadClass(”de.j2g.groovy.Garage”);
        } catch (CompilationFailedException e) {
            …
        } catch (ClassNotFoundException e) {
            …
        }

        GroovyObject goGarage = null;
        try {
            goGarage = (GroovyObject) gGarage.newInstance();
        } catch (Exception e) {
            …
        }

        System.out.println(” done!”);

        IGarage garage = (IGarage) goGarage;
        ArrayList<ICar> cars = garage.getCars();

        for (ICar car : cars) {
            System.out.print(”\n” + car.getMake() + ” “);
            System.out.println(car.getModel());
            System.out.println(car.getPrice() + ” €”);
            System.out.println(car.getType());
        }
    }
}

Das Ausführen der Main-Class sollte folgende Ausgabe auf die Konsole bringen:

    Loading groovy classes... done!     

    Ford SHELBY GT500
    89000.0 €
    Sports Car    

    Ford Taurus
    21000.0 €
    Full-Size

The Power of Groovy

Die Funktionen im oberen Beispiel hätte man sicher auch ebenso schnell in Java umsetzen können. Etwas Programmieraufwand konnte aber schon bei der Car.groovy gespart werden - es war nicht nötig die Getter- und Setter zu definieren. Um nun die Effizienz der Skriptsprache noch etwas deutlicher zu machen, wird im Folgenden die Klasse Garage.groovy um einen FileReader erweitert:

cars.txt

    Toyota;Camry;34000;Full-Size
    VW;Golf;25000;Economy

Garage.groovy

public ArrayList<ICar> getCars() {
    def cars = new ArrayList<ICar>()
    def carFile = new File(’D:/cars.txt’)

    carFile.eachLine {
        line ->
            def carArray = line.split(’;')
            def car = new Car()
            car.make = carArray[0]
            car.model = carArray[1]
            car.price = Integer.parseInt(carArray[2])
            car.type = carArray[3]
            cars.add(car)
    }
    return cars;
}

Fazit

Einfacher geht es kaum noch, wenig Code zur Funktionsimplementierung und optionales Exception-Handling machen Groovy zum idealen Begleiter für die Agile Entwicklung!

Groovy IDE Plugins: Eclipse IntelliJ JEdit Netbeans

Caused by: org.postgresql.util.PSQLException: ERROR: operator does not exist: bigint ~~ bigint
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1512)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1297)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:437)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:353)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:257)
at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:92)
... 2 more

Zunächst vermutete ich ein JDBC Treiber-Problem, jedoch konnte der Fehler nach etwas Recherche und Debugging auf das Object-Mapping eingegrenzt werden. Das Kernproblem ließ sich dann letzendlich seitens der Datenbank bzw. deren Ansprache durch das Grails ORM identifizieren - ich hatte versehentlich eine falsche Version der PostgreSQL Datenbank installiert. Da Grails Hibernate als Persistenz-Framework verwendet (GORM) und  dieses nur Postgres bis zur Version 8.1 unterstützt,  quittierte meine Application die meisten Datenbankoperationen mit obiger Meldung.

Links: Von Hibernate unterstützte Datenbanken

Vor 43 interessierten Teilnehmern wurde die Model Driven Architecture (MDA) vorgestellt. Herr Professor Aßmann (Lehrstuhl Softwaretechnik der TU Dresden) gab eine konzeptionelle Einleitung zum Thema und betrachtete dabei insbesondere den Zusammenhang zwischen MDA und Component-based Software Engineering (CBSE) (Folien). Herr Torsten Lunze (Communardo Software GmbH) stellte mit seinem Vortrag (Folien) den Bezug zur Praxis anhand eines Beispiels aus dem Projektgeschäft her und erläuterte u.a. die Vor- und Nachteile von MDA beim Einsatz der Open Source Software AndroMDA. Beim anschließenden Buffet blieb Zeit Kontakte zu knüpfen und das Thema im Gespräch zu vertiefen.
Mindestens einmal pro Quartal wird nun eine Veranstaltung der JUG Saxony stattfinden. Das nächste Treffen ist am 9. Juli 2008 in den Räumen der TU Dresden geplant. Das Thema wird voraussichtlich EclipseLink (JPA 2.0 RI, JSR 317) sein.
Gern können Sie sich als Mitglied der JUG Saxony auf unserer Website http://www.jugsaxony.de registrieren. Für Anregungen und Wünsche sind wir stets offen.

Die allgegenwärtige Session

In allen Controllern ist die Session bereits standardmäßig im Application-Scope und wartet gebrauchsfertig mit dem Namen “session” auf Verwendung. Das Objekt implementiert im wesentlichen die Standardfunktionalität der javax.servlet.HttpSession und hält ergänzend die Zugriffsmöglichkeiten einer GroovyMap bereit.

session.username = ‘John Doe’

println session["username"] oder
println session.username

Das Objekt selbst wird im Hintergrund über request.getSession() initialisiert, daher hat man auch nach einem session.invalidate() bzw. einem Timeout beim nächsten Actionaufruf (Achtung: Nicht im selben Controller!) eine neue Session. Am Beispiel einer Nutzer-Authentifizierung soll der Zugriff verdeutlich werden:

//Im Interceptor ist die Authentifizierung definiert, die vor jeder Action ausgeführt werden soll
def beforeInterceptor = [action:this.&auth,except:'login']

//Falls kein Nutzer in der Session gefunden wird, erfolgt eine Weiterleitung zur Login-Action
def auth() {
  if(!session.user) {
    redirect(action:’login’)
    return false
  }
}
def login = {
    // zeige Login-Seite
}

Session Timeouts

Wie oben bereits angesprochen, muss man sich kein neues Session Objekt nach einem Timeout besorgen. Leider hat dieser Mechanismus aber den Nachteil, dass man dadurch nicht merkt ob eine neue Session durch den Timeout einer Vorhergehenden erzeugt wurde und Rückschlüsse darauf lassen nur eine neue ID und die fehlenden Session-Attribute zu.

Braucht ein Nutzer z.B. zu lange um eine Formular auszufüllen, bekommt er beim nächsten Klick den Zugriff verweigert oder der aktuelle Bearbeitungssatus wird zurückgesetzt. Sicher ist dies in den meisten Fällen eines Session-Timeouts der Fall, aber hier ist der unberechtigte Zugriff mit dem Timeout gleichgesetzt und der Nutzer kann schlecht explizit auf eine abgelaufene Session hingewiesen werden.

Eine Möglichkeit herauszufinden ob die aktuelle Session noch existiert und eine entsprechende Meldung auszugeben, wäre einen Parameter zu setzen und diesen vor einer Action abzufragen:

static beforeInterceptor = [action:this&checkSession, except:'login']

def checkSession = {
  if(!session.timeout)
  render(”Session Timeout!”)
}

AfterInterceptor Verwendung

Die Möglichkeiten eines Interceptors sind vielfältig, sollten aber gerade bei Ausführung nach Methodenaufrufen mit bedacht eingesetzt werden.

Beispiel: Man definiert in einer Basisklasse den Zugriff auf die Session per AfterInterceptor (z.B. für einen Logger) und leitet diese dann in einem Controller ab. In einer neuen Action wird nun die Session ungültig gemacht und als Ergebnis löst der Aufruf der Session-Variable im Interceptor automatisch eine IllegalStateException aus.

Dieser Aufruf kann auch schon die blosse Ausgabe der Session sein, da das Objekt im Controller nicht mehr exisiert. Im nachfolgenden Codeauszug wird der eben beschriebene Fall veranschaulicht:

class BasisController {
  def afterInterceptor = {       
    //wirft eine IllegalStateException
    println session
  }
  …
}

class UserInterface extends BasisController {
//Erzeugt nach dem render eine IllegalStateException
  def logout = {
     session.invalidate()
     render(view:’logout’)
  }
}

Ein Workaround wäre, im Interceptor nicht die Session-Variable des Controller zu nutzen. Stattdessen sollte man die Session direkt aus dem Request holen:

class BasisController {
  def afterInterceptor = {        
    //gibt die Session aus oder null, wenn diese ungültig wurde
    println request.getSession(false)
  }
  …
}

Zugriffe ohne Session

Ein großer Nachteil der automatischen Sessionvergabe war bislang auch die Tatsache, dass bei einzelnen Controlleraufrufen (z.B. durch einen externen Service), ebenfalls eine Session erzeugt wurde, obwohl diese gar nicht benötigt wurde. So hatte man bei einem Aufruf durch einen Webservice nach jedem Request immer eine Session, welche unbenutzt auf den Timeout wartete.

Seit Grails 1.0.1 wird nur nach der expliziten Nutzung des Session Objektes im Controller eine neue Session angelegt. Siehe dazu http://jira.codehaus.org/browse/GRAILS-1238.