Resumée W-JAX vom 10.11

Da dies mein erster Besuch auf der W-JAX war, war ich natürlich ordentlich gespannt, wie die einzelnen Sessions wohl ablaufen werden.

Eröffnet wurde der Tag mit einer Keynote von Ted Newark, der etwas provokative Titel „Why the next five years will be about languages“ liess schon einiges Versprechen.

Ich sage mal, ich habe selten einen so kompetenten Speaker wie Ted erlebt, mit Wortwitz und Eloquenz konnte er mich durchaus überzeugen.

Idee hinter der Keynote war hauptsächlich, herauszuarbeiten wieso das Thema Languages die letzten paar Jahre (Jahrzehnte?) nicht wirklich relevant für das tägliche Business war.

Die Essenz der Aussage von Ted hierauf war, das Sprachen typischerweise im akademischen Bereich entwickelt werden. Der Fokus einer akademischen Arbeit ist üblicherweise aber der, einer „akademisches“ Problem zu lösen. Ist dieses akademische Problem gelöst, verliert sich das Interesse an der Weiterentwicklung dieser Sprache in den meisten Fällen leider sehr schnell.

Versuchte man also früher, als Entwickler eine „neue“ Sprache zu verwenden, stiess man sehr schnell an die Problematik, dass die Funktionalität einer Sprache über diese spezifische Problemstellung hinaus dürftig, wenn überhaupt vorhanden war (humoristisches, leicht übertriebenes Beispiel von Ted war die Frage, wie greife ich in einer hypotetischen Sprache auf eine relationale Datenbank zu? Die Antwort hierauf, „Relational Databases? I never heard of this new Thing??“. Es herrscht wohl die Meinung vor, dass Sprachen üblicherweise von Professoren entwickelt werden, die mindestens ein Jahrzehnt nicht mehr draussen in Projekten waren;-).

Heute scheint es möglich zu sein, seine eigene „einfache“ Sprache innerhalb von einem Tag zu entwickeln, und zwar nicht von Akademikern, sondern vom Standardentwickler wie auch ich einer bin. Eingie Beispiele zu neuen Sprachen, die natürlich zur Sprache kamen waren Groovy, Ruby, Scala etc. Insgesamt stimmte die Keynote auf einen erfolgreichen Tag ein.

Die zweite Session die ich besucht habe war geleitet von … Hierbei ging es darum, die Neuigkeiten in JEE6 gegenüber JEE5 und sogar J2ee herauszuarbeiten. Der Vortragsstil des Referenten ist als durchaus „nüchtern“ zu beschreiben, da wünsche ich mir doch ein wenig mehr Enthusiasmus, nichts desto trotz war es für mich interessant, mal zu hören, was denn alles so zu kommen scheint. (Ich habe in meiner täglichen Arbeit eher weniger mit EJBs etc.. zu tun, deswegen muss ich leider eingestehen dass ich hier nicht mehr so ganz auf dem laufenden bin).

Der Referent berichtete aus seinem täglichen Projektgeschäft und speziell von einem Projekt zur Erstellung eines FTS ( Führerlosen Transportsystems auf Basis von EJB und Java, als Frontend kam ein Swing Client zum Einsatz).

Meiner Ansicht nach interessante Änderungen die mit EJB 3.1 komme sind:

