From Zero to Hero? Seam Forge. Deutschland 8,50. Wann auf welche Weise verfeinern? 104. Komplettsysteme sind kein Muss. Project Caffeine » 78.

Transkript

1 ikl. Java Magazi JAVA Mag CD From Zero to Hero? Seam Forge Deutschlad 8,50 JBoss AS BI-Reportig als Ope Source Project Caffeie Buildig NextGeeratio Web Apps with WebSockets ad HTML5 Video vo der JAX 2011 CouchDB HIGHLIGHT User Stories JBoss AS 7 fial Secha Touch jcouchdb Seam Forge Alle CD-Ifos ab Seite magazi User Stories Build your ow Story Wa auf welche Weise verfeier? 104 Bessere Präsetatioe für Etwickler ud Architekte 55»» Bradeues Programm» 51 7 S A s s o JB» 7 S A : g ti h g i L e h t Ride»40 7 h c a r5 e b ü 4 o :V o i t a r g i M»33 u a b f u Cluster-A 16 WEITERE INHALTE JAX-WS RI Metawidget 1.25 Sveso BI-Reportig als Ope Source Komplettsysteme sid kei Muss Project Caffeie ABAP to Go» 78 CouchDB 2011 Acceture. All rights reserved. Österreich 9,80 Schweiz sfr 16,80 Java Architekture Web Agile CD-INHALT Wir lade Sie ei, ei Uterehme keezulere, das Ihe mehr Chace, Herausforderuge ud Zufriedeheit bietet. Ei Uterehme, das auf Teamwork ud Zusammearbeit setzt. Ei Uterehme, das aktuelle Techologietreds mitgestaltet ud 28 der 30 DAX-Uterehme i Deutschlad ud Top-Uterehme i Österreich ud i der Schweiz hilft, ihr Geschäft eu zu erfide. User Spektrum ist so breit gefächert, dass Sie sogar de Job wechsel köe, ohe das Uterehme zu wechsel. Spreche Sie mit us ud etdecke Sie Ihre Möglichkeite. etdecke-acceture.de» 46 Der bequeme Weg» 98» 60

