Archiv der Kategorie: Java

JBoss EJB 3.0 mit Eclipse RCP nutzen

English language version here

Als ich neulich das erste Mal aus einer Eclipse RCP heraus auf JBoss zugreifen wollte, bekam ich gleich die unschönen Seiten des OSGI-Classloading zu spüren. Meine Suche im Web nach einer Lösung förderte eigentlich nur die Fragen von anderen zu diesem Thema zu Tage. Daher nun hier mein Versuch, ein kleines Howto zu schreiben damit andere schneller zu einem funktionierendem Ergebnis kommen.

Das Ziel

Ziel soll sein, ein Eclipse Rich Client Project (ab jetzt nur noch RCP) zu erstellen, dass aus dem eigentlichen RCP-Plugin und einem Plugin mit den JBoss-Client-Bibliotheken besteht. Die EJB-Klassen werden wir in diesem Fall erstmal direkt in das RCP-Plugin integrieren, in einem späteren Beitrag werden sie dann, zwecks besserer Wartbarkeit, in ein eigenes Plugin ausgelagert. Die Anwendung soll dann ihre Daten als Session- und Entity-Beans vom JBoss beziehen.

Das Problem

Der OSGI-Classloader von Eclipse erzeugt für jedes geladene Plugin einen eigenen Classpath. Die Klassen von anderen Plugins sind dadurch unsichtbar. Dieses Vorgehen ist auch sinnvoll, denn es ermöglicht unter anderem das (de-) aktivieren von Plugins zur Laufzeit der Anwendung. Sofern ein Plugin (nennen wir es A) sich als Abhängig von einem anderen Plugin (B) erklärt (unter Dependencies im Plugin-Editor) werden die Klassen von B für A sichtbar.

In unserem Falle benötigen wir aber eine beidseitige Sichtbarkeit. Unser RCP muss die JBoss-Klassen sehen und JBoss muss die im RCP vorhandenen EJB-Klassen sehen können. Ist dies nicht gegeben hagelt es

javax.naming.CommunicationException [Root exception is java.lang.ClassNotFoundException: bz.jmc.blog.tutorial.rcp_with_jboss.ejb.MyTestStatelessSessionRemote (no security manager: RMI class loader disabled)]

und ähnliche Fehler.

Die Lösung

Da nicht beide Plugins sich gegenseitig unter Dependencies angeben können benötigen wir eine andere Lösung. Die heisst für uns „Buddy Classloading“. Hiermit wird es möglich, dass sich ein Plugin schon während der Implementierung für die Klassen von anderen Plugins „öffnet“. Andere Plugins können sich so als Buddy registrieren und Ihre Klassen dem anderen Plugin zur Verfügung stellen.

Auf den folgenden Seiten habe ich ein kleines, mit Screenshots versehenes Tutorial zusammengestellt, dass die Lösung anhand eines einfachen Beispiels erläutert.

Neues Buch von O’Reilly: Enterprise JavaBeans 3.0

Seit einiger Zeit versuche ich mir das Thema Java EE näher zu bringen. Bisher habe ich dazu 3 deutschsprachige Bücher gelesen, die sich alle aber noch mit J2EE 2.1 beschäftigt haben. Mit Version 2.1 ist das Thema aber doch sehr komplex sodass ich kurz davor war meine Bemühungen einzustellen.

Seit der JavaOne 2006 ist aber ja nun die neue Spezifikation 3.0 für Java EE final und vereinfacht das ganze Modell doch erheblich. Und O’Reilly hat gerade eines der ersten Bücher veröffentlicht die sich dediziert mit 3.0 beschäftigen.

Einen Nachteil, den das Büch für viele deutschsprachige hat, will ich vorweg nicht verschweigen: es ist z.Zt. noch ausschließlich in der englischen Originalversion erhältlich. Wer des Englischen aber einigermaßen mächtig ist wird mit dem Buch gut zurechtkommen.

„EJB 3.0“ ist sehr strukturiert aufgebaut. Nach 2 Kapiteln mit einer Einleitung und einem generellen Überblick über die Java EE Architektur werden in den folgenden 19 Kapiteln alle Aspekte von Java EE behandelt. Neben den grundlegenden Bean-Typen, die in aller Ausführlichkeit besprochen werden, widmet sich das Buch sehr intensiv der Java Persistence API. Anhand von vielen Beispielen werden alle Möglichkeiten der Objekt-Relationalen Abbildung erleutert.