1. @Singleton-Annotation : hierbei bietet die Spec die Möglichkeit, eine EJB wirklich nur einmal (pro JVM) zur Verfügung zu stellen. Könnte sich durchaus eigenen, um Applicationsettings einmalig global zu setzen. Hieraus ergeben sich natürlich recht interessante Multithreadingproblematiken, was ist zum Beispiel, wenn mehrere Clients gleichzeit auf die Singleton Instanz zugreifen? Hier bietet die Spec einigre interessante Annotations, mit denen das Locking geregelt werden kann (@Lock(READ oder WRITE) oder @AccessTimeout.
2. Endlich, standardisierte JNDI-Namen für EJBs , und zwar Herstellerunabhängig nach dem Pattern java:global/<app>/<module>/beanImpl:Interface, keine Ahnung wieso das nicht schon früher kam.
3. Timerservice (@Timeout, @Schedule etc., müsste man sich mal im Detail anschauen)
4. @Asynchronous, wir haben jetzt die Möglichkeit, eine Session-Bean-Methode asynchron auszuführen, d.h. Die Methode kehrt sofort zurück und liefert bei Bedarf ein Future (JDK 1.5), mit dem das Ergebnis abgefragt werden kann.
5. Die Möglichkeit, einen EJBContainer lokal programmatisch durchzustarten (für beispielsweise UnitTests : EJBContainer.createEJBContainer(), über diesen bekommt man beispielsweise einen Context, mit dem alle EJBs abgefragt werden können). Extrem cooles Feature!!
6. Man braucht keine Interfaces mehr (@LocalBean)

Container die EJB3.1 aktuell schon unterstützen sind Glassfish V3, Jboss 5.2 und OpenEJB.

Die dritte Session des Tages trug den verheissungsvollen Titel „EJB in the Large“. Die Referentin war direkt aus Brasilien eingeflogen, um aus Ihrer täglichen Arbeit zu berichten. Das Projekt das hier beschrieben wurde ist als durchaus eindrucksvoll zu bewerten. Es wurde beschrieben, wie ein „Health Care System“ für die Stadt „Sao Paolo“ in sage und schreibe 9 Monaten entwickelt wurde, und zwar auf Basis von EJB 2.1, Entity Beans, Xdoclet, Drools, Luntbuild und CrossDB. Das System konnte täglich ca. 1 Mio Anfragen bearbeiten, was zusammen mit der eingesetzten Technologie schon beinahe Sagenhaft ist.

Auch die Ansätze die die Referentin (gleichzeitig Projektleiterin) gewählt hat, waren sehr interessant. Insgesamt waren in dem Projekt ca. 70 Entwickler beschäftigt aufgeteilt in 3 Teams, teilweise EJB Experten, teilweise aber auch nicht. Am Ende bestand das Projekt aus 600!! EJB-Instanzen (für jeden Use-Case wurde eine eigene SessionFacade erstellt). Der Persistenzlayer wurde mit EntityBeans realisiert. (Aber nicht komplett, denn beispielsweise wurde aus Performancegründen komplett auf das Queriying mittels EntityBeans verzichtet. Dies wurde separat mit einem SQL-Framework CrossDB erstellt).

Der Vortrag an sich konnte leider wenig beeindrucken. Abgerundet wurde das Ganze von einem „Film“ gedreht von Sun, der ca. 10 Minuten dauerte. Ich habe derweil versucht, meine Eindrücke ordentlich zusammenzuschreiben;-).

Der Vortrag bestand eigentlich aus zwei Teilen. Im zweiten Teil sollte die Migration auf EJB 3 beschrieben werden, aufgrund des eher dürftigen ersten Teils habe ich mich aber entschlossen, den zweiten Teil auszulassen.

Als nächstes kam die Keynote von Adam Bien („The Future of Enterprise Java“). Gewohnt souverän versuchte hier Adam Bien die rosige Zukunft von Enterprise Java zu bestätigen, und das prognostizierte Aussterben von EJB zu widerlegen;-).

Das Fazit, dem ich mich persönlich durchaus anschliesse, EJB wird in nächster Zeit nicht aussterben! Good news!

Der nächste Workshop hatte den Titel „JPA under the Hood“ und wurde gehalten von Alois Reitbauer.

Kern des Workshops sollte es sein, herauszuarbeiten, wie sich verschiedene Persistenzframeworks für bestimmte Use-Cases verhalten (untersucht hat der Speaker Hibernate, EclipseLink und OpenJPA). Hierbei wurden u.a. die UseCases ObjectCache und QueryCache betrachtet.

Sehr interessant war für mich hier die vom Speaker eingesetzte Software. Die zentrale Frage hierbei war, kenne ich mein System wirklich, wenn ich nur die Interfaces kenne? (JPA? Hallo?).

Erste Frage: Das Query „select User u where u.id=1“

Essenz: Niemals feste Parameter in Queries kodieren, denn diese Queries können nicht im Querye-Cache landen und werden vom ORM-Framework immer und immer wieder ausgeführt.

