W-JAX am 12.11.

Auch am 12.11. durfte ich noch einen Tag an der W-JAX in München verbringen. Der Tag war recht angenehm, wenn auch einige des Sessions nicht das gehalten haben, was ich mir davon versprochen habe.

Session 1 : JSON in the real World

Die erste Session des Tages wurde bereits um 08:30 von Scott Davis (Groovy Veteran) gehalten mit dem Titel „JSON in the Real World“. Ich kannte zwar JSON, habe aber bisher nie damit gearbeitet und dachte mir deshalb, „in the Real World?“ – Kann nicht schaden. Scott ist ein begnadeter Speaker und es macht richtig Spass ihm zuzuhören (vor allem weil er gerne ab und an einige Jokes einbaut, die echt recht amüsant sind).

Zunächst mal JSON (Javascript Object Notation) ist nichts weiter, als eine Möglichkeit, Javascript Objekte sinnvoll als Objekt-Strukturen zu speichern (das ganze ist prinzipiell nicht mehr als eine Map). „Erfunden“ bzw. eingeführt wurde das ganze massgeblich von Douglan Crockford.

Aussehen tut das Ganze prinzipiell so:

var blogEntry = {
Blog: „Splitshade“,
Host: „WordPress“,
Topic: „Json“,
Location: „W-JAX“
}

var blogEntryArr = [blogEntry,blogEntry,blogEntry]

Scott hat in seinem Vortrag versucht, anhand eines konkreten Beispiels den Einsatz von JSON und dessen Vorteile gegenüber beispielsweise Javascript herauszuarbeiten. Scott hat den Webservice „Boss@yahoo“ verwendet, der es erlaubt, programmatisch die Suchfunktion anzusprechen und als Ergebnis u.a. auch JSON liefern kann.

Scott hat hierbei auch auf die XSS-Problematik hingewiesen, die sich durch die SOP (Single Origin Policy) von Javascript ergibt. Prinzpiiell heisst das, wir können von jedem beliebigen entfernten Server Javascript (und somit auch JSON) laden, aber eben nur einmal, mehrmals geht das nicht. Hier gibt es nun mehrere Möglichkeiten, wie man das Problem umgehen kann („Sign your Javascript“, Proxy auf unserem eigenen Server oder einen Hack (man gibt direkt eine lokale Javascript-Methode als Callback an, die als Ergebnis mit rausgerendert wird. Anhand von obigem Beispiel wäre das, wenn die CallbackMethode render() heissen würde folgender Rückgabewert: „render(blogEntryArr)“ statt nur „blogEntryArr“. D.h. die Funktion wird direkt aufgerufen, das wird beispielsweise auch bei GoogleMaps gemacht.

Zu guter Letzt hat Scott noch auf sein kommendes Buch hingewiesen (Getting Started with Grails , kostenlos!!).

Bean Validation

Im zweiten Vortrag ging es um das Thema „Bean Validation“ und den JSR 299. Gehalten wurde der Vortrag von Emmanuel Bernard (JBoss) und gleichzeitig Spec Lead für die Implementierung.

Die Referenzimplementierung für Bean Validation ist Hibernate Validator 4.03.

Prinzipiell gestatt die BeanValidation-API, ValidationConstraints als Annotations zu deklarieren und auf allen Schichten einer EnterpriseAnwendung einzusetzen, d.h. sowohl im Frontend, als auch im Middletier und sogar im Backend und der Datenbank können die Regeln geprüft werden und zwar normalerweise automatisch.

Die API definiert schon eine ganze Menge Constraints (@NotNull, @MaxLength etc.) und kann sehr einfach erweitert werden, indem beispielsweise CompositeConstraints aus den vorhandenen zusammengebaut werden. Zusätzlich bietet die API eine sehr weitreichende Integration in die JEE-Welt (beispielsweise die Integration in JSF 2.0 geht ad-hoc ohne eine Konfiguration). Emmanuel hat hier gezeigt, das die Constraints auf den ManagedBeans angegeben werden und automatisch beim Zugriff durch einen JSF-PropertyResolver ausgewertet werden. Coole Sache.

Weiterhin können die definierten Constraints automatisiert an ein Javascript-Frontend durchgereicht werden oder auch automatisiert in ein Datenbankschema gespielt werden. Find ich persönlich jetzt nicht sooo wichtig, aber das das so einfach geht ist schon erstaunlich. Nachteil ist auf jedenfall, das man die Anwendung der Regeln nicht so einfach auf eine Schicht begrenzen kann.

Insgesamt lohnt sich der Blick darauf wohl, ich werde mir das in nächster Zeit auf jedenfall mal reinziehen.

Keynote Cloud Computing

Puh, was soll ich dazu sagen, sehr theoretisch und langweilig, ich habe beinahe die ganze Note damit verbracht, eine kleine Ajax-Anwendung zu basteln, damit ich ein wenig mit JSON rumspielen konnte;-).

Keynote Scala

Interessanter Vortrag, in dem Martin Odelsky (Scala Mitbegründer) sich zu den nächsten 5 Jahren in Scala äusserte. Wenig technisch, aber durchaus interessant anzusehn. Ich persönlich habe bislang relativ wenig bis keine Erfahrung in Scala und ich persönlich find auch, das sich der Code nicht besondern einfach liest, aber evtl. kommt das ja mit der Zeit, ich habe mir auf jedenfall vorgenommen, hier durchaus mal einen Blick zu wagen.

OSGI Best practices

Vortrag von Martin Lippert und Matthias Lübken.  War recht amüsant, doch leider wenig technisch und ging nicht wirklich ins Detail, mich hätten einige Praxistipps noch interessiert.

Die Folien des Vortrags kann man sich hier anschauen.

GUI Security

In diesem Vortrag von Michael Wiesner ging es prinzipiell darum, wie Security schon in der GUI realisiert werden kann.
Diese Frage hat durchaus ihre Berechtigung (Beispiel war, das in heutiger Software eigentlich Security nur dadurch realisiert ist, das ein Button zwar vorhanden ist und angezeigt wird, aber erst beim Drücken wirkliche SecurityContsraints im Backend abgefangen werden).

Folgende Tipps hatte „Mike“ für uns:

1. Berechtigungskonzept am Client – hier sollte nicht mit Rollen sondern vielmehr mit Rechten gearbeitet werden
2. Die Constraints sollten direkt ins Domänenmodell mit Hilfe von AspectJ eingewoben werden

Insgesamt interessanter Vortrag, wenn auch die Ansätze für die PRaxis nicht besonders relevant sein dürften.

Das wars von mir von der W-JAX, mehr als zwei Tage „durfte“ ich leider nicht. Ich hoffe, alle Beteiligten hatten ebensoviel Spass wie ich.

 

W-JAX am Dienstag 10.11.

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.

W-JAX in München

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.

Exzellentes P2-Tutorial

Ein wirklich exzellentes Tutorials über P2 gibt hier.

VIelen Dank an Ralf Ebert für diesen Beitrag.

Toolbar in einer Form mit Commands bevölkern

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.

Maven local Repository

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;-)

Linux brauchbare Befehle

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.

Google Guice

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.

Glassfish V3 on OSGi

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.

Dependency auf lokale EJB

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>