Um dem Leser die Einordnung des gelernten in einen realen Kontext zu ermöglichen entwickeln die Autoren durch das gesamte Buch hindurch ein Buchungssystem für eine virtuelle Kreuzfahrtlinie namens „Titan Cruises“. Die Anwendung wird mit jedem Kapitel fortentwickelt. Themen wie Webservices und Security werden anhand von externen Reisebüros erklärt, die ebenfalls Zugriff auf das Buchungssystem benötigen.

Cover EJB 3.0Ein besonderes Schmankerl für alle an JBoss Interessierten ist der zweite Teil des Buches. Als Arbeitsbuch gehalten wird die konkrete Umsetzung der vorherigen Kapitel mit JBoss erläutert. Dies muß auch nicht wirklich verwundern, da der Autor Bill Burke „Chief Architect“ bei JBoss Inc. ist.

Das das Buch sehr aktuell ist (15.05.06), zeigte sich schon auf dem Klappentext. Dort wird schon erwähnt, das JBoss nun zu RedHat gehört.

Abschliessend kann ich mich dem ebenfalls auf dem Klappentext zitierten Marc Fleury (CEO JBoss) nur anschliessen: „If you work on Enterprise applications, this is the only EJB book you need“.

Enterprise JavaBeans 3.0
Bill Burke & Richard Monson-Haefel
O’Reilly, 5. Auflage
ISBN: 059600978X
733 Seiten

PHP auf dem Desktop?

Da lese ich eben (allesdrehtsichimkreis), dass es das Projekt PHP-GTK gibt. Ansich ja eine ganz nette Idee aber selbst als wirklich langjähriger (und durchaus begeisterter!) PHP-Nutzer kann ich den großen Nutzen nicht erkennen. PHP ist als Sprache sehr auf die Erstellung von Webseiten ausgerichtet. Und das klappt, wie ich aus eigener Erfahrung weiß, auch für größere Projekte ganz gut.

Aber das PHP nun deswegen Java verdrängen wird sehe ich nicht. Weder auf dem Desktop noch im Web. Beide Sprachen haben Ihre Vorteile und Ihre Daseinsberechtigung. Gerade Java hat einige unbestrittene Vorteile:

  • Die Typsicherheit macht das Entwickeln von sehr effizienten Entwicklungswerkzeugen möglich
  • Die Java-VM ist mittlerweile sehr schnell, laut JavaPosse bei einigen Aufgaben sogar deutlich schneller als C. Insbesondere durch die Hotspot-Technologie kann die VM noch während des Programmablaufs Optimierungen vornehmen.
  • In Java stehen mit mehrere GUI-APIs zur Verfügung (Swing, SWT, AWT)
  • Für Java gibt es, im Gegensatz zu PHP, Application Server. Diese können einem viele der Performace-Probleme, die teilweise bei PHP auftreten, abnehmen:
    • Durch das cachen der Datenstruktur werden nicht bei jedem Request x Datenbankabfragen durchgeführt (Wir oft habe ich ich mich schon geärgert, dass PHP-Skripte die Ergebnisse von teurer Rechenzeit nach dem Rendern einer Seite einfach an /dev/null schieben)
    • Da der App-Server dauerhaft läuft kann er auch Dinge erledigen, wenn gerade kein Request vorliegt.
    • Das Clustern von mehreren App-Server ist i.d.R. einfacher als bei PHP
    • etc
  • Aber das „Totschlag-Argument“ gegen PHP-GTK: PHP ist nicht Multithreading-fähig! Das heißt meine GUI wird nicht aktualisiert, solange das Programm noch etwas anderes zu tun hat. Sorry, aber das will heute kein Nutzer mehr akzeptieren. Man stelle sich nur vor, die Anwendung hat 5 Minuten lang etwas zu berechnen und während dieser Zeit ist sie unbenutzbar…

Aus diesen und anderen Gründen wird PHP-GTK kein Erfolg werden. Die Vorteile von PHP, insbesondere für kleine Webprojekte, bleiben aber unbenommen: einfach zu lernen, große Code-Basis und auf fast jedem Shared-Web-Server lauffähig.

So richtig freue ich mich aber schon auf die Fertigstellung von JSR-223 (Scripting for the JavaTM Platform). Dieses JSR beschreibt die Integration von Skriptsprachen in die Java EE Umgebung. Beispielhaft wird dort PHP implementiert. Dann kann man endlich auf JSPs oder Servlets verzichten und stattdessen PHP nehmen. Und dabei (fast) alle Vorteile von Java EE nutzen.