Interessanterweise checkt sowohl OpenJPA als auch EclipseLink, dass es den Parameter hierzu ersetzen muss (gespeichert wird also die Query „select User u where u.id=?“.

Hibernate hingegen setzt tatsächlich die nicht parametrisierte Query ab.

Zweite Frage:

Was passiert, wenn der User geladen wird, eine Änderung in der Datenbank gemacht wird und dann diesselbe Query erneut abgesetzt wird?

Antwort: Die Änderungen aus der Datenbank werden nicht geladen, weil die Persistenzframeworks auf Objektidentität prüfen und bemerken, das der User mit der bestimmten ID bereits im Cache vorhanden ist. Durchaus überrsaschend, wenn auch logisch.

Dritte Frage:

Ist „getReference“ tatsächlich sinnvoll? GetReference() bietet die Möglichkeit, eine Referenz aus einer Klasse zu laden, ohne das die eigentliche Klasse wirklich geladen werden muss. (Beispielsweise kann man eine AdressEntity eines Users laden, ohne das der User komplett geladen werden muss).

Ergebnis: Ja, das funktioniert sowohl in Hibernate als auf OpenJPA. EclipseLink lädt leider standardmässig trotzdem alles aus der Datenbank, vorsichtshalber.

Vierte Frage:

Wieviele Connections werden erzeugt, wenn man in einem Loop ständig neue Sessions anfordert?

Antwort: Ohne Transaktionen, eine. Mit Transaktionen erzeugt Hibernate für jede angeforderte Session eine eigene Connection (autsch!).

Eergebnis: Es wäre schön, wenn alle Persistenzframeworks einen gemeinsamen Defaultstandard hätten. Ist aber nicht der Fall…

Im nächsten Workshop ging es um die Specs JSR-299, 330 und 340. Der Referent war Werner Keil, leider habe ich bisher keinen so schlechten Vortrag gehört, deswegen habe ich die gesamte Session versucht, mein Wlan ans Laufen zu bekommen;-).

Die Letzte Session war definitv das Highlight des Tages : Live on Stage Jave EE 6 Hacking mit Adam Bien.

Unter anderem wurden einige SessionBeans erstellt, Restful-Zugriff, JSF 2.0 Seiten, JPA Entities etc.. immer wieder ein Spass, Adam zuzuschauen.

Bin schon gespannt, was morgen kommt.

Heute und morgen bin ich glücklicher Inhaber einer Eintrittkarte für die W-JAX 2009 in München.
Es dürften zwei vielversprechende Tage werden, ich werde hier natürlich berichten.

Ein wirklich exzellentes Tutorials über P2 gibt hier.

VIelen Dank an Ralf Ebert für diesen Beitrag.

Wieder 2 Stunden meines Lebens verschwendet, weil ich eine einzige Zeile vergessen habe,

es ist zum ausrasten, damit mir das nicht nochmal passiert, soll das Ganze hier dokumentiert werden. Was wir machen möchten ist die Bevölkerung einer FormToolbar mit einem deklarativ beschriebenen Menu.

Das Ganze soll also über Commands funktionieren.

Hierfür definieren wir zunächst 2 Commands nebst irgendwelchen Handlern:

<command commandId=“playmp3″ icon=“icons/Button-Play-32×32.png“ label=“Play“ style=“push“>
<command commandId=“stopmp3″ icon=“icons/Button-Stop-32×32.png“ label=“Stop“ style=“push“/>

Dann definieren wir die Toolbar-Menucontribution, die in der FormToolbar angezeigt werden soll:

<menuContribution locationURI=“popup:myMp3ToolBar“>
<command commandId=“playmp3″ icon=“icons/Button-Play-32×32.png“ label=“Play“ style=“push“>
</command>
<command commandId=“stopmp3″ icon=“icons/Button-Stop-32×32.png“ label=“Stop“ style=“push“>
</command>

</menuContribution>

Um dieses deklarativ beschrieben Menu nun in einer FormToolbar anzuzeigen, braucht mal folgendes Codefragment:

…

ToolBarManager manager = (ToolBarManager) sForm.getToolBarManager();
toolkit.decorateFormHeading(sForm.getForm());
IMenuService menuService = (IMenuService)getSite().getService(IMenuService.class);
menuService.populateContributionManager(manager, „toolbar:myMp3Toolbar„);
manager.update(true);
Composite container = sForm.getBody();