2 Titelthema JBoss-Migratio Migratio eier J2EE-1.4-Awedug vo JBoss 4 bis 7 Vo 4 über 5 ach 7 Natürlich sammelt jeder seie eigee Erfahruge bei eier Migratio. Es ka daher sei, dass Ihre Awedug ohe oder mit ur weige Äderuge auf alle JBoss-Versioe lauffähig ist. Wahrscheilicher ist es jedoch, dass Sie bei der Migratio auf ähliche Probleme wie der Autor stoße. I diesem Fall sollte Sie folgede Lösuge kosultiere. vo Marcus Schießer I diesem Artikel werde Praxiserfahruge beschriebe, die der Autor bei der Migratio eier J2EE-1.4- Altawedug vo JBoss GA ach JBoss EAP machte. Aschließed erläutert der Autor beispielhaft die Migratio der Awedug zu der eue JBoss- Versio Bei JBoss GA ud hadelte es sich um die frei verfügbare Commuity Editio. Sie ka uter herutergelade werde. JBoss EAP war jedoch die Eterprise Editio, die auf der Versio 5.1 der Commuity Editio aufbaut. Der Ede letzte Jahres veröffetlichte JBoss 6 wird hier icht behadelt, da es sich um ei weig dokumetiertes Zwischerelease hadelt ud die ächste Eterprise Editio auf der Commuity Editio 7 aufbaue wird. Die zu migrierede Awedug basiert auf eier Drei-Schicht-Architektur, die Hiberate i der Persistezschicht, Sessio Beas ach EJB 2.1 i der Busiesslogik ud schließlich Swig für de Rich Cliet verwedet. Die serverseitige Kompoete der Awedug wurde als ei eiziges EAR gepackt ud im JBoss verteilt. Die Swig-Awedug wurde über eie eigeetwickelte Kompoete ählich Java WebStart uterehmesweit verteilt ud kommuiziert mit de Sessio Beas über de HTTP-Ivoker [1] vo JBoss. Als Besoderheit verfügt die Awedug och über ei eigees Maaged Bea (MBea), das über Quartz [2] zeitgesteuerte Abläufe startet. Da es sich um ei MBea hadelt, ist dieses über das JBosseigee SAR-Format ierhalb des EARs verpackt. Außerdem existiert och ei WAR, das ei kleies Servlet ethält, über das der Admiistrator de Zustad der Awedug kotrolliert. Zur Verdeutlichug zeigt Abbildug 1 ei vereifachtes Deploymet-Diagramm der Architektur. Bei der Migratio wurde die Awedug icht ach JEE5 oder JEE6 migriert, soder lediglich derart agepasst, dass sie mit dem JBoss EAP fehlerfrei läuft. Auch für diese vermeitlich kleie Schritt ware eiige Äderuge otwedig, icht zuletzt weil sich zetrale Kompoete wie der Trasaktiosmoitor oder die Security zwische beide JBoss-Versioe geädert habe. Die Agabe der Dateie ist i dem Artikel relativ zu dem Verzeichis der Default-Server-Kofiguratio, die jeweils auch Grudlage für die Migratio war. Diese existiert für beide JBoss-Versioe (4.2.2 ud 5.0.1) ud wird stadardmäßig beim Start vo JBoss verwedet. Die Default-Server-Kofiguratioe befidet sich vom Hauptverzeichis aus gesehe i dem Uterverzeichis server/default. Neuer Trasaktiosmoitor Zuächst betrachte wir die Kofiguratio der itere Services vo JBoss zwische Versio ud Diese sid i der Datei cof/jboss-service.xml kofiguriert. Hier fällt auf, dass im Vergleich zur vorherige Versio die Services für Security, der Trasaktiosmoitor ud der Deploymet Scaer i JBoss wegfalle. Das liegt dara, dass JBoss seit Versio 5 auf eier sehr reduzierte Microcotaier-Architektur basiert, die Services als POJO-Kompoete ud icht mehr als MBeas implemetiert wie bei dem JMX-Kerel vo JBoss 4. Daher sid die geate Services i Versio 5 POJOs, die im Verzeichis deploy istalliert ud kofiguriert werde. A der vo JBoss gelieferte Microcotaier-Kofiguratio musste für Versio keie Apassuge vorgeomme werde, sodass die Stadardkofiguratio (cof/jboss-service.xml) für die Migratio überomme wurde. Bezüglich des Trasaktiosmoitors war für die Awedug i der alte JBoss Kofiguratio 40 javamagazi