Die in fetten Lettern  beschriebene ID ist die genau die ID die wie zuvor definiert haben in der plugin.xml.

Achtung, der Grund für diesen Blogeintrag, vergisst man die zweite fette Zeile, passiert nichts! keine Fehlermeldung kein gar nichts, einfach nichts! Manchmal hasse ich Eclipse.

Nur so als Tipp am Rande,

ein lokales Repository konfiguriert man entweder in der ~/.m2/conf/settings.xml oder in der $M2_HOME/conf/settings.xml.

Das GAnze schaut so aus:

<localRepository>G:/development/libs/maven_repo/</localRepository>

und nicht so:

<localRepository>G:/development/libs/maven_repo</localRepository>

Man beachte den / am Ende, der Spass hat mich einen ganzen Abend gekostet um den Build wieder zum Laufen zu kriegen. Zumindest sind jetzt alle Poms wieder aufgeräumt;-)

Man kann Befehle mit Hilfe eines ; aneinanderketten:

./startup.sh ; tail -f ~/log

tail -f ist ideal, um Logfiles zu prüfen, da hier jeder neue Eintrag einfach an das Ende der Ausgabe angehangen wird.

Ich habe mich heute mal mit Google Guice beschäftigt und das will ich hier mal kurz zusammenfassen.

Zunächst mal – Google Guice ist ein sehr leichtgewichtiges DI-Framework. Leichtgewichtig ist hier Programm.

Das Ganze ist sehr übersichtlich gestaltet und macht einen recht sympathischen Eindruck.

Ein erstes Beispiel hat man nach spätestens 5min am Laufen.

Wichtiges Infos hierzu gibt es hier

Wozu braucht man jetzt aber DI?

Die Antworten, die mir hier am wichtigsten sind sind decoupling und testability. Decoupling deswegen weil meine Anwendungsmodule (Implementierungen etc.. abhängig davon, wie die Anwendung aufgebaut ist) nicht mehr direkt voneinander abhängig sind, sondern die entsprechenden Implementierungen meiner Interfaces (IService…) von GUICE typischerweise via Constructorinjection injeziert bekommen. Genug der Theorie, direkt ein paar Codezeilen.. die Konfiguration von Guice erfolgt anders als beispielsweise in Spring nicht über externe XML-Dateien oder ähnliches sondern komplett in Java unter starker Verwendung von Annotations und Generics (sehr schön gelöst).

Eine typische Konfiguration könnte so aussehen:

public class GuiceModule implements Module {

@Override
public void configure(Binder bind) {
bind.bind(IService.class).annotatedWith(ServiceImpl2.class).to(ServiceImpl.class);
bind.bind(IService.class).to(de.md.client.impl.ServiceImpl2.class);
bind.bind(String.class).annotatedWith(Names.named(„test“)).toInstance(„MeinString“);
}

}

Das Ganze arbeitet also mit Fluent-Interfaces – sehr schön! – das Beispiel hier bindet die Implementierung ServiceImpl2 an das Interface „IService“. Wann immer in meiner Applikation also jetzt ein IService irgendwo verwendet wird, injeziert mir Guice hier ein ServiceImpl2.

Man hat auch die Möglichkeit, mehrere Implementierungen an ein Interface zu binden. Hierfür muss man als Entwickler eigene Annotations schreiben, damit Guice irgendwie mitgekommt, was wo gebraucht wird, eine einfache Annotation die für Guice vollkommen ausreichend ist, könnte so aussehen:

@Retention(RetentionPolicy.RUNTIME)
@BindingAnnotation
public @interface ServceImpl {

}

Die Annotation @BindingAnnotation kommt von Guice und zeigt an, das es sich hier tatsächlich um eine Annotation handelt, die für ein Binding definiert worden ist.

Die Verwendung ist denkbar einfach, denken wir uns einen einfache CLient aus, der folgenden Konstruktor hat.

@Inject
public Client(@ServiceImpl2 IService service, @ServceImpl IService service2) {
this.service = service;
this.service2 = service2;
}

Mit den Annotations @ServiceImpl2 und @ServiceImpl kann Guice mitgeteilt werden, welche Instanz denn jetzt wirklich injeziert werden soll – wieder sehr schön gelöst.