3 JBoss-Migratio Titelthema jedoch der Fast I-Memory Trasactio Maager kofiguriert. Er war bereits i JBoss veraltet ud wurde u ab Versio 5 edgültig etfert. Für Versio 5 wurde der Trasaktiosmaager vo der Firma Arjua aufgekauft ud als JBossTS dem JBoss hizugefügt. Kofiguriert werde ka er i der Datei deploy/trasactiojboss-beas.xml. Da die Awedug sehr lagläufige Trasaktioe ethält, musste der Time-Out des Trasaktiosmoitors agepasst werde. Hierzu wurde das Property trasactiotimeout auf 3600 Sekude (oder eie Stude) i dieser Datei folgedermaße erhöht: <proper ty ame="tras actiotimeout">3600</property>. Der eue Trasaktiosmaager bereitete zuächst keie Probleme, bei geauerem Teste gab es jedoch währed der Laufzeit Ausahmefehler, we eie Trasaktio zwei Datasources verwedete. Hitergrud war, dass i der Deploymet-Datei der Datasources (i diesem Fall Oracle-basiert oracle-ds.xml) die beide a der Trasaktio beteiligte Datasources als lokale TX-Datasources (über das Tag local-tx-datasource) kofiguriert ware. Das Problem trat icht mehr auf, achdem der Autor beide Datequelle als XA-Datasources (über das Tag xa-datasource) kofiguriert hatte. Das war erstaulich, da sich beide i derselbe Datebakistaz befade ud daher eigetlich keie XA-Datasource otwedig sei müsste, die im Gegesatz zur lokale TX-Datasource verteilte Trasaktioe erlaubt. Möglicherweise ist der Trasaktiosmaager a dieser Stelle u strikter, sodass er geerell keie Trasaktio mit zwei lokale TX-Datasources erlaubt. Azeige Äderuge a der Security Gleich vorab: Dieser Abschitt behadelt ur die otwedige Äderuge a der JBoss Kofiguratio, um die Awedug fehlerfrei lauffähig zu bekomme der Artikel behadelt icht die Absicherug eier JBoss-Istaz. Die eigesetzte Awedug verwedete scho i der Kofiguratio für JBoss eie eigee cof/stadardjboss. xml. I dieser Datei werde geerell Parameter für die EJBs abhägig vo ihrem Typ (z. B. Sessio Bea oder Etity Bea) festgelegt. Gültig ist diese Datei ur für EJB 2.1 Beas aus Kompatibilitätsgrüde ist sie jedoch ebefalls i JBoss ethalte, um EJB-2.1-basierte Aweduge, wie die usere, verwede zu köe. Um EJBs ab der Versio 3 zu kofiguriere, muss ma gegebeefalls die Dateie deploy/ejb3-coectors-jboss-beas.xml, deploy/ ejb3-cotaier-jboss-beas.xml ud deploy/ejb3-iterceptors-aop.xml apasse. Für die zu migrierede Awedug wurde vo der Stadardkofiguratio abgewiche, uter aderem um eigee Log Iterceptors für die Sessio Beas zu verwede. Ei Iterceptor ist ei Kozept aus der aspektorietierte Programmierug, das es erlaubt, bei eiem Methodeaufruf eie weitere Aufruf vorweg- ud/oder achzuschalte. Bei userer Awedug wurde bei jedem Aufruf eier Methode eier Sessio Bea eie Log-Meldug erzeugt. Um die alte Kofiguratiosdatei verwede zu köe, musste der Autor zuächst die DTD für JBoss aktualisiere. Die DTD musste auch a weitere Stelle aktu- javamagazi