Weiterhin hat man die Möglichkeit, Namen zu vergeben, und Instanzen direkt an eine benannte Instanz zu injezieren.

@Inject @Named(„test“) private String s;

Schaut man sich das Module ganz oben nochmals an, sieht man, das Guice hier automatisch den String „MeinString“ injeziert. Sauber gemacht.

Auf einen ersten Blick wirkt Guice auf mich sehr sympatisch, ich werde auf jedenfall noch den einen oder anderen Blick da rein werfen, besonders intersesiert mich die Möglichkeit, Guice in Verbindung mit OSGi zu verwenden.

Zu Beginn einige Glassfish-Facts, die nicht jeder kennt (zumindest ich nicht;))

Glassfish kommt mit einer Embedded-Datenbank (JavaDB) – kann gestartet werden mit

glassfish/bin/asadmin start-database

Hochinteressant, mittlerweile dürfte wohl jeder mitbekommen haben, das Glassfish in der V3 auf einem OSGi-Container (Felix) aufbaut.

Mir war bisher zwar klar, das sich hierdurch für Glassfish einige Vorteile ergeben (Management, Dynamik), aber ich hatte keine Ahnung, inwiefern das für mich als Entwickler interessant sein kann.

Zunächst mal hier einige Infos die hier weiterhelfen:

Die OSGi-Konsole bietet einen Remote-Schnittstelle an, wenn der Glassfish gestartet wurde, kann mit „telnet localhost 6666″ eine Verbindung zur Konsole aufgebaut werden

Das allein ist zwar definitiv interessant, reicht aber nicht.

Ein Entwickler von Glassfish betreibt hierzu einen wirklich hochinteressanten Blog, in welchem beispielsweise ein Eintrag vorhanden ist, der sich damit beschäftigt, ein OSGi-Bundle als WAR File zu deployen. Denkt man sichjetzt noch die Möglichkeit, OSGi-Services zu verwenden um Funktionalitäten Horizontal zwischen Applikationen anzubieten, dann tun sich hier schöne neue Welten auf.

Die Blogeinträge hierzu findet man hier:

http://weblogs.java.net/blog/ss141213/archive/2009/06/osgi_enabled_we.html

http://weblogs.java.net/blog/ss141213/archive/2009/06/developing_hybr.html

http://weblogs.java.net/blog/ss141213/archive/2009/05/using_felix_web.html

Ein Blick lohnt sich auf jedenfall, wenn jemand hier bereits interessante Erfahrungen gemacht hat würde ich mich über Kommentare freuen.

Da scheinbar die Standard-Maven-Repositories keine API für EJB3 unterstützen, kann man die lokalen Jars aus seiner Appserverinstallation so verwenden:

<dependencies>
<dependency>
<groupId>glassfish</groupId>
<artifactId>javax.ejb</artifactId>
<version>LATEST</version>
<scope>system</scope>
<systemPath>${glassfish.home}/modules/javax.ejb.jar</systemPath>
</dependency>
<dependency>
<groupId>org.apache.openejb</groupId>
<artifactId>api</artifactId>
<version>3.1.1</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
</dependencies>

Natürlich muss hierfür zusätzlich die Property glassfish.home deklariert werden.

Um EJB3 verwenden zu können, muss dies Maven noch so mitgeteilt werden:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-ejb-plugin</artifactId>
            <configuration>
                <ejbVersion>3.0</ejbVersion>
            </configuration>
        </plugin>
    </plugins>
</build>
Zusätzlich sollten die Compiler Settings auf 1.5 geeicht werden:
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-compiler-plugin</artifactId>
 <version>2.0.2</version>
 <configuration>
 <source>1.5</source>
 <target>1.5</target>
 </configuration>
 </plugin>

Um einen Client zu generieren, einfach folgenden Parameter für das Maven EJB Plugin setzen.
 <configuration>
          <!-- this is false by default -->
          <generateClient>true</generateClient>
        </configuration>

Nützlicher Tipp:

Um das Logging für die OSGi DS zu aktivieren einfach folgende beiden Properties als System-Properties setzen (vmargs):

-Dequinox.ds.debug=true

-Dequinox.ds.print=true (Log-Infos auch auf der Konsole, ansonsten werden diese nur auf den OSGi-Logservice ausgegeben)