4 Titelthema JBoss-Migratio alisiert werde, i jedem Fall wurde dabei eifach der DOCTYPE im Header der Datei ausgetauscht: <!DOCTYPE jboss PUBLIC"-//JBoss//DTD JBOSS 5.0//EN" " org/j2ee/dtd/jboss_5_0.dtd"> Daach kote die Datei zwar verwedet werde, es trat jedoch ei seltsamer Fehler auf, der erst ach eiiger Aalysezeit dieser Datei zugeordet werde kote. Das Problem ierhalb der Awedug war, dass das Logi immer erfolgreich war, auch we ei falsches Passwort agegebe wurde, die Autorisierug war also immer erfolgreich. Die Ursache war, dass i JBoss 5 die Security über eue Iterceptors geregelt wird ud diese zwiged i cof/stadardjboss.xml kofiguriert werde müsse. I der alte Kofiguratiosdatei vo JBoss 4.2.2, die als Basis für die verwedete Kofiguratiosdatei diete, ware diese atürlich icht kofiguriert. Das Problem wurde behobe, idem der Autor i der Datei für alle Ivoker-Kofiguratioe de SecurityCotextIterceptor hizufügte: <iterceptor>org.jboss.proxy.ejb.securitycotextiterceptor</iterceptor> Für alle Bea-Kofiguratioe wurde PreSecurityIterceptor hizugefügt: <iterceptor>org.jboss.ejb.plugis.security.presecurityiterceptor </iterceptor> Zusätzlich für alle Stateful Sessio Beas wurde StatefulSessioSecurityIterceptor ergäzt: <iterceptor>org.jboss.ejb.plugis.statefulsessiosecurityiterceptor </iterceptor Da wir gerade beim Thema Security sid: I der Datei logi-cofig.xml werde üblicherweise die Security Domais für de Java Autheticatio ad Authorizatio Service (JAAS) kofiguriert. Pro Security Domai werde dabei die Logimodule, die für eie Awedug die Authetifizierug überehme, ud dere Kofiguratiosparameter festgelegt. I eier Awedug wird da lediglich refereziert, zu welcher Security Domai diese gehört, dadurch wird die eigetliche Autorisierug vo der Awedug getret. Vergleicht ma die Stadardkofiguratio der Datei logi-cofig.xml zwische JBoss ud 5.0.1, so wurde die DTD aktualisiert ud die Security Domai für JBoss MQ etfert, das i Versio durch JBoss Messagig ersetzt wurde. Für die Migratio überahm der Autor eifach die Security Domai der Awedug i die Stadardkofiguratio vo JBoss Ei weiteres Securityproblem trat i Zusammehag mit dem HTTP-Ivoker auf. Dieser ermöglicht es, Aufrufe der EJBs über HTTP zu tätige, hierbei diet der HTTP-Ivoker als Adapter, der die eigetliche RMI- Aufrufe kapselt. Stadardmäßig verwedet dieser HTTP- Ivoker i Versio die Security Domai der JMX Cosole (jmx-cosole), astatt, wie och i Versio 4.2.2, die Security Domai der EJB-Kofiguratio aus der Datei jboss.xml. Isofer etsprach das Verhalte i der alte Versio eher der Erwartug. Dieses Problem führte währed der Laufzeit zu eier SecurityExceptio, die verhidert werde kote, idem für de HTTP-Ivoker geerell die Security Domai der Awedug gesetzt wurde. I userem Fall war das kei Problem, da ur usere Awedug de HTTP-Ivoker i JBoss verwedet hat. Hier muss ma gegebeefalls de HTTP-Ivoker mehrmals, d. h. eimal pro Awedug deploye. Alterativ ka ma hier auch eie aktuellere EAP-Versio als verwede, da dieses Problem laut JBoss mittlerweile behobe ist. Um die Security Domai für de HTTP-Ivoker azupasse, wurde diese i der Datei deploy/http-ivoker. sar/iwoker.war/web-inf/jboss-web.xml geädert (im Beispiel hat die Awedug die Security Domai MySecurityDomai): <jboss-web> <security-domai>java:/jaas/mysecuritydomai</security-domai> </jboss-web> Sostige Kofiguratiosapassuge Asoste wurde die Datei für die Log4J-Kofiguratio vo log4j.xml i jboss-log4j.xml umbeat. Das etspricht dem Stadard für JBoss 5 ud wird so i der jboss-service.xml refereziert (die uverädert vo der JBoss Stadardkofiguratio überomme wurde). Außerdem musste der JBoss-eigee Schedulig-Service aus der Serverkofiguratio etfert werde. Für diese Zweck müsse die Dateie scheduler-maagerservice.xml, scheduler-service.xml ud der Resource- Adapter quartz-ra.rar aus dem Verzeichis deploy gelöscht werde. Möchte ma de Schedulig-Service ur deaktiviere, köe die Dateie alterativ auch i ei aderes Verzeichis (z. B. mit dem Name odeploy) verschobe werde. Dieser Schritt war otwedig, da die Awedug ud der Schedulig-Service beide Quartz verwede ud die Awedug für Quartz eie eigee Kofiguratio mitliefert. Sie wurde vo dem Resource- Adapter quartz-ra.rar fälschlicherweise als ihre eigee agesehe (obwohl i eier eigee EAR verpackt) ud gelade. Da i der Quartz-Kofiguratio eie Datasource verwedet wird, die zu diesem Zeitpukt och icht gelade war, gab es eie Ausahmefehler beim Starte des Applicatio Servers. Apassuge a der Awedug Bisher wurde ur die Kofiguratio des Applicatio Servers behadelt, aber für die Migratio ware auch Äderuge a der Awedug selbst otwedig. Zuächst musste die DTD i der jboss-web.xml des WAR- Archivs aktualisiert werde. Hierzu wurde folgeder Header hizugefügt: 42 javamagazi

5 JBoss-Migratio Titelthema Abb. 1: Deploymet- Diagramm der zu migrierede Awedug <!DOCTYPE jboss-web PUBLIC "-//JBoss//DTD Web Applicatio 5.0//EN" " Wie am Afag erwäht, liefert die Awedug ei eigees MBea mit, das sich i eiem SAR-Archiv befidet. Hier hat sich offesichtlich im Vergleich zur JBoss-Versio das SAR-Archivformat geädert, da die zu dem MBea abhägige JARs icht mehr wie zuvor i dem Order lib des SARs gefude wurde. Nachdem diese i das Root des SAR-Archivs kopiert wurde, kote sie jedoch korrekt refereziert werde. Außerdem kote das MBea seie Datasource icht verwede, da diese zu dem Zeitpukt des Lades der MBea och icht gelade war. Hitergrud war, dass eie Referez zu der Datasource i der Kofiguratiosdatei jboss-service.xml des SAR-Archivs fehlte. Diese musste i der MBea-Defiitio ierhalb des <mbea> Tags hizugefügt werde mit: <depeds>jboss.jca:service=datasourcebidig,ame=appds</depeds> Hierbei steht AppDS für de Name der Datasource, die das MBea refereziere soll. Das Deploymet für JBoss hat ohe diese Referezierug fuktioiert. Zum Abschluss stellte sich och zwei kleiere Classloadig-Probleme heraus: Eierseits lieferte die Awedug ihre eigee Versio der Quartz Library (Versio 1.6.0) i seiem EAR mit diese wurde vom Classloader jedoch icht gefude, soder die Versio 1.5.2, die JBoss i dem Pfad commo/lib (vom Hauptverzeichis aus gesehe) ausliefert. Um userer eigee Versio Präferez beim Classloadig zu gebe, wurde die Datei quarz-all jar i de Library-Order der Serverkofiguratio (server/default/lib) kopiert. Ei weiteres Classloadig-Problem trat beim Lade eier awedugseigee Kofiguratiosdatei (Java Properties) auf. Diese wurde bei JBoss korrekt aus dem Verzeichis cof vo JBoss gelade. Das Problem war u, dass sich diese Datei mit adere Kofiguratiosparameter fälschlicherweise zusätzlich i eiem JAR ierhalb des SARs befad. Diese Datei bekam i JBoss die Präferez gegeüber der eigetliche Kofiguratiosdatei im Verzeichis cof ud wurde daher mit de falsche Kofiguratiosparameter gelade. Nachdem das Problem gefude wurde, musste die doppelte Kofiguratiosdatei ierhalb des SARs gelöscht werde. Daach wurde die richtige Kofiguratiosdatei aus dem Verzeichis cof verwedet. Aus 5 mach 7 Damit ist der Teil der Migratio der Awedug auf JBoss abgeschlosse. Der Autor schaute sich i javamagazi

6 Titelthema JBoss-Migratio diesem Zusammehag och die Verteilug der Awedug auf der eue JBoss-Versio 7 a. Dieser Abschitt erklärt jedoch icht die eue Fuktioe, kosultiere Sie hierzu bitte de Artikel Ride the Lightig auf Seite 16, i dem Sie eie ausführliche Eiführug zu JBoss 7 fide. Zuächst trat währed des Deploymets eie Vielzahl a Ausahmefehler auf, weil eie Klasse icht gefude wurde (ClassNotFoudExceptio). Der Hitergrud war, dass mit JBoss 7 das komplette Classloadig auf JBoss Modules [3] umgestellt wurde. Dabei werde Klasse zu Module zusammegefasst ud Abhägigkeite zwische de eizele Module explizit festgelegt. Besteht zu eiem Deploymet (z. B. eiem EAR) keie explizite Abhägigkeit zu eiem Modul, so werde die Klasse dieses Moduls icht gelade. I userem Fall fehlte die Abhägigkeit zu der verwedete Hiberate-Versio ud zu Log4J. Erstere wurde eifach i das Verzeichis lib des EARs kopiert. Da Log4J als Modul jedoch scho vom Applicatio-Server zur Verfügug gestellt wird, muss ma das JAR icht zusätzlich i das EAR kopiere. Besser ist es stattdesse zu defiiere, dass das EAR vo dem vo JBoss mitgelieferte Log4J-Modul (mit dem Name org.apache.log4j) abhägig ist. Um JBoss das mitzuteile, ka eifach folgede Zeile i die Maifest-Datei (MANIFEST.MF) des EARs eigefügt werde: Depedecies: org.apache. log4j. Aschließed ware alle Classloadig-Probleme behobe. Für adere Deploymets fuktioiert die Defiitio eier Abhägigkeit aalog. Daach trat beim Deploymet der Sessio Beas ei Parsig-Fehler i dem EJB-Deploymet-Deskriptor ejb-jar.xml auf. Der Parser erwartete, dass ierhalb der <method>- ud <method-permissio>-tags keie <descriptio>-tags auftrete. Da diese ur Kommetare darstelle ud keie Bedeutug zur Laufzeit habe, wurde sie für diese Test etfert. Darauf wurde die Sessio Beas fehlerfrei im JBoss 7 deployt, obwohl es sich och um EJB 2.1 Beas hadelte. Sie fade sich u lediglich i dem mit EJB 3.1 eigeführte stadardisierte JNDI Namespace [4], sodass der Service Locator [5] der Awedug agepasst werde musste. Nach Aussage vo JBoss solle diese Probleme ab Versio 7.1 behobe sei, da diese Versio EJB 2.1 Beas wieder komplett uterstützt. Etwas Aufwad erforderte auch die Apassug der Datasource-Kofiguratio. Sie ist u i eiem eue Format ud wird direkt i der Datei für die gesamte Serverkofiguratio kofiguriert. Außerdem wird i ihr u auch der vo der Datasource verwedete JDBC-Datebaktreiber als JBoss Module refereziert. Wie die Kofiguratio geau verläuft, würde de Rahme des Artikels sprege, eie Beschreibug für eie MySQL Datasource befidet sich jedoch uter [6]. Soweit lief die Migratio zu JBoss 7 relativ problemlos. Schwierigkeite hat da jedoch die Tatsache bereitet, dass sich das SAR-Archiv der Awedug icht mehr deploye ließ. Zwar uterstützt Versio 7 och MBeas, i userem Fall ließ sich der Deskriptor jedoch auch ach eier Aktualisierug der DTD icht mehr parse. Hier müsste ma geauer aalysiere, was die Ursache ist ud de Deskriptor etspreched apasse. Da das MBea für usere Awedug zeitgesteuerte Aufgabe ausführt, köte ma es alterativ auch i eie EJB 3.1 Timer kovertiere. Ei weiteres Problem war, dass JBoss 7 icht mehr de HTTP-Ivoker ethält. Die Versio des HTTP-Ivokers vo JBoss EAP ließ sich ebefalls icht auf dem eue JBoss deploye. Für diese Migratiosschritt sollte ma gaz auf de HTTP-Ivoker verzichte ud de Rich Cliet auf eie Trasport mit RMI umstelle. Fazit A dieser Stelle wurde die Migratio ach JBoss 7 uterbroche, da das Deploymet des MBeas ud die Reimplemetierug der Trasportschicht zu zeitaufwädig gewese wäre. Fazit ist, dass sich die Migratio eier Altawedug (J2EE 1.4) vo JBoss 4 auf 5 aufwädiger gestaltet hat, als zuächst vermutet. Zwar ist es eifach, Kofiguratiosdateie a ei eues Format azupasse, aber für das geäderte Security- ud Trasaktiosverhalte loht es sich auf jede Fall, eie höhere Aalyse- ud Testaufwad eizuplae. Diese Aufwad sollte ma sicherlich auch für eie Migratio vo JBoss 5 ach 7 eiplae, auch we die Migratio i de bereits durchgeführte Schritte relativ problemlos verlief. Verwedet ma wie im Beispiel EJB 2.1 Beas, loht es sich außerdem, auf Versio 7.1 zu warte, da hier eie bessere Uterstützug ageküdigt ist. Ebeso sollte ma beim Eisatz des HTTP-Ivokers beachte, dass dieser icht mehr uterstützt wird ud daher auch Apassuge a der Awedug selbst otwedig sid. Marcus Schießer ist freiberuflicher Softwarearchitekt ud Cosultat aus Karlsruhe. Seit seier Diplomarbeit im Jahr 2002 verwedet er JBoss, damals och i der Versio 2.4. Aktuell arbeitet er i eiem Projekt als Techischer Architekturveratwortlicher bei der DB Systel GmbH i Frakfurt. Liks & Literatur [1] html/jndi_over_http-accessig_jndi_over_http.html [2] [3] jboss_modules [4] Developer+Guide#DeveloperGuide-JNDIPortableJNDISytax [5] ServiceLocator.html [6] Developer+Guide#DeveloperGuide-DataSourceCofiguratio 44 javamagazi