Geronimo

3-935042-97-3_geronimo.book Seite 1 Dienstag, 18. April 2006 11:17 11

Geronimo

3-935042-97-3_geronimo.book Seite 2 Dienstag, 18. April 2006 11:17 11

3-935042-97-3_geronimo.book Seite 3 Dienstag, 18. April 2006 11:17 11

Christian Dedek, Kristian Köhler

Geronimo

schnell + kompakt

3-935042-97-3_geronimo.book Seite 4 Dienstag, 18. April 2006 11:17 11

Christian Dedek, Kristian Köhler Geronimo schnell + kompakt Frankfurt, 2006 ISBN 3-935042-97-3

© 2006 entwickler.press, ein Imprint der Software & Support Verlag GmbH

http://www.entwickler-press.de/ http://www.software-support.biz/ Ihr Kontakt zum Verlag und Lektorat: [email protected] Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

Korrektorat: Petra Kienle Satz: text & form GbR, Carsten Kienle Umschlaggestaltung: Melanie Hahn Belichtung, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn. Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

3-935042-97-3_geronimo.book Seite 5 Dienstag, 18. April 2006 11:17 11

Inhaltsverzeichnis Kapitel 1: Einführung 1.1 Allgemeines 1.2 Umfang der Auslieferung 1.3 Fremdkomponenten 1.4 Konventionen

7 7 10 12 13

Kapitel 2: Installation 2.1 Download und Installation 2.2 Verzeichnisstruktur 2.3 Skripte zur Verwaltung 2.4 Mögliche Umgebungsvariablen 2.5 Verwendete Ports 2.6 Prüfung der Installation

15 15 16 19 21 22 23

Kapitel 3: Architektur 3.1 Aufbau des Servers Konfigurationen ConfigStore Deployment Beziehungen zwischen Komponenten Repository 3.2 GBeans

25 25 27 27 30 32 34 35

Kapitel 4: Konfiguration 4.1 Konfigurationsmöglichkeiten Konfigurationsdatei config.xml Administrationskonsole Konfigurationsdeployment 4.2 Administrative Einstellungen Logging Webcontainer

41 43 43 48 51 52 52 54

schnell + kompakt

5

3-935042-97-3_geronimo.book Seite 6 Dienstag, 18. April 2006 11:17 11

Inhaltsverzeichnis

Datenbank Java Message Service (JMS)

62 70

Kapitel 5: Arbeiten mit dem Server 5.1 Das Kommandozeilentool deploy 5.2 J2EE-Archive installieren 5.3 Erstellung von Deployment-Plänen Auf Bibliotheken und Dienste verweisen JCA Connectoren Referenzen auf externe Ressourcen Referenzen auf EJB Konfiguration des EJB Containers Konfiguration des Webcontainers Sichere Anwendungen

75 80 83 85 87 89 92 96 98 101 102

Stichwortverzeichnis

107

Die Autoren

109

6

3-935042-97-3_geronimo.book Seite 7 Dienstag, 18. April 2006 11:17 11

KAPITEL 1 Einführung 1.1

Allgemeines

1.2

Umfang der Auslieferung

1.3

Fremdkomponenten

12

1.4

Konventionen

13

1.1

7 10

Allgemeines

Die Apache Software Foundation (ASF) hat nach über zweijähriger Entwicklungszeit die Version 1.0 ihres J2EE-1.4-konformen Application Servers Geronimo bekannt gegeben. Bis zu diesem Zeitpunkt verfolgte die ASF einige Projekte, die Teile der J2EESpezifikation abdeckten. Bis zum Erscheinen des Apache Geronimo fehlte allerdings eine Integration und somit ein eigener J2EE-konformer Application Server. Auf dem Open Source J2EE Application Server-Markt stehen einige freie Implementierungen zur Auswahl. Im Falle von JBoss und JOnAS handelt es sich bereits um J2EE-zertifizierte Produkte. Die Frage nach dem Sinn eines weiteren Produkts scheint berechtigt. Geronimo steht im Gegensatz zu den genannten Alternativen unter der Apache Software License, einem Derivat der Berkeley Software Distribution (BSD)-Lizenz. Sie erlaubt den Einsatz und die Abwandlung der Quellen unter geschlossenen Lizenzen. In diesem Aspekt unterscheidet sie sich von der Lesser General Public License (LGPL), unter der JBoss und JOnAS lizenziert

schnell + kompakt

7

3-935042-97-3_geronimo.book Seite 8 Dienstag, 18. April 2006 11:17 11

1 – Einführung

werden. Jeder Quellcode, der auf LGPL-lizenziertem Code aufsetzt, muss selbst wieder unter einer GPL-/LGPL-Lizenz veröffentlicht werden. Somit scheiden viele Erweiterungen und Verzahnungen mit dem Server für kommerzielle Interessen aus, die nicht offene Lizenzen nutzen möchten. Eine solche Verzahnung kann z.B. durch Einbinden eigener Komponenten, die servereigene Programmierschnittstellen nutzen, entstehen. Die Vision des Geronimo-Projekts ist die Umsetzung des vollständigen J2EE-Funktionsumfangs durch Integration bestehender, erfolgreicher Open-Source-Projekte. Die Kompatibilität der Lizenz dieser Projekte ist hierbei Grundvoraussetzung für die Aufnahme in die Geronimo J2EE Distribution. Nur Ressourcen, die unter BSD-Lizenz oder abgeleiteten Lizenzen angeboten werden, erfüllen diese Kompatibilitätsanforderung der Apache Software Foundation. Auf diesem Wege fanden neben verschiedenen Apache-Implementierungen der WebContainer Jetty oder die EJB ContainerImplementierung von OpenEJB Aufnahme in den Geronimo Application Server. Die Entwicklung des Application Servers ist keineswegs ein Selbstzweck oder eine rein akademische Beweisimplementierung, die nicht für den produktiven Einsatz gedacht ist. Von Anfang an wurde viel Wert auf Modularität, Konfigurierbarkeit und Anpassungsfähigkeit des Servers gelegt. In den hierbei angebotenen Funktionen übertrifft er seine Mitbewerber und stellt somit eine skalierbare, gute und leicht zu konfigurierende Plattform zur Verfügung. Dies garantiert dem Geronimo Application Server ein breites Einsatzgebiet, das von minimalen Desktop-Konfigurationen bis zu hoch verfügbaren 24/7-Cluster-Installationen reicht.

8

3-935042-97-3_geronimo.book Seite 9 Dienstag, 18. April 2006 11:17 11

Allgemeines

Kompakt Das Geronimo-Projekt versteht sich als der Anbieter eines „Best of Breed“ J2EE Applicaton Servers. Ein weiterer Vorzug gegenüber seiner Konkurrenz, seien es Open Source oder kommerzielle Application Server, ist der viel diskutierte späte Markteintritt. Geronimo wurde komplett neu entwickelt1. Bei der Architektur des Servers konnte aus Fehlern früherer Implementierungen der Konkurrenz gelernt und diese entsprechend vermieden werden. Die Umsetzung der J2EE-1.4Spezifikation wurde nicht durch den Ballast bestehender „Altlasten“ erschwert. Die überzeugenden Angebote des Geronimo-Projekts führten im Jahr 2005 zu einer stürmischen Entwicklung. Mit der sich abzeichnenden J2EE-Zertifizierung stieg die Aufmerksamkeit kommerzieller Interessenten innerhalb der Geronimo Community, wobei IBM seine Beteiligung an der Weiterentwicklung des Geronimo Application Servers mit der Übernahme des Apache Supporters GlueCode krönte. Die Firma GlueCode vermarktete bis zu diesem Zeitpunkt unter dem Namen JOE einen eigenen Geronimo-basierten J2EE Application Server, den sie z.B. um eine ansprechende portletbasierte Administrationsoberfläche bereicherte. Dieser Server ging in der IBM WebSphere Application Server Community Edition auf. Die Administrationskonsole ist inzwischen Teil des Standard Apache Geronimo geworden. Andere Hersteller wie der dänische Server-Anbieter Trifork oder die irische Iona beteiligen sich ebenfalls offen an der Weiterent-

1. Zu dieser Thematik gab es zu Beginn der Geronimo-Entwicklung Streitigkeiten mit der JBoss Group, da von dieser Seite behauptet wurde, dass Quellcode übernommen worden sei. Diese Behauptung wurde allerdings entkräftet. Siehe hierzu http://geronimo.apache.org/newshistory.html

schnell + kompakt

9

3-935042-97-3_geronimo.book Seite 10 Dienstag, 18. April 2006 11:17 11

1 – Einführung

wicklung des Application Servers. Beide Firmen unterstützen hierbei die Weiterentwicklung der CORBA-Infrastruktur. In Zusammenhang mit der Freigabe des Geronimo Release 1.0 wurden zusätzlich Teile der integrierten Projekte als neue Unterprojekte in den Apache-Brutkasten (Incubator) aufgenommen. Sie werden in Zukunft als Teilprojekte der Apache Software Foundation weiterentwickelt. Dies betrifft: 쐌 ActiveMQ eine JMS-kompatible Enterprise-Messaging-Plattform 쐌 ServiceMix ein JBI-basierter Enterprise Service Bus (ESB) und SOA Toolkit 쐌 WADI eine Clustering-, Loadbalancing- und Fail-over-Lösung 쐌 XBean ein plug-in-basiertes Server-Framework in Analogie zum Eclipse IDE Framework

1.2

Umfang der Auslieferung

Von der Apache Software Foundation wird Geronimo 1.0 in zwei verschiedenen Distributionen zum Download angeboten. Die beiden Alternativen sind entweder mit Apache Tomcat oder Jetty als Webcontainer vorkonfiguriert. Der restliche Funktionsumfang ist gleich. In beiden Varianten handelt es sich um einen J2EE1.4-konformen Application Server. Der Server besitzt eine ansprechende portletbasierte Administrationskonsole, mit der er überwacht und verwaltet werden kann. Anwendungen lassen sich entweder von einem lokalen oder entfernten Rechner mittels eines mitgelieferten Deploy Tool in den Server installieren. Zusätzlich steht bei lokalem Deployment ein so genanntes Hot Deployment Feature für J2EE-Komponenten zur Verfügung. Hierbei kann durch das Kopieren eines Archivs

10

3-935042-97-3_geronimo.book Seite 11 Dienstag, 18. April 2006 11:17 11

Umfang der Auslieferung

in ein spezielles Verzeichnis eine Anwendung automatisch in den Server installiert werden. Neben den Deployment- und Managementfähigkeiten bietet Geronimo eine Clustering-Unterstützung, die zum Beispiel LoadBalancing für Webanwendungen ermöglicht. Intern arbeitet der Application Server konfigurationsbasiert. Anwendungen und Serverbestandteile lassen sich einzeln als so genannte Konfigurationen verwalten. Diese besitzen einen Lebenszyklus, der vom Java EE Application Deployment (JSR-88) übernommen wurde. In den Server geladene Konfigurationen müssen nicht zwangsläufig ausgeführt werden. Sie lassen sich zu einem späteren Zeitpunkt einzeln starten bzw. auch wieder stoppen oder entfernen. Über diesen Konfigurationsmechanismus lässt sich der Server sehr gut skalieren und auf die verschiedensten Bedürfnisse von kleinen bis zu sehr großen Installationen anpassen. Die aktuelle Geronimo-Version zeichnet sich allerdings nicht nur durch die reine J2EE-Unterstützung und -Zertifizierung aus. Der Geronimo-Kernel kann vielmehr auch als Server Framework bezeichnet werden, mit dessen Hilfe es einfacher wird, einen eigenen Anwendungsserver zu erstellen. Es muss sich nicht zwangsläufig um einen J2EE-Server handeln. Die Konfektionierung eines auf Geronimo basierenden Servers ist sehr leicht möglich. Dies wird durch den Konfigurationsmechanismus und die zur Verfügung gestellten Werkzeuge unterstützt. Geronimo wartet zusätzlich zu den J2EE-Features mit Integrationen von ServiceMix (Java Business Integration Implementierung), Apache Derby (Java Datenbank – vormals IBM Cloudscape) und Apache Directory Service auf.

schnell + kompakt

11

3-935042-97-3_geronimo.book Seite 12 Dienstag, 18. April 2006 11:17 11

1 – Einführung

1.3

Fremdkomponenten

Wie bereits erwähnt, werden von Geronimo viele Open-SourceProjekte integriert. Aus diesem Grund wird an dieser Stelle eine Auswahl der prominentesten Projekte vorgestellt. 쐌 ActiveCluster – Framework zur Erstellung von Clusterbasierten Anwendungen. http://activecluster.codehaus.org/ 쐌 ActiveMQ – Java Messaging Service (JMS)-Implementierung http://www.activemq.org/ 쐌 Axis – Simple Object Access Protocol (SOAP)-Implementierung http://ws.apache.org/axis/ 쐌 Apache Derby – Java-basierte relationale Datenbank http://db.apache.org/derby/ 쐌 Apache Directory – Enterprise Directory Server Platform zur Integration von z.B. LDAP, Kerberos, DHCP http://directory.apache.org/ 쐌 CGLIB – Code Generation Library zur Erzeugung von Klassen zur Laufzeit http://cglib.sourceforge.net/ 쐌 Apache-Commons-Bibliotheken – wiederverwendbare JavaKomponenten wie Datenbankpool, Caches und http-Anfrageklassen. http://jakarta.apache.org/commons/ 쐌 Apache Tomcat – Servlet-Container für Servlets und JSPs http://tomcat.apache.org/ 쐌 Howl – performante Logging-Implementierung für z.B. Transaktionslogs http://howl.objectweb.org/ 쐌 Jetty – Servlet-Container für Servlets und JSPs http://jetty.mortbay.org/jetty/ 쐌 Log4J – Logging-Implementierung http://logging.apache.org/log4j/docs/

12

3-935042-97-3_geronimo.book Seite 13 Dienstag, 18. April 2006 11:17 11

Konventionen

쐌 MX4J – Java Management Extension (JMX)-Implementierung http://mx4j.sourceforge.net/ 쐌 OpenEJB – EJB Container-Implementierung http://openejb.codehaus.org/ 쐌 Scout – Java-API for XML Registries (JAXR)-Implementierung http://ws.apache.org/scout/ 쐌 Tranql – Persistenz-Framework http://tranql.codehaus.org/ 쐌 Wadi – Distributed Caching Service (verteilter Cache) http://incubator.apache.org/wadi/ 쐌 XmlBeans – XML-Binding-Implementierung http://xmlbeans.apache.org/ 쐌 Xerces – XML Parser http://xerces.apache.org/xerces-j/

1.4

Konventionen

In den weiteren Kapiteln dieses Buchs werden anhand von Beispielen die jeweiligen Sachverhalte verdeutlicht. Das GeronimoInstallationsverzeichnis wird hierbei mit dem logischen Bezeichner referenziert. Angegebene Ausführungskommandos beziehen sich immer auf den Aufruf unter einem Microsoft Windows-Betriebssystem. Die angegebenen Parameter unterscheiden sich nicht von denen unter einem UNIX-artigen System. Die Dateinamen der auszuführenden Skripte sind nur in Bezug auf den Dateitypen anzupassen. Windows: startup.bat

bzw. UNIX:

startup.sh

schnell + kompakt

13

3-935042-97-3_geronimo.book Seite 14 Dienstag, 18. April 2006 11:17 11

1 – Einführung

Diesem Buch liegt die Geronimo-Version 1.0 zugrunde. Alle angegebenen Beispiele beziehen sich auf diese Version.

14

3-935042-97-3_geronimo.book Seite 15 Dienstag, 18. April 2006 11:17 11

KAPITEL 2 Installation 2.1

Download und Installation

15

2.2

Verzeichnisstruktur

16

2.3

Skripte zur Verwaltung

19

2.4

Mögliche Umgebungsvariablen

21

2.5

Verwendete Ports

22

2.6

Prüfung der Installation

23

In diesem Kapitel wird die Installation des Geronimo Application Servers behandelt.

2.1 Download und Installation Die Apache Software Foundation bietet über die GeronimoHomepage unter http://geronimo.apache.org zwei Varianten des Geronimo Application Servers 1.0 zum Download an. 쐌 Serverbundle mit Webcontainer Apache Tomcat 쐌 Serverbundle mit Webcontainer Jetty Beide Server-Varianten sind jeweils als tar.gz und zip-Archiv verfügbar. Der Inhalt beider Archivtypen unterscheidet sich nicht. Voraussetzung für den Einsatz des Servers ist das SUN Microsystems Java Runtime Environment (JRE) bzw. das Java Development Kit (JDK) 1.4.2_08 oder eine höhere 1.4.2-Version. Der Einsatz eines J2SE 5 ist nicht möglich, da eine enge Kopplung an die im Sun JRE/JDK vorhandene CORBA-Implementierung besteht. Das verwendete JDK bzw. JRE muss zusätzlich über die Umge-

schnell + kompakt

15

3-935042-97-3_geronimo.book Seite 16 Dienstag, 18. April 2006 11:17 11

2 – Installation

bungsvariable JAVA_HOME bzw. JRE_HOME referenziert werden können. Kompakt Die Geronimo-Version 1.0 ist nur mit dem SUN Java Runtime Environment oder Java Development Kit 1.4.2_08 oder höherer 1.4.2-Version von SUN einsetzbar. Die eigentliche Installation des Servers gestaltet sich recht einfach. Sie besteht einzig aus dem Entpacken des jeweiligen Archivs in ein dafür vorgesehenes Verzeichnis.

2.2 Verzeichnisstruktur Nach dem Entpacken des Geronimo-Archivs entsteht folgende Verzeichnisstruktur:

Abb. 2.1: Geronimo-Verzeichnisstruktur

bin Das bin-Verzeichnis enthält Skripte zum Starten und Stoppen des Servers sowie ein Deploy Tool, mit dessen Hilfe mit dem Server gearbeitet werden kann. Zusätzlich ist das ausführbare Java-

16

3-935042-97-3_geronimo.book Seite 17 Dienstag, 18. April 2006 11:17 11

Verzeichnisstruktur

Archiv client.jar zum Starten eines J2EE Client-Containers enthalten. config-store In diesem Verzeichnis sind Serverbestandteile und Anwendungen in Form so genannter Configurations abgelegt. Die enthaltene Unterverzeichnisstruktur wird von Geronimo-Diensten automatisch verwaltet. Die Datei index.properties führt Buch über den Inhalt dieser Verzeichnisse. deploy Hierbei handelt es sich um das Hot-Deployment-Verzeichnis, in das J2EE-Archivtypen kopiert werden können und anschließend ohne weitere Aktionen automatisch in den Server installiert werden. docs Innerhalb dieses Verzeichnisses befindet sich die zum Zeitpunkt des Geronimo-Release aktuelle Online-Dokumentation. Die jeweils aktuelle Version findet man unter: http://opensource.atlassian.com/confluence/oss/display/GERONIMO lib Sämtliche Bibliotheken, die vom Geronimo-Kern benötigt werden, sind in diesem Verzeichnis enthalten. Zusätzlich wird das Unterverzeichnis endorsed für den Java-Endorsed-Mechanismus benutzt. Das Verzeichnis extension wird standardmäßig als Wert für das System Property java.ext.dirs gesetzt. Hinweis Zusätzliche Informationen zum Endorsed-Mechanismus erhält man unter: http://java.sun.com/j2se/1.4.2/docs/guide/extensions/ spec.html

schnell + kompakt

17

3-935042-97-3_geronimo.book Seite 18 Dienstag, 18. April 2006 11:17 11

2 – Installation

Hinweis Weitere Informationen zum Extension-Mechanismus findet man unter: http://java.sun.com/j2se/1.4.2/docs/guide/standards/ META-INF Dieses Verzeichnis enthält die Manifest-Datei für Geronimo. repository Das so genannte Repository stellt eine strukturierte Ablagemöglichkeit für Bibliotheken zur Verfügung. Dateien, die sich in dieser Verzeichnisstruktur befinden, können von mehreren Anwendungen oder Serverbestandteilen gleichzeitig verwendet werden. Hier können z.B. Datenbanktreiber aufgenommen werden. schema Zur Validierung sämtlicher J2EE Deployment-Deskriptoren und Geronimo Deployment-Plans stehen XML-Schemata zur Verfügung. Diese sind innerhalb des schema-Verzeichnisses zusammengefasst und können zur Validierung eigener Dateien genutzt werden. var Das var-Verzeichnis beinhaltet Konfigurationseinstellungen und Daten für Geronimo sowie für integrierte Server-Bestandteile wie z.B. Tomcat oder Jetty. Innerhalb dieser Verzeichnisstruktur werden z.B. die Logs und die Daten der integrierten Datenbank Derby abgelegt.

18

3-935042-97-3_geronimo.book Seite 19 Dienstag, 18. April 2006 11:17 11

Skripte zur Verwaltung

2.3 Skripte zur Verwaltung Der Application Server lässt sich über die im /bin-Verzeichnis enthaltenen Skripte starten. Unter Windows handelt es sich um Batch-Dateien. Für Unix stehen ShellSkripte zur Verfügung. In beiden Umgebungen werden wiederum zwei Skript-Alternativen angeboten. 쐌 startup.bat bzw. startup.sh 쐌 geronimo.bat bzw. geronimo.sh Das erste Skript startet den Server in einem separaten Prozess. Unter Windows wird hierzu ein neues Fenster geöffnet. Die Unix-Variante führt den Server im Hintergrund aus, wobei die Ausgabe nicht standardmäßig angezeigt wird. Diese wird in die Datei geronimo.out im /var/log-Verzeichnis geschrieben und kann z.B. mittels tail angezeigt werden. tail –f $GERONIMO_HOME/var/log/geronimo.out

Die startup-Skripte stellen die einfachste Möglichkeit dar, den Server zu starten. Sie rufen intern die geronimo-Skripte mit vordefinierten Parametern auf. Zusätzlich angegebene Parameter werden an das geronimo-Skript weitergegeben. Für den direkten Aufruf der geronimo-Skripte müssen entsprechende Kommandozeilenparameter angegeben werden. Diese sind in beiden Plattformvarianten gleich. Insgesamt stehen fünf Kommandos zur Verfügung: 쐌 run Startet den Server im Vordergrund bzw. im gleichen Fenster.

schnell + kompakt

19

3-935042-97-3_geronimo.book Seite 20 Dienstag, 18. April 2006 11:17 11

2 – Installation

쐌 start Startet den Server im Hintergrund bzw. in einem neuen Fenster. 쐌 stop Stoppt den Server. Das Stoppen des Servers erfordert die Angabe eines validen Benutzers mit zugehörigem Passwort. Alternativ hierzu kann das shutdown-Skript verwendet werden. Dieses ruft das geronimo-Skript direkt unter Angabe des stopKommandos auf. ./geronimo.sh stop --user system↵ --password manager

Hinweis Bei den angegebenen Benutzerinformationen handelt es sich um den Standardbenutzer. Auf die entsprechenden Möglichkeiten der Anpassungen wird in Kapitel 4.2 „Administrative Einstellungen“ eingegangen. 쐌 debug Startet den Server im JPDA-Debugger. 쐌 jpda start Startet den Server mittels JPDA-Debugger. Die angegebenen Kommandos können mit weiteren Argumenten aufgerufen werden. Diese wirken sich auf die Log-Ausgabe über die Kommandozeile aus. Mittels --help kann eine Übersicht über alle möglichen Argumente ausgegeben werden.

20

3-935042-97-3_geronimo.book Seite 21 Dienstag, 18. April 2006 11:17 11

Mögliche Umgebungsvariablen

2.4 Mögliche Umgebungsvariablen Zusätzlich zu den Kommandozeilenparametern besteht die Möglichkeit, über Umgebungsvariablen die Laufzeitumgebung des Servers zu beeinflussen. Im Folgenden werden die wichtigsten Umgebungsvariablen in ihrer Bedeutung erklärt: JAVA_HOME Zeigt auf das Java Development Kit (JDK)-Installationsverzeichnis. Dieser Wert muss gesetzt werden, wenn die Umgebungsvariable JRE_HOME nicht gesetzt wurde. Es ist zwingend erforderlich, dass entweder JAVA_HOME oder JRE_HOME gesetzt ist. JRE_HOME Zeigt auf das Java Runtime Environment (JRE)-Installationsverzeichnis. Dieser Wert sollte gesetzt werden, wenn Geronimo mit einem Java Runtime Environment ausgeführt werden soll. Hinweis Geronimo verwendet für die Laufzeitkompilierung einen JDKunabhängigen Compiler. Der Einsatz eines JRE bringt keine Funktionseinbußen mit sich. JAVA_OPTS (optional) Werte, die unter dieser Umgebungsvariablen abgelegt sind, werden beim Aufruf der Java-Virtuellen-Maschine als Parameter mitgegeben. Viele weitere Programme, nicht nur Geronimo, nutzen diese Umgebungsvariable. GERONIMO_OPTS (optional) Werte, die unter dieser Umgebungsvariablen abgelegt sind, werden beim Aufruf der Java-Virtuellen-Maschine als Parameter mitgegeben. Der Unterschied zur Umgebungsvariablen JAVA_ OPTS besteht darin, dass es sich um eine Geronimo-spezifische

schnell + kompakt

21

3-935042-97-3_geronimo.book Seite 22 Dienstag, 18. April 2006 11:17 11

2 – Installation

Einstellung handelt und sie sich somit nicht auf andere Programme auswirken kann. Beispiel Anpassung der Java Heap-Einstellung über Umgebungsvariable: export GERONIMO_OPTS=-Xmx1024m GERONIMO_TMPDIR (optional) Hinter diesem Wert verbirgt sich die Angabe für das Temporärverzeichnis der Virtuellen Maschine. Ist die Variable nicht gesetzt, wird das Verzeichnis /var/temp genutzt. Hinweis Eine Auflistung aller möglichen Umgebungsvariablen enthält die Datei geronimo.bat bzw. geronimo.sh.

2.5 Verwendete Ports Nach dem Start belegt Geronimo standardmäßig mehrere Netzwerkports. Tabelle 2.1 zeigt eine Auflistung. Tabelle 2.1: Netzwerkports

Port

Dienst

1099

RMI Naming

1389

Apache Directory LDAP

1527

Derby Connector

4201

ActiveIO Connector EJB

4242

Remote Login Listener

22

3-935042-97-3_geronimo.book Seite 23 Dienstag, 18. April 2006 11:17 11

Prüfung der Installation Tabelle 2.1: Netzwerkports (Forts.)

Port

Dienst

8009

Tomcat Connector AJP

8080

Tomcat Connector HTTP

8443

Tomcat Connector HTTPS

61616

ActiveMQ Message Broker Connector

Die Anpassung der zu verwendenden Ports kann über die Datei config.xml im Verzeichnis /var/config/ erfolgen.

2.6 Prüfung der Installation Nach dem Ausführen eines der Startskripte kann der erfolgreiche Start des Application Servers überprüft werden. Die letzte Meldung auf der Kommandozeile nach dem Start des Servers und der Ausgabe aller benutzten Ports sollte wie folgt aussehen. Geronimo Application Server started

In der Konsole bzw. in der Datei geronimo.out im Verzeichnis /var/log sollten keine Fehlermeldungen protokolliert worden sein. Ebenfalls sollte die Datei /var/log/geronimo.log keinen Fehlereintrag enthalten. Ist der Server ohne Fehler gestartet, findet man unter der URL http://localhost:8080 eine HTML-Willkommensseite. Diese enthält einen Link zur Administrationskonsole unter http://localhost: 8080/console. Eine Anmeldung kann mit dem Standardbenutzer (Benutzername: system, Passwort: manager) erfolgen.

schnell + kompakt

23

3-935042-97-3_geronimo.book Seite 24 Dienstag, 18. April 2006 11:17 11

3-935042-97-3_geronimo.book Seite 25 Dienstag, 18. April 2006 11:17 11

KAPITEL 3 Architektur 3.1

Aufbau des Servers

25

3.2

GBeans

35

3.1 Aufbau des Servers Der Integrationsgedanke des Geronimo Application Servers spiegelt sich in seiner Architektur wider. Ein statischer Ansatz mit starren und stark gekoppelten Bestandteilen wäre nicht adäquat gewesen. Grundanforderung an die Architektur war eine möglichst gute Entkopplung der Serverkomponenten und eine leichte Erweiterbarkeit. Um dies abdecken zu können, wurde die so genannte Geronimo Bean-Architektur, kurz GBean-Architektur, erschaffen. Es handelt sich hierbei um ein Dependency-Injection-basiertes Konfigurations- und Managementsystem, das nicht nur im Rahmen eines J2EE-konformen Servers eingesetzt werden kann. Der Geronimo-Kern kann vielmehr als Server-Framework bezeichnet werden, der auch als Basis für eigene Server-Projekte nutzbar ist. Zentraler Bestandteil der Geronimo-Architektur ist der so genannte Geronimo-Kernel. An ihm sind sämtliche Komponenten angemeldet. Er verwaltet deren Lebenszyklen sowie die Beziehungen der Komponenten untereinander. Diese Beziehungen werden, wie schon erwähnt, über Dependency Injection aufge-

schnell + kompakt

25

3-935042-97-3_geronimo.book Seite 26 Dienstag, 18. April 2006 11:17 11

3 – Architektur

löst, also nicht starr innerhalb der Komponente, sondern über eine externe Konfigurationsdatei angegeben. Technisch gesehen können an den Kernel nur Geronimo Beans, kurz GBeans, angemeldet werden. Dementsprechend muss entweder die angemeldete Komponente selbst ein GBean sein oder sie stellt für die Verwaltung ein GBean zur Verfügung. GBeans sind gewissermaßen die Brücke zum Geronimo-Kernel.

CORBA GBean

TranQL GBean

Derby

Axis GBean

GBean

GBean

Geronimo Kernel

GBean

Mail

... GBean

Tomcat

GBean

OpenEJB

Abb. 3.1: Geronimo-Kernel mit angemeldeten GBeans

Dieser Ansatz bringt den Vorteil mit sich, dass sich innerhalb des Servers sämtliche angemeldeten Komponenten gleich verhalten, z.B. in Hinblick auf Konfiguration und Verwaltung. Ebenso lässt sich durch ein Deployment eines neuen GBean der Funktionsumfang des Servers leicht erweitern. Alle installierten Komponenten, seien es Serverbestandteile wie Transaktionsmanager oder Connection Pools, aber auch J2EE-

26

3-935042-97-3_geronimo.book Seite 27 Dienstag, 18. April 2006 11:17 11

Aufbau des Servers

konforme Anwendungen, werden über GBeans am Kernel angemeldet und von ihm verwaltet.

Konfigurationen Eine Zusammenstellung mehrerer GBeans wird als Konfiguration bezeichnet. Diese wird selbst wieder als GBean am Kernel angemeldet und durch ihn kontrolliert. Somit können sie einzeln gestartet bzw. wieder gestoppt werden. Da Anwendungen und Serverbestandteile als GBeans am Geronimo-Kernel angemeldet werden, kann eine Anwendung direkt mit einer für sie eingerichteten Datenbankanbindung mittels Konfiguration zusammengefasst und verwaltet werden. Konfigurationen können hierarchisch angeordnet werden. Wurde eine Konfiguration als Kind einer anderen angegeben, so sieht die Kindkonfiguration über die aufgebaute Classloader-Hierarchie alle Bestandteile der Elternkonfiguration. Kompakt Geronimo arbeitet konfigurationsbasiert. Eine Konfiguration ist eine Deployment-Einheit und stellt eine Zusammenstellung von GBeans und Classloader dar.

ConfigStore Im ConfigStore sind alle zur Verfügung stehenden Konfigurationen abgelegt und können einzeln verwaltet werden. Es besteht die Möglichkeit, eine Konfiguration dort in mehreren Versionen vorzuhalten. Abgelegte Konfigurationen müssen nicht zwangsläufig vom Kernel geladen werden. Man kann diese einzeln starten bzw. wieder stoppen. Während des Deployments kann entschieden werden, ob eine Konfiguration nur in den ConfigStore geladen werden oder ob diese danach sofort gestartet werden soll.

schnell + kompakt

27

3-935042-97-3_geronimo.book Seite 28 Dienstag, 18. April 2006 11:17 11

3 – Architektur

Jede Konfiguration besitzt eine eindeutige ID. Im Falle der Geronimo-Server-Bestandteile handelt es sich um eine URI, in der unter anderem eine Versionsnummer enthalten ist. geronimo/j2ee-server/1.0/car

Mit dieser ID können Konfigurationen einzeln gestartet bzw. wieder gestoppt werden. Geronimo kennt verschiedene Kommandos, mit denen Konfigurationen verwaltet werden: 쐌 deploy/undeploy/redeploy – speichert bzw. löscht eine Konfiguration im ConfigStore und startet bzw. stoppt diese automatisch. 쐌 distribute – speichert eine Konfiguration im ConfigStore. Sie wird nicht automatisch gestartet. 쐌 start/stop – startet bzw. stoppt eine Konfiguration aus dem ConfigStore. Beispiel Stoppen der Willkommensseite des Tomcat Bundle über das Kommandozeilenwerkzeug deploy. Das verwendete Werkzeug befindet sich im Verzeichnis /bin. deploy.bat -–user system ↵ --password manager ↵ stop ↵ geronimo/welcome-tomcat/1.0/car

Die Standardimplementierung des ConfigStore legt sämtliche Konfigurationen im Dateisystem ab. Hierzu dient das Verzeichnis /config-store. Hier werden die einzelnen Konfigurationen wiederum in separaten Verzeichnissen

28

3-935042-97-3_geronimo.book Seite 29 Dienstag, 18. April 2006 11:17 11

Aufbau des Servers

gespeichert. Diese enthalten die serialisierte Version der Konfiguration sowie die eventuell enthaltenen J2EE-Archive. Die Datei index.properties führt alle Konfigurationen des ConfigStore auf und verweist auf die entsprechenden Verzeichnisse. Die Verzeichnisnamen werden automatisch beim Deployment durch die ConfigStore-Implementierung aufsteigend nummeriert erzeugt. ... geronimo/j2ee-deployer/1.0/car=18 geronimo/remote-deploy-tomcat/1.0/car=26 geronimo/jmxdebug-tomcat/1.0/car=25 ...

In obigem Beispiel liegt die Konfiguration mit der ID geronimo/ j2ee-deployer/1.0/car im Verzeichnis / config-store/18. Wird eine Konfiguration aktualisiert, wird ein weiteres Verzeichnis angelegt und der Eintrag in der index.properties angepasst. Das Verzeichnis, in dem sich die alte Konfiguration befindet, wird nicht gelöscht. Somit ist es prinzipiell auch nach einem Redeploy möglich, die zuvor installierte Variante wieder zu starten. Wichtig ist hierbei, dass mehrere Versionen einer Konfiguration im ConfigStore vorhanden sein können. In diesem Fall müssen sie unterschiedliche ConfigIDs besitzen. Wird eine neue Version mit neuer ConfigId installiert, wird standardmäßig ein weiteres Verzeichnis angelegt und ein zusätzlicher Eintrag in die Datei index.properties aufgenommen. Die Architektur des Servers sieht vor, dass alternative Store-Implementierungen bereitgestellt werden können, die z.B. die Konfigurationen zentral in einer Datenbank oder einem LDAP-System ablegen. Somit kann ein Config Store von mehreren Servern gleichzeitig genutzt werden.

schnell + kompakt

29

3-935042-97-3_geronimo.book Seite 30 Dienstag, 18. April 2006 11:17 11

3 – Architektur

Für die Weitergabe von Konfigurationen nutzt Geronimo ein proprietäres Configuration Archive (CAR). Darin werden sämtliche Informationen und Attributwerte abgespeichert. Die konfigurierten GBeans werden hierbei als serialisierte Daten im Archiv abgelegt. Enthält die Konfiguration weitere Bestandteile wie z.B. J2EE-Archive, werden diese in ihren bekannten Archivformaten in das CAR aufgenommen. Die serialisierten Werte befinden sich immer in der Datei META-INF/config.ser.

Deployment Das Deployment einer Konfiguration folgt einem einfachen Muster. Zuerst müssen GBeans erzeugt und zusammengestellt werden. Anschließend kann die erzeugte Konfiguration in den ConfigStore gespeichert und gestartet werden. Dies kann bei Geronimo auf drei verschiedene Arten erfolgen. 쐌 Deployment über so genannten Configuration Builder 쐌 Deployment über so genannten Module Builder 쐌 Programmtechnisch

GBean Configuration Deployment Plan

Deployment Descriptor/ Plan

Configuration Builder

GeronimoKernel speichern GBean GBean

Module Builder Programmatisch

GBean

laden

Configuration Store

Abb. 3.2: Deployment Architektur

30

3-935042-97-3_geronimo.book Seite 31 Dienstag, 18. April 2006 11:17 11

Aufbau des Servers

In der ersten Variante wird die Konfiguration aus einer XML-Datei, dem so genannten Deployment-Plan, ausgelesen. Sie enthält die Konfiguration in Form von XML-serialisierten GBeans. Der so genannte Configuration Builder erzeugt daraus die entsprechenden GBeans, welche anschließend im ConfigStore gespeichert werden. Mit dieser Variante werden Geronimo-Dienste wie z.B. der Webcontainer Apache Tomcat oder der Transaktionsmanager in den Server installiert. Über den Configuration Builder werden ebenfalls so genannte Module Builder im Server installiert. Sie stellen spezielle Dienste dar, die wiederum das Deployment von Anwendungen übernehmen können. Im Falle von J2EE-Anwendungen extrahiert der entsprechende Module Builder die benötigten Informationen aus den J2EE Deployment-Deskriptoren sowie den Geronimo-eigenen Deployment-Plan und erzeugt daraus die benötigten GBeans mitsamt der resultierenden Konfiguration. Jedes installierte Archiv wird dementsprechend als separate Konfiguration behandelt. Auch hier werden die GBeans anschließend im ConfigStore gespeichert. Jedem (J2EE-)Anwendungstyp ist ein spezieller Module Builder zugeordnet. Für Webarchive (WAR) steht z.B. der WebModuleBuilder zur Verfügung. Für das Deployment von eigenen Anwendungsarchiven ist lediglich ein weiterer Module Builder nötig, der das entsprechende Archivformat erkennt und auswerten kann. In Geronimo 1.0 ist ausschließlich das J2EE-Anwendungsdeployment im Standardumfang möglich. Abschließend besteht die Möglichkeit, eine Konfiguration programmatisch zu erstellen. Da über den Configuration Builder eine weitaus elegantere und einfachere Möglichkeit besteht, den Server zu erweitern, wird dies in den wenigsten Fällen nötig sein. Intern arbeitet der Configuration Builder über diesen Weg.

schnell + kompakt

31

3-935042-97-3_geronimo.book Seite 32 Dienstag, 18. April 2006 11:17 11

3 – Architektur

Alle drei Alternativen können zu verschiedenen Zeitpunkten durchgeführt werden. 쐌 Übersetzungszeitpunkt 쐌 Ausführungszeitpunkt Für die Ausführung eines Deployments zum Übersetzungszeitpunkt des Servers werden von Geronimo Apache Maven-Plugins eingesetzt. Diese sind in der Serverauslieferung nicht enthalten. Das Deployment zur Laufzeit wird in Kapitel 5 „Arbeiten mit dem Server“ näher beschrieben.

Beziehungen zwischen Komponenten Wie bereits erwähnt, werden Beziehungen zwischen GBeans durch Dependency Injection aufgelöst. Geronimo bietet hier zwei Möglichkeiten an: 쐌 Feste Beziehungsdefinition zu einem GBean 쐌 Angabe eines Interesses an anderen GBeans Im ersten Fall wird im Deployment-Plan eine Beziehung zu einem weiteren GBean angegeben. Das exakte Ziel steht zum Definitionszeitpunkt fest. Die Beziehung wird sofort beim Start des GBean durch Dependency Injection aufgelöst. Der hierbei referenzierte Name muss eindeutig sein. 600 XidFactory ...

32

3-935042-97-3_geronimo.book Seite 33 Dienstag, 18. April 2006 11:17 11

Aufbau des Servers

.. ..

Alternativ können GBeans Interesse an weiteren GBeans anmelden. Mittels eines so genannten Referenzpattern werden GBeans angegeben, über deren Start bzw. Stoppen man informiert werden möchte. Wird ein GBean mit zutreffendem Namen gestartet, wird eine entsprechende Referenz zu diesem GBean über Dependency Injection gesetzt. ... *:j2eeType=ConfigurationStore,* ...

Im obigen Beispiel werden in das GBean „ConfigurationManager“ alle Referenzen zu GBeans injiziert, deren angegebener „j2eeType“ „ConfigurationStore“ ist. Auf diese Weise kann z.B. das GBean, das den Webcontainer repräsentiert, Interesse an sämtlichen Webkomponenten anmelden. Wird eine neue Webkomponente geladen, so wird der Container automatisch darüber informiert. Der DeploymentMechanismus muss keine direkte Referenz zum eigentlichen Webcontainer besitzen. Somit ist es relativ einfach, verschiedene Implementierungen wie den Webcontainer auszutauschen.

schnell + kompakt

33

3-935042-97-3_geronimo.book Seite 34 Dienstag, 18. April 2006 11:17 11

3 – Architektur

Repository Innerhalb eines Repository werden sämtliche vom Server benötigte Bibliotheken verwaltet. Seine Struktur ist an die von Apache Maven angelehnt. Es handelt sich um eine zentrale strukturierte Ablagemöglichkeit für Dateien. Jede Datei im Repository besitzt einen eindeutigen Identifier, der wiederum aus vier Bestandteilen besteht. 쐌 groupId Kurzname der zugehörigen Gruppe. Mittels einer Gruppe können mehrere Bibliotheken zusammengefasst werden. Hierbei handelt es sich im Normalfall um Dateien eines Herstellers. 쐌 type Gibt den Typ der Datei an. Im Falle von Bibliotheken handelt es sich hierbei um „jar“. Geronimo kennt z.B. auch den Typ „rar“ für Resource Adapter-Bibliotheken. 쐌 artifactId Kurzname der Datei. Hierdurch können Dateien innerhalb einer Gruppe unterschieden werden. 쐌 version Angabe zur Version der Datei. Die mitgelieferte Repository-Implementierung legt die Dateien unterhalb des repository-Verzeichnisses ab. Der entsprechende Dateiname setzt sich hierbei wie folgt zusammen. /s/<artifactId>-.

34

3-935042-97-3_geronimo.book Seite 35 Dienstag, 18. April 2006 11:17 11

GBeans

Hinweis Bei bestehenden Dateien, die in das Repository gelegt werden sollen, muss eventuell der Dateiname angepasst werden. Oft fehlen bei Bibliotheken Angaben zur Versionsnummer. Dies ist innerhalb des Repository allerdings zwingend erforderlich! Sämtliche Dateien aus dem Repository können über ein entsprechendes Element innerhalb eines Deployment-Plans in den Classpath der entsprechenden Konfiguration aufgenommen werden. ... <dependency> geronimo <artifactId>geronimo-jetty 1.0 ...

Auf diese Weise können verschiedene Konfigurationen Bibliotheken gemeinsam nutzen. Diese müssen nicht in jeder Konfiguration redundant gehalten werden. Allerdings besitzen sie in einem solchen Fall eine weitere Laufzeitabhängigkeit und können nur in einem Server mit entsprechender Bibliothek im Repository ausgeführt werden.

3.2 GBeans Wie bereits erwähnt, handelt es sich bei GBeans um die zentralen Bausteine innerhalb der Geronimo-Architektur. Über sie können Komponenten an den Kernel angemeldet und verwaltet werden.

schnell + kompakt

35

3-935042-97-3_geronimo.book Seite 36 Dienstag, 18. April 2006 11:17 11

3 – Architektur

Einzige Anforderung an eine GBean-Implementierung ist, dass sie ihre Managementschnittstelle über eine statische Methode veröffentlicht. Die Methode muss getGBeanInfo heißen und ein GBeanInfo-Objekt zurückliefern. Das Info-Objekt enthält hierbei Informationen zu allen Attributen, Methoden und Referenzen des Beans. Zusätzlich können ein Bean-Name sowie ein J2EE Type angegeben werden. Letzterer dient allerdings nur der Verwaltung des Beans. Es stellt keine Bindung zur J2EE-Welt dar. Hinweis Die GBeans können innerhalb des Servers über JMX angesprochen werden. Sie sind allerdings keine MBeans im Sinne der JMX-Spezifikation. Insbesondere entspricht ihre Managementschnittstelle nicht dem JMX-Managementinterface. Bei folgender Klasse handelt es sich um ein einfaches GBean mit einem Attribut „name“. Die Klasse implementiert zusätzlich das GBeanLifecycle-Interface, über das Callback-Methoden zur Verfügung gestellt werden, mit denen das Bean über seinen Lebenszyklus informiert wird. public class BeispielGBean implements GBeanLifecycle { private String name; ... private static final GBeanInfo GBEAN_INFO; static { GBeanInfoBuilder builder = new GBeanInfoBuilder(BeispielGBean.class);

36

3-935042-97-3_geronimo.book Seite 37 Dienstag, 18. April 2006 11:17 11

GBeans

builder.addAttribute("name", String.class, persistent, managebale); GBEAN_INFO = builder.getBeanInfo(); } public static GBeanInfo getGBeanInfo() { return GBEAN_INFO; } public void doStart() throws Exception { System.out.println("start Beispiel"); } public void doStop() throws Exception { ... } ... }

Um ein GBean im Server zu starten, muss es installiert werden. Hierzu sind zwei Schritte nötig: 쐌 Bereitstellung der Klasse innerhalb des Servers 쐌 Deployment mit Hilfe eines Deployment-Plans, der das GBean innerhalb einer Konfiguration enthält Sämtliche Bibliotheken aus dem Repository können aus einer Konfiguration heraus referenziert und demzufolge auch benutzt werden. Somit kann durch Ablage der Klasse im Repository die-

schnell + kompakt

37

3-935042-97-3_geronimo.book Seite 38 Dienstag, 18. April 2006 11:17 11

3 – Architektur

se dem Kernel zur Verfügung gestellt werden. Die Klasse muss sich hierbei innerhalb eines Java-Archivs befinden. Für das obige Beispiel muss die Datei unter folgendem Namen in das Repository kopiert werden. /repository/de.oio/jars/gbean-bsp-1.0.jar

Für ein erfolgreiches Deployment ist zusätzlich ein DeploymentPlan zu erstellen. Dieser muss dem geronimo-config-1.0.xsd-Schema entsprechend eine vollständige Konfiguration beinhalten. In obigem Beispiel besteht diese aus lediglich einem einzelnen GBean. Wichtig hierbei ist die Angabe der Abhängigkeit zum Java-Archiv, das die GBean-Klasse beinhaltet. <dependency> de.oio <artifactId>gbean-bsp 1.0 Kristian

38

3-935042-97-3_geronimo.book Seite 39 Dienstag, 18. April 2006 11:17 11

GBeans

Hinweis Im Verzeichnis /schema befindet sich die Datei geronimo-config-1.0.xsd mit dem entsprechenden Konfigurationsschema. Mithilfe des mitgelieferten DeployTools kann das erstellte GBean im Server gestartet werden. ./deploy.bar –username system –password manager deploy mein-plan.xml

schnell + kompakt

39

3-935042-97-3_geronimo.book Seite 40 Dienstag, 18. April 2006 11:17 11

3-935042-97-3_geronimo.book Seite 41 Dienstag, 18. April 2006 11:17 11

KAPITEL 4 Konfiguration 4.1

Konfigurationsmöglichkeiten

43

4.2

Administrative Einstellungen

52

Dieses Kapitel beschäftigt sich mit der Konfiguration des Servers. Innerhalb des Geronimo ConfigStore werden alle zur Verfügung stehenden Konfigurationen gespeichert und beim Start des Servers ausgelesen. Diese Konfigurationen wurden zum Zeitpunkt des Deployments mit Voreinstellungen ausgestattet, die für die aktuelle Installation durch eine Konfigurationsdatei angepasst werden können. Weitere Informationen hierzu befinden sich auch im Kapitel 3 „Architektur“. Kompakt Zum Startzeitpunkt des Servers werden die bereitzustellenden Konfigurationen aus dem ConfigStore ermittelt und entsprechend geladen bzw. gestartet. Während des Ladevorgangs wird zusätzlich die Konfigurationsdatei ausgelesen, mit deren Hilfe einzelne Attribute einer Konfiguration aus dem ConfigStore überschrieben werden können.

schnell + kompakt

41

3-935042-97-3_geronimo.book Seite 42 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Anpassungen der Konfigurationen können somit über zwei Wege erfolgen: 쐌 Überschreiben der Werte mittels einer Konfigurationsdatei (direktes Editieren bzw. über mitgelieferte Werkzeuge) 쐌 Direkte Änderung der Konfiguration im ConfigStore mittels mitgelieferter Werkzeuge Werden mehrere ähnliche Geronimo-Installationen benötigt, die sich nur in sehr wenigen Attributen wie z.B. einer Port-Angabe für den Webserver unterscheiden, ist es möglich, einen unveränderten ConfigStore für die verschiedenen Installationen zu verwenden. Die sich unterscheidenden Attribute können jeweils durch die Konfigurationsdatei verändert werden. Das Überschreiben von einzelnen Konfigurationsattributen wird über den AttributManager gesteuert. Dieser liest standardmäßig die Datei config.xml im Verzeichnis /var/ config/ ein. Die Angabe, welche Datei verwendet werden soll, kann alternativ über ein System Property der virtuellen Maschine angepasst werden. Geronimo bietet hierzu die Möglichkeit, eine Umgebungsvariable GERONIMO_OPTS mit dem entsprechenden Wert zu setzen. GERONIMO_OPTS= -Dorg.apache.geronimo.config.file=datei.xml

Zur Laufzeit des Servers wird die Konfigurationsdatei nicht erneut eingelesen. Änderungen an den Servereinstellungen können zur Laufzeit nur über Administrationswerkzeuge wie z.B. die mitgelieferte AdminConsole oder per JMX Remoting mit der Open Source Management Console MC4J durchgeführt werden. Diese Änderungen werden sofort in die Konfigurationsdatei geschrieben und stehen nach einem Neustart des Servers weiterhin zur Verfügung. Direkte Änderungen in der Konfigurationsdatei

42

3-935042-97-3_geronimo.book Seite 43 Dienstag, 18. April 2006 11:17 11

Konfigurationsmöglichkeiten

während der Ausführung des Servers haben keinerlei Bedeutung und werden beim Beenden des Servers durch diesen wieder überschrieben. Selbst Kommentare in der Datei werden durch den Server beim erneutem Schreiben entfernt. Trotz offensichtlicher Nachteile ist eine direkte Anpassung der Datei in manchen Situationen notwendig. Wenn z.B. der Server durch einen Port-Konflikt daran gehindert wird, ordnungsgemäß zu starten, und die AdminConsole nicht zugänglich ist, stellt eine direkte Anpassung der Konfigurationsdatei die letzte Rettung dar. Hinweis Nehmen Sie niemals während der Ausführung des Servers Änderungen an der config.xml-Datei vor! Geronimo erzeugt innerhalb des config-Verzeichnisses zusätzlich Backup-Dateien, auf die im Falle einer fehlerhaften Konfiguration zurückgegriffen werden kann. Sie enthalten jeweils den Stand vor der Änderung bzw. den Stand zur Auslieferung.

4.1 Konfigurationsmöglichkeiten Im Folgenden werden die drei Möglichkeiten zur Konfigurationsanpassung gezeigt. 쐌 Anpassung der Konfigurationsdatei config.xml 쐌 Anpassung über die Administrationskonsole 쐌 Konfigurationsdeployment

Konfigurationsdatei config.xml In der Konfigurationsdatei config.xml im Verzeichnis /var/config/ können Konfigurationseinstellungen

schnell + kompakt

43

3-935042-97-3_geronimo.book Seite 44 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

aus dem ConfigStore überschrieben werden. Diese Datei kann direkt angepasst werden. Nachstehend wird die Syntax der Konfigurationsdatei erläutert: ... <pattern> ..

Die nachfolgenden Tabellen listen die einzelnen Elemente und deren Bedeutung auf: attributes Attribute Kindelemente/Inhalt configuration

44

Liste aller Konfigurationen, die geladen bzw. in denen Attribute oder Referenzen geändert werden sollen

3-935042-97-3_geronimo.book Seite 45 Dienstag, 18. April 2006 11:17 11

Konfigurationsmöglichkeiten

configuration Attribute name

Name der zu verändernden Konfiguration. Der angegebene Name muss einer Konfiguration aus dem ConfigStore entsprechen. Beispiel: geronimo/tomcat/1.0/car

load

Attribut zur Angabe, ob die Konfiguration beim Starten des Servers geladen werden soll oder nicht Standardeinstellung: true

Kindelemente/Inhalt gbean

Alle enthaltenen GBeans, für die Konfigurationsattribute verändert werden sollen

gbean Attribute name

Eindeutiger Name des zu verändernden GBeans innerhalb der Konfiguration Beispiel: TomcatWebSSLConnector

load

Attribut zur Angabe, ob dieses GBean beim Starten des Servers geladen werden soll oder nicht

gbeanInfo

JMX ObjectName des zu verändernden GBeans innerhalb der Konfiguration. Dieser Wert wird nicht zwingend benötigt.

schnell + kompakt

45

3-935042-97-3_geronimo.book Seite 46 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

gbean (Forts.) Kindelemente/Inhalt attribute

Liste aller Attribute, die verändert werden sollen

reference

Liste der Referenzen zu anderen Komponenten, die verändert werden sollen

attribute Attribute name

Name des zu ändernden Attributs Beispiel: port

Kindelemente/Inhalt Inhalt dieses Elements ist der neu zu setzende Wert für das angegebene Attribut.

reference Attribute name

Name der zu ändernden Referenz des GBeans. Die Referenz muss im Ziel-GBean vorhanden sein. Beispiel: ServerInfo

Kindelemente/Inhalt pattern

46

Liste von „pattern“- Elementen

3-935042-97-3_geronimo.book Seite 47 Dienstag, 18. April 2006 11:17 11

Konfigurationsmöglichkeiten

pattern Attribute Kindelemente/Inhalt gbean-name

Genau ein „gbean-name“-Element

gbean-name Attribute Kindelemente/Inhalt JMX ObjectName Pattern des referenzierten GBeans Beispiel: geronimo.server:J2EEApplication=null,↵ J2EEModule=geronimo/tomcat/1.0/car,↵ J2EEServer=geronimo,j2eeType=GBean,↵ name=TomcatEngine

Soll z.B. der Standard-Port der RMI Registry für JNDI-Anfragen von der Voreinstellung 1099 auf Port 1199 umgestellt werden, so muss folgender Codeblock in die config.xml-Datei aufgenommen bzw. abgeändert werden:

schnell + kompakt

47

3-935042-97-3_geronimo.book Seite 48 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

1199 rmi://0.0.0.0:1199

Hiermit werden die GBean-Attribute port und namingProviderUrl an den GBeans RMIRegistry und NamingProperties in der Konfiguration geronimo/rmi-naming/1.0/car entsprechend angepasst.

Administrationskonsole Die einfachste Möglichkeit zur Konfiguration des Servers besteht in der Nutzung der mitgelieferten, portletbasierten Administrationskonsole. In der Standardkonfiguration befindet sie sich unter folgender Adresse: http://localhost:8080/console.

48

3-935042-97-3_geronimo.book Seite 49 Dienstag, 18. April 2006 11:17 11

Konfigurationsmöglichkeiten

Abb. 4.1: Geronimos AdminConsole – Begrüßungsseite

Sicherheit der Administrationskonsole Die Administrationskonsole ist durch die Eingabe von Benutzername und Passwort geschützt. Diese Angaben lassen sich über die Dateien users.properties und roles.properties aus dem Verzeichnis /var/security konfigurieren.

schnell + kompakt

49

3-935042-97-3_geronimo.book Seite 50 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Hinweis Standardbenutzername und Passwort lauten: Username: system Passwort: manager Die Datei users.properties enthält hierbei alle Benutzer/PasswortKombinationen. Gruppenzuordnungen für die in der users.properties angegebenen Benutzer erfolgen über die Datei groups.properties. Hinweis Änderungen in beiden Dateien werden zur Laufzeit direkt übernommen. Angaben zu Benutzern und Gruppen sowie deren Zuordnungen müssen nicht direkt in den beiden Konfigurationsdateien editiert werden. Diese lassen sich komfortabel über die Administrationskonsole verwalten. Hierzu dient der Punkt „Console Realm“ im Navigationsmenü. Einstellungen über die Admin Console Zur komfortablen Anpassung vieler Konfigurationsattribute kann die Administrationskonsole eingesetzt werden. Die Arbeit mit der Konsole ist nicht auf die Anpassung einzelner Attribute einer Konfiguration beschränkt. Mit ihrer Hilfe können ganze Konfigurationen gestartet bzw. gestoppt werden. Sämtliche Veränderungen, auch das Starten und Stoppen einzelner Konfigurationen, werden sofort in die Datei /var/ config/config.xml übernommen. Sie sind somit auch nach einem Neustart des Servers wieder gültig.

50

3-935042-97-3_geronimo.book Seite 51 Dienstag, 18. April 2006 11:17 11

Konfigurationsmöglichkeiten

Über die Administrationskonsole werden unter anderem: 쐌 쐌 쐌 쐌 쐌 쐌

neue Bibliotheken in das Repository geladen, Datenbanken eingerichtet und verwaltet, Java Messaging-Konfigurationen vorgenommen, neue Anwendungen installiert, die Systemdatenbank verwaltet und konfiguriert, Sicherheitseinstellungen vorgenommen.

Hinweis Bisher können noch nicht alle Konfigurationsmöglichkeiten des Servers über die Administrationskonsole ausgeschöpft werden. In manchen Fällen ist die direkte Anpassung der Datei config.xml aus diesem Grund unumgänglich.

Konfigurationsdeployment Eine weitere Möglichkeit der Konfigurationsanpassung besteht darin, Konfigurationen direkt im ConfigStore anzupassen. Hierbei werden keine Daten in die config.xml-Datei geschrieben. Für den Fall, dass mehrere Geronimo-Instanzen denselben ConfigStore nutzen, wirkt sich eine solche Änderung in allen Servern aus. Wie bereits erwähnt, wird der initiale ConfigStore beim Übersetzen des Application Servers erzeugt. Eine dort abgelegte Konfiguration kann nur über das Überladen einzelner Konfigurationsattribute mittels der config.xml-Datei verändert werden. Mittels des mitgelieferten kommandozeilenbasierten Deploy Tool können Konfigurationen innerhalb des ConfigStore dahingehend angepasst werden, dass sie komplett ausgetauscht werden. Der Austausch der Konfiguration wird über die redeployOption des Tools erreicht.

schnell + kompakt

51

3-935042-97-3_geronimo.book Seite 52 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Die Benutzung des Deploy Tools wird in Kapitel 5 „Arbeiten mit dem Server“ eingehender betrachtet. deploy.bat --user system --password manager↵ redeploy komplette-konfiguration.xml

Hinweis Jedes Austauschen einer Konfiguration führt zu einem neuen Unterverzeichnis innerhalb des config-store-Verzeichnisses, in dem die neuen serialisierten Daten der Konfiguration abgelegt sind. Die alten Verzeichnisse der Konfigurationen werden nicht gelöscht und stehen als Sicherungskopie zur Verfügung. Der im Aufruf entscheidende Parameter ist die XML-Datei mit Informationen zur auszutauschenden Konfiguration. Für jede im ConfigStore befindliche Konfiguration steht eine solche als Deployment-Plan bezeichnete Datei zur Verfügung. Innerhalb dieses Deployment-Plans müssen im Gegensatz zur config.xml-Datei sämtliche GBeans mit allen Konfigurationsattributen aufgeführt sein.

4.2 Administrative Einstellungen Die Administration des Geronimo Application Servers erfordert die Anpassung bestimmter Konfigurationsattribute. Die folgenden Abschnitte zeigen die wichtigsten Parameter.

Logging Die Standardinstallation beinhaltet das Log4JService GBean, welches die Log4J-Konfiguration innerhalb des Servers übernimmt. Log4J wird von Geronimo selbst für das komplette Logging eingesetzt. Sollen einzelne Server-Bestandteile in einem

52

3-935042-97-3_geronimo.book Seite 53 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

geänderten Log Level ausführt werden, muss die Log4J-Konfiguration dementsprechend angepasst werden. Das Log4JService GBean ist standardmäßig so eingestellt, dass es die Logging-Konfiguration aus der Datei /var/log/server-log4j.properties ausliest. Hierbei handelt es sich um eine normale Log4J-Properties-Datei. In der Standardkonfiguration werden die Log-Meldungen des Servers in die Datei /var/log/geronimo.log im DEBUG-Modus geschrieben. Übersteigt die Größe der LogDatei 10 MB, so wird eine neue Datei erzeugt und in diese weiterprotokolliert. In der Auslieferungskonfiguration werden maximal drei dieser Dateien angelegt. Werden mehr Log-Meldungen produziert, wird immer die älteste Log-Datei gelöscht. Auf der Server-Konsole (unter Windows die Kommandozeile, in der Geronimo ausgeführt wird) werden nur Meldungen im INFO-Level und höher ausgegeben. Dieses Verhalten kann über die Angabe von Kommandozeilenargumenten beim Start des Servers verändert werden. Die Option –v stellt die Ausgabe auf „verbose“ und –vv stellt die Ausgabe auf „veryverbose“. Beispiel Angabe von Logging-Kommandozeilenparametern beim Start. startup.bat --vv

Zur Laufzeit wird alle 60 Sekunden überprüft, ob sich die Log4JKonfiguration geändert hat. Bei einer Veränderung wird diese neu eingelesen.

schnell + kompakt

53

3-935042-97-3_geronimo.book Seite 54 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Webcontainer Der Geronimo Application Server wird in zwei verschieden vorkonfigurierten Versionen zum Download bereitgestellt. Diese Versionen unterscheiden sich durch die mitgelieferten Webcontainer. Die beiden Alternativen sind: 쐌 Apache Tomcat 쐌 Jetty Die Webcontainer-Implementierungen verfügen über unterschiedliche Konfigurationsmöglichkeiten. Sie müssen bzw. können dementsprechend unterschiedlich konfiguriert werden. Wird der mit Apache Tomcat vorkonfigurierte Geronimo Application Server eingesetzt, muss die Konfiguration geronimo/tomcat/1.0/car angepasst werden. Die Verwendung von Jetty als Webcontainer erfordert die Anpassung der Konfiguration geronimo/ jetty/1.0/car. Die zwei Implementierungen stellen über GBeans Attribute zur Konfiguration bereit. Diese Attribute lassen sich über die Konfigurationsdatei config.xml im Verzeichnis / var/config anpassen. In beiden Webcontainer-Implementierungen ermöglichen so genannte Connectoren die Kommunikation zwischen Client und Server. Sie sind dafür verantwortlich, die Anfragen der Clients entgegenzunehmen und an die entsprechende Server-Komponente weiterzugeben. Die vorkonfigurierten Geronimo Server verfügen jeweils über drei eingerichtete Connectoren: 쐌 HTTP – für eine reine HTTP-Kommunikation 쐌 HTTPS – für eine verschlüsselte HTTP-Kommunikation 쐌 AJP – für die Anbindung des Apache HTTP Server

54

3-935042-97-3_geronimo.book Seite 55 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Diese Connectoren können einzeln konfiguriert werden. In der Apache Tomcat-Konfiguration geschieht dies über die angegebene Konfigurations-ID sowie die angegebenen GBeanNamen. Tabelle 4.1: Tomcat-Konfiguration

Konfiguration

geronimo/tomcat/1.0/car

HTTP Connector

TomcatWebConnector

HTTPS Connector

TomcatWebSSLConnector

AJP Connector

TomcatAJPConnector

Bei Jetty müssen die Angaben zur Konfiguration sowie zu den GBeans wie folgt lauten: Tabelle 4.2: Jetty-Konfiguration

Konfiguration

geronimo/jetty/1.0/car

HTTP Connector

JettyWebConnector

HTTPS Connector

JettySSLConnector

AJP Connector

JettyAJP13Connector

Für das Überschreiben der Standard HTTP-Port-Angabe für Apache Tomcat muss somit folgendes XML-Fragment in der Datei config.xml angepasst werden.

schnell + kompakt

55

3-935042-97-3_geronimo.book Seite 56 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

... 0.0.0.0 80 8443 ...

Hierbei wird die Standardangabe von Port 8090 (diese Angabe ist innerhalb der Konfiguration im ConfigStore eingestellt) auf Port 80 umgestellt. Hinweis Die vorkonfigurierten Server-Varianten mit Apache Tomcat und Jetty beinhalten bereits XML-Fragmente für die Port-Anpassungen der Webcontainer in der config.xml-Datei. Wie im obigen Beispiel deutlich wird, lassen sich mehrere Attribute der GBeans konfigurieren. Im Folgenden wird auf die zur Verfügung stehenden Konfigurationsattribute der einzelnen Implementierungen eingegangen. Gemeinsame Konfigurationsattribute host IP-Adresse, an die der Connector gebunden werden soll. Mit dem Wert 0.0.0.0 werden alle vorhandenen IP-Adressen des Rechners verwendet.

56

3-935042-97-3_geronimo.book Seite 57 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

port Zu verwendende Port-Nummer des Connectors. Gängige Werte hierzu sind 80 (Standardport für das HTTP-Protokoll) bzw. 8080. Standardeinstellung bei Apache Tomcat: 8090 Standardeinstellung bei Jetty: 8080 maxThreads Maximale Anzahl der zur Verfügung stehenden Threads für die Abarbeitung von Verbindungsanfragen. Standardeinstellung: 150 (Apache Tomcat und Jetty) acceptQueueSize Maximale Größe der Warteschlange, in die Anfragen gestellt werden, wenn alle Threads für die Abarbeitung von Verbindungsanfragen verwendet werden. Alle Anfragen, die eintreffen, wenn die Warteschlange voll ist, werden abgewiesen. Standardeinstellung: Apache Tomcat 100, Jetty 150 lingerMillis Zeit in Millisekunden, die der Connector warten soll, bis er den von ihm benutzten Socket nach der Verwendung wieder schließen soll. Ein Wert von –1 bedeutet, dass der Socket sofort geschlossen werden soll. Standardeinstellung: -1 (Apache Tomcat und Jetty) tcpNoDelay Bei der Einstellung „true“ wird das TCP_NO_DELAY Flag an den vom Connector verwendeten Socket gesetzt. In den meisten Fällen wird dadurch eine bessere Performance erreicht. Standardeinstellung: true (Apache Tomcat und Jetty)

schnell + kompakt

57

3-935042-97-3_geronimo.book Seite 58 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

redirectPort Port, an den Anfragen weitergegeben werden sollen, wenn eine eintreffende Anfrage eine verschlüsselte Verbindung erfordert und der Connector keine verschlüsselte Verbindungen verarbeiten kann. Hinweis Beim angegebenen Zielport sollte es sich um die Port-Angabe eines mit SSL konfigurierten Connectors handeln. bufferSizeBytes Größe (in Byte) des Zwischenspeichers für den Netzwerkdatenverkehr dieses Connectors. Standardeinstellung Apache Tomcat: 2048 Standardeinstellung bei Jetty: 8192 Zusätzliche Konfigurationsattribute für Jetty Beim Einsatz des Jetty-Webcontainers können zusätzlich die nachstehenden Konfigurationsattribute angepasst werden. minThreads Minimale Anzahl der zur Verfügung stehenden Threads für die Abarbeitung von Verbindungsanfragen. Standardeinstellung: 25 maxIdleTimeMs Maximale Zeit in Millisekunden, die ein Thread auf eine Anfrage warten darf, bevor er wieder zerstört wird. Standardeinstellung: 30000 (30 Sekunden)

58

3-935042-97-3_geronimo.book Seite 59 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

lowThreadsMaxIdleTimeMs Zeit in Millisekunden, nach der eine Verbindung von einem ausbzw. überlasteten Connector persistiert wird. Standardeinstellung: 800 lowThreads Anzahl von unbenutzten Threads, mit der bestimmt wird, ob sich der Connector im ausgelasteten Zustand befindet. Standardeinstellung: 0 Zusätzliche Konfigurationsattribute für Apache Tomcat Wird Apache Tomcat als Webcontainer eingesetzt, stehen zusätzlich folgende Attribute zur Verfügung. minSpareThreads Anzahl der für die Abarbeitung von Verbindungsanfragen zur Verfügung gestellten Threads, die beim Starten des Connectors angelegt werden sollen. Die angegebene Thread-Anzahl wird auch aufrechterhalten, wenn keine Anfragen eintreffen (idletime). Standardeinstellung: 25 Hinweis Der Wert sollte kleiner gewählt werden als die Einstellung von „maxSpareThreads“. maxSpareThreads Maximal zulässige Anzahl von nicht benötigten Threads für die Abarbeitung von Verbindungsanfragen. Wird diese Angabe überschritten, werden die nicht mehr benötigten Threads gestoppt. Standardeinstellung: 75

schnell + kompakt

59

3-935042-97-3_geronimo.book Seite 60 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

maxHttpHeaderSizeBytes Maximal zulässige Größe (in Byte) für den HTTP Request und Response Header. Standardeinstellung: 8192 hostLookupEnabled Gibt an, ob beim Methodenaufruf getRemoteHost() an einem Objekt der Klasse javax.servlet.HttpServletRequest ein DNS Lookup durchgeführt werden soll oder nicht. Bei „true“ wird der Hostname des Clients zurückgeliefert. Bei „false“ wird die aktuelle IP-Adresse zurückgegeben. Standardeinstellung: false connectionTimeoutMillis Zeit in Millisekunden, die der Connector maximal warten soll, bis er nach dem Verbindungsaufbau die Request URI erhalten hat. Standardeinstellung: 20000 (20 Sekunden) uploadTimeoutEnabled Dieses Flag gibt an, ob für die Bearbeitung eines Request eine längere Connection Timeout-Zeit verwendet werden soll. Dies stellt sicher, dass längere Verarbeitungen innerhalb des Servlet bzw. längere Upload-Zeiten nicht zu einem Connection Timeout führen. Standardeinstellung: false Gemeinsame HTTPS-Attribute Folgende Attribute besitzen beide Webcontainer-Alternativen zusätzlich am HTTPS Connector.

60

3-935042-97-3_geronimo.book Seite 61 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

keystoreFileName Name der Keystore-Datei (relativ zum Geronimo Home-Verzeichnis), die das Server-Zertifikat enthält. Wenn das Attribut „truststoreFileName“ nicht gesetzt wurde, wird erwartet, dass in dieser Datei zusätzlich Zertifikate für die Client-Authentifizierung enthalten sind. Standardeinstellung: /var/security/keystore truststoreFileName Name der Keystore-Datei (relativ zum Geronimo Home-Verzeichnis), die Zertifikate für die Client-Authentifizierung enthält. algorithm Angabe zum Algorithmus, mit dem auf den Keystore zugegriffen werden soll. Diese Einstellung kann sich von JVM zu JVM unterscheiden. Dieser Wert sollte im Normalfall nicht angepasst werden müssen. Standardeinstellung: Default keystorePassword Passwort, mit dem auf den KeyStore und den privaten Schlüssel des Servers zugegriffen werden soll. Standardeinstellung: secret truststorePassword Passwort, mit dem auf den Truststore zugegriffen werden soll. secureProtocol Angabe, welche Version des SSL-Protokolls verwendet werden soll. Standardeinstellung: TLS

schnell + kompakt

61

3-935042-97-3_geronimo.book Seite 62 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

keystoreType Format der Einträge in der Keystore-Datei. Standardeinstellung: JKS truststoreType Format der Einträge in der Truststore-Datei. Standardeinstellung JKS clientAuthRequired Flag, das angibt, ob eine Client-Authentifizierung mittels ClientZertifikaten für diesen Connector erforderlich ist. Wurde das Attribut trustStoreFileName gesetzt, wird die dort konfigurierte Keystore-Datei zur Authentifizierung der Clients verwendet. Ist dies nicht der Fall, wird die unter keystoreFileName angegebene Datei benutzt. Standardeinstellung: false Zusätzliche HTTPS-Attribute für Jetty clientAuthRequested Flag, das angibt, ob eine Client-Authentifizierung mittels ClientZertifikaten für diesen Connector erwünscht ist. Standardeinstellung: false

Datenbank Die meisten J2EE-Anwendungen erfordern eine Anbindung an eine über JDBC ansprechbare Datenbank. Innerhalb des Geronimo Application Servers lassen sich Datenbankanbindungen über so genannte Connection Pools zur Verfügung stellen. Konfigurierte Pools werden vom Server im JNDI-Baum angemeldet und können somit von Anwendungen benutzt werden.

62

3-935042-97-3_geronimo.book Seite 63 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Der Geronimo Application Server bietet verschiedene Standardsichtbarkeiten für konfigurierte Datenbankpools an: 쐌 serverweit 쐌 applikationsweit 쐌 clientweit Eine serverweite Sichtbarkeit eines Datenbankpools ist für den Zugriff mehrerer Anwendungen sowie deren Applikationsmodule auf den Datenbankpool gedacht. Datenbankpools, die mit applikationsweiter Sichtbarkeit installiert wurden, sind für Zugriffe aus der entsprechenden Anwendung heraus bestimmt. Bei der clientweiten Sichtbarkeit eines Datenbankpools wird davon ausgegangen, dass Client-Modulen der Zugriff auf die Datenbank ermöglicht werden soll. Die Standardsichtbarkeiten sind nicht als Sicherheitseinstellung zu verstehen. Prinzipiell ist es jeder Server-Komponente unter Umwegen möglich, mittels einer Referenz auf einen installierten Datenbankpool zuzugreifen. Sie erleichtern vielmehr das Arbeiten mit Datenbanken in einem bestimmten Kontext. Die unterschiedlichen Sichtbarkeiten der Datenbankpools werden über das Deployment bestimmt. Es gibt verschiedene Möglichkeiten, die Datenbankpools einzurichten und somit deren Sichtbarkeit zu definieren: 쐌 Deployment über die Administrationskonsole bzw. Kommandozeilentool (serverweite Sichtbarkeit) 쐌 Deployment über den Deployment-Deskriptor der Anwendung (anwendungsweite Sichtbarkeit) 쐌 Deployment über den Deployment-Deskriptor eines ClientModuls (clientweite Sichtbarkeit)

schnell + kompakt

63

3-935042-97-3_geronimo.book Seite 64 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Vorbereitung für eine Datenbankanbindung Jede Datenbankanbindung erfordert einen speziellen Datenbanktreiber, der die Kommunikation mit der Datenbank übernimmt. Dieser Treiber muss dem Server zur Verfügung gestellt werden. Geronimo nutzt hierzu sein Repository. Das Hinzufügen eines Treibers in das Repository kann auf drei unterschiedlichen Wegen erfolgen: 쐌 Manuelles Kopieren des Treibers in das Repository 쐌 Hinzufügen über die Administrationskonsole 쐌 Hinzufügen während der Datenbankkonfiguration

Manuelles Kopieren des Treibers Der für eine Datenbankverbindung erforderliche Treiber kann direkt in das Repository kopiert werden. Hierbei muss der Dateiname im Repository folgendem Muster entsprechen: /s/<artifactId>-.

Beispiel Der Oracle JDBC-Treiber 9.0.2 für JDK 1.4 wird in der Datei ojdbc14.jar ausgeliefert. Diese Datei kann z.B. in das Repository als /oracle/jars/ojdbc14-9.0.2.jar kopiert werden.

Hinzufügen über die Administrationskonsole Die Administrationskonsole bietet für das Hinzufügen von Bibliotheken in das Repository den Menüpunkt „Common Libraries“ an. In einem HTML-Formular können die Treiberdatei sowie die für die Installation benötigten Daten angegeben werden. Auch hier werden die vier Bestandteile des Bibliothek-Identifiers benötigt (siehe „Vorbereitung für eine Datenbankanbindung“).

64

3-935042-97-3_geronimo.book Seite 65 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Hinweis Über diesen Weg können ebenfalls weitere gemeinsam benötigte Bibliotheken in den Server gebracht werden. Es muss sich nicht um Datenbanktreiber handeln.

Hinzufügen während der Datenbankkonfiguration Zusätzlich zu den beiden gezeigten Varianten besteht die Möglichkeit, während der Konfiguration einer Datenbankanbindung einen neuen Treiber zu installieren. Diese Alternative unterscheidet sich von den beiden anderen Varianten dadurch, dass nur vordefinierte Treiber installiert werden können. Diese werden hierbei direkt aus dem Internet heruntergeladen und in das Repository aufgenommen. Die Angabe eines eigenen Treibers ist nicht möglich. Für folgende Produkte bietet die Administrationskonsole eine automatische Installation an: 쐌 쐌 쐌 쐌 쐌 쐌 쐌 쐌 쐌 쐌 쐌 쐌

DaffodilDB FrontBase DataDirect SQL Server Informix InterSystems Cache JdataStore Mimer Oracle Pervasive Pointbase Progress Microsoft SQL Server

schnell + kompakt

65

3-935042-97-3_geronimo.book Seite 66 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Während der Konfiguration einer Datenbankanbindung über den Datenbank-Wizard lässt sich über den Button „Download Driver“ die automatische Installation konfigurieren und starten. Geronimo muss hierzu Zugriff auf das Internet besitzen. Deployment über die Administrationskonsole Die Administrationskonsole bietet über den Menüpunkt „Database Pools“ eine komfortable Möglichkeit, Datenbankanbindungen zu konfigurieren. Die Einrichtung eines Datenbankpools kann innerhalb der Konsole über drei Wege erfolgen: 쐌 Nutzung des Konfigurations-Wizard 쐌 Import von JBoss-4-Konfigurationsdateien 쐌 Import von WebLogic-8.1-Konfigurationsdateien Alle drei Alternativen sind weitestgehend selbsterklärend. Über mehrere HTML-Formulare werden Informationen über den einzurichtenden Datenbankpool abgefragt. Bei den beiden Importvarianten werden Informationen aus den jeweils bestehenden Konfigurationsdateien gelesen und als Voreinstellung für den Datenbank-Wizard übernommen. Vor dem eigentlichen Deployment können die Einstellungen getestet und eventuell noch einmal angepasst werden. Der Wizard bietet zusätzlich die Möglichkeit, den zugrunde liegenden Deployment-Plan des neu eingerichteten Datenbankpools anzuzeigen. Dieser kann für ein manuelles Deployment über die Kommandozeile oder für den Einsatz innerhalb eines Deployment-Deskriptors einer Anwendung kopiert und verwendet werden.

66

3-935042-97-3_geronimo.book Seite 67 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Hinweis In der Liste der Datenbankpools unter „Database Pools“ im Menü der Administrationskonsole findet man den Link „usage“. Dieser verweist auf eine Beschreibungsseite, wie dieser Datenbankpool aus einer Anwendung heraus angesprochen werden kann. Deployment über Kommandozeile Das Deployment eines serverweit sichtbaren Datenbankpools kann ebenfalls über die Kommandozeile erfolgen. Hierzu dient das mitgelieferte Deploy Tool. Geronimo nutzt für die Anbindung von externen Ressourcen die Java Connector Architecture (JCA). Diese kommuniziert über so genannte Resource Adapter mit einer Datenquelle. Aus diesem Grund muss beim Aufruf des Tools ebenfalls ein entsprechender Adapter angegeben werden. Zusätzlich wird ein DeploymentPlan erwartet, der dem Format einer Resource Adapter-Konfiguration entspricht. Geronimo bringt den TranQL Resource Adapter mit, der standardmäßig für JDBC-Datenbankanbindungen genutzt wird und beim Aufruf des Deploy Tools mitangegeben werden muss. Hinweis Die einfachste Variante zur Erstellung eines Connector Deployment-Plans besteht in der Nutzung der Administrationskonsole. Hier können Datenbankanbindungen konfiguriert und deren Deployment-Plan angezeigt werden. Der angezeigte Plan kann kopiert und verwendet werden.

schnell + kompakt

67

3-935042-97-3_geronimo.book Seite 68 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Ein Aufruf zum Deployment einer Datenbankanbindung sieht demnach folgendermaßen aus: deploy.bat --user system --password manager↵ deploy datenbank-plan.xml↵ tranql-connector-1.1.rar

Ein Deployment über die Kommandozeile ist dann sinnvoll, wenn die Aktion z.B. für Tests automatisiert werden soll oder wenn dem Resource Adapter mehr Properties mitgegeben werden sollen, als die Administrationskonsole anbietet. Hinweis Das TranQL Resource Adapter-Archiv befindet sich im Verzeichnis /traql/rars/ unterhalb des Repository-Verzeichnisses. Deployment über Deployment-Deskriptor Für den Fall, dass die Standardsichtbarkeit einer Datenbankanbindung auf eine Anwendung beschränkt sein soll, muss der Deployment-Plan in das Anwendungsarchiv aufgenommen werden. Mit dieser Möglichkeit kann beim Deployment einer Anwendung die entsprechende Datenbankanbindung mit gestartet und beim Undeployment wieder gestoppt und gelöscht werden. Das EAR-Anwendungsarchiv muss hierbei alle benötigten Informationen für das Datenbankdeployment enthalten. Der Deployment-Plan sowie der Resource Adapter müssen mit eingepackt werden. Der Adapter muss selbst als Anwendungskomponente innerhalb der Datei geronimo-application.xml angegeben werden.

68

3-935042-97-3_geronimo.book Seite 69 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

... <module> tranql-connector-1.1.rar mysql-plan.xml

Eine EAR-Datei kann demnach wie folgt aufgebaut sein: | +| +| +| +-

mysql-plan.xml tranql-connector-1.1.rar account-server.jar META-INF | +- application.xml | +- geronimo-application.xml

Der eingepackte Deployment-Plan unterscheidet sich nicht von einem Deployment-Plan, der über die Kommandozeile installiert werden kann. Er muss ebenso dem geronimo-connector-1.0.xsdSchema entsprechen.

schnell + kompakt

69

3-935042-97-3_geronimo.book Seite 70 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Undeployment der Datenbankanbindung Das Undeployment einer Datenbankverbindung kann wie das Deployment auf unterschiedlichen Wegen erfolgen: 쐌 über die Administrationskonsole 쐌 über die Kommandozeile Unter dem Menüeintrag „J2EE Connectors“ in der Administrationskonsole befindet sich eine Liste aller konfigurierten Datenbankanbindungen, die mit dem jeweils entsprechendem Link gelöscht werden können. Bei einer Datenbankanbindung, die mit einer Anwendung installiert wurde, ist es ausreichend, die Anwendung aus dem Server zu entfernen. Alternativ zur Administrationskonsole kann über das Deploy Tool mittels des „undeploy“-Kommandos der Pool gelöscht werden. Als Parameter muss hierbei die configId der Datenbankanbindung angegeben werden. deploy.bat --user system --password manager ↵ undeploy ↵ user/database-pool-MySqlDS/1/car

Hinweis Die configId befindet sich im Deployment-Plan als Attribut des Root-Elements „connector“.

Java Message Service (JMS) In vielen Anwendungsfällen ist eine synchrone Verarbeitung von Aufgaben nicht nötig bzw. nicht sinnvoll. Zeitintensive Aktionen sollen oft im Hintergrund abgearbeitet werden. Mit dem Java Message Service (JMS) lässt sich diese Anforderung erfüllen.

70

3-935042-97-3_geronimo.book Seite 71 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Jeder J2EE-konforme Application Server muss eine entsprechende Implementierung beinhalten. Geronimo nutzt hierzu die Implementierung ActiveMQ. Zentraler Bestandteil in der ActiveMQ-Architektur ist der so genannte Message Broker, der für die Verarbeitung der Nachrichten zuständig ist. Er wird über ein GBean an Geronimo angemeldet und kann dementsprechend konfiguriert werden. In der Geronimo Standardkonfiguration wird der ActiveMQ Message Broker automatisch gestartet und muss im Normalfall nicht konfiguriert werden. JMS ConnectionFactories sowie zugehörige Queues und Topics werden zu so genannten Resource Groups zusammengefasst. Diese können einzeln konfiguriert und installiert werden. Die Kommunikation eines Clients mit dem Message Broker erfolgt, wie schon bei einer Datenbankanbindung, über die Java Connector Architecture (JCA). Geronimo bietet hierzu einen entsprechenden Resource Adapter an. Hinweis Der ActiveMQ JCA Resource Adapter befindet sich im Verzeichnis /activemq/rars. Der Vorteil eines solchen JCA-konformen Adapters besteht in der möglichen Nutzung von Containerdiensten wie z.B. der Transaktionssteuerung. Ein Client, sei es Servlet, JSP-Seite oder EJB-Komponente, muss die JCA-Schnittstelle allerdings nicht programmatisch ansprechen. Er kann hierzu das normale JMSAPI nutzen. Die Konfiguration einer JMS-Anbindung ähnelt der einer Datenbankanbindung. Über einen Deployment-Plan muss der ActiveMQ Resource Adapter für die Kommunikation mit dem Message Broker eingerichtet werden.

schnell + kompakt

71

3-935042-97-3_geronimo.book Seite 72 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration

Wie bei einer Datenbankanbindung bestehen verschiedene Möglichkeiten für das Deployment einer JMS Resource Adapter-Konfiguration. Sie entscheiden auch hier über die Standardsichtbarkeit der JMS Resource Group. 쐌 Deployment über die Administrationskonsole bzw. das Kommandozeilentool (serverweite Sichtbarkeit) 쐌 Deployment über den Deployment-Deskriptor der Anwendung (anwendungsweite Sichtbarkeit) 쐌 Deployment über den Deployment-Deskriptor eines ClientModuls (clientweite Sichtbarkeit) Deployment eines JMS Resource Adapters Das Deployment eines JMS Resource Adapters kann analog zum Deployment einer Datenbankanbindung erfolgen. Der Kommandozeilenaufruf zum Deployment sieht folgendermaßen aus: deploy.bat --user system --password manager↵ deploy jms-plan.xml↵ activemq-ra-3.2.1.rar

Beim Deployment über die Kommandozeile besitzt der JMS Resource Adapter eine serverweite Standardsichtbarkeit. Durch die Integration des Deployment-Plans in die Anwendung kann die Standardsichtbarkeit auf die entsprechende Anwendung begrenzt werden. Hinweis Die Konfiguration der JMS-Anbindung wird im Unterkapitel „JCA Connectoren“ ab Seite 89 beschrieben.

72

3-935042-97-3_geronimo.book Seite 73 Dienstag, 18. April 2006 11:17 11

Administrative Einstellungen

Message-Broker-Konfiguration Der Message Broker ist in der Standardauslieferung bereits konfiguriert. Als Standardpersistenzmechanismus wird die im Geronimo mitgelieferte Apache-Derby-Datenbank verwendet. Zur Performance-Steigerung ist ein Cache eingerichtet, der bis zu 10000 Nachrichten im Speicher hält. Zusätzlich sind zwei Connectoren konfiguriert, über die man sich mit dem Server verbinden kann: 쐌 TCP-basiertes Protokoll über Port 61616 쐌 VM-interne Kommunikation Mithilfe der Datei confix.xml im Verzeichnis /var/conf lassen sich im Bedarfsfall Konfigurationsattribute des Message Brokers anpassen. Die configId für den ActiveMQ Broker lautet: geronimo/activemq-broker/1.0/car. Tabelle 4.3 zeigt ausgewählte ActiveMQ GBeans mit ihren wichtigen Attributen. Tabelle 4.3: ActiveMQ-Konfiguration

Name

Attribute

ActiveMQ.jdbc

dataSource Mithilfe dieses Attributs kann die Standarddatenbank umgestellt werden. Hierbei muss ein gbean-name-Element angegeben werden. ...

schnell + kompakt

73

3-935042-97-3_geronimo.book Seite 74 Dienstag, 18. April 2006 11:17 11

4 – Konfiguration Tabelle 4.3: ActiveMQ-Konfiguration (Forts.)

Name

Attribute

ActiveMQ.cache

cacheSize Angabe zur Anzahl der im Cache zu haltenden Nachrichten. 10000

ActiveMQ.tcp.↵ default und ActiveMQ.vm.↵ localhost

port Port, über den sich Clients mit dem Server verbinden können. protocol Zu verwendendes Protokoll. Mögliche Werte sind: vm, tcp und ssl. tcp localhost 61616

Alternativ zur Anpassung des systemweiten Message Brokers kann ActiveMQ mit einem zweiten Deployment-Plan ein zweites Mal in Geronimo installiert werden. Somit stehen zwei separate JMS-Server zur Verfügung. Eine weitere Option besteht darin, ActiveMQ als Teil einer Anwendung zu installieren. In diesem Fall müssen alle ActiveMQ-GBeans angegeben und konfiguriert werden. Dies kann über die Datei geronimo-application.xml innerhalb eines EAR-Archivs erfolgen.

74

3-935042-97-3_geronimo.book Seite 75 Dienstag, 18. April 2006 11:17 11

KAPITEL 5 Arbeiten mit dem Server 5.1

Das Kommandozeilentool deploy

80

5.2

J2EE-Archive installieren

83

5.3

Erstellung von Deployment-Plänen

85

Innerhalb des Geronimo Application Servers können zwei Arten von Komponenten installiert werden: 쐌 Geronimo Services 쐌 J2EE-Anwendungen Geronimo Services sind spezifische Erweiterungen des Geronimo Application Servers, welche gegenüber dem Server-Kern über GBeans repräsentiert werden. Zwar bilden Geronimo Services oft die Basis von J2EE-Anwendungen, die stark modularisierte Struktur und spezielle Abhängigkeitsverwaltung des Servers erlauben jedoch eine saubere logische Trennung beider Komponentenarten. Als Bausteine der Grundarchitektur eines Geronimo Servers wurden die GBeans bereits in einem eigenen Kapitel behandelt. J2EE-Anwendungen sind verteilbare Softwarekomponenten, die den Standards der Java 2 Enterprise Edition entsprechen und auf sämtlichen kompatiblen J2EE Application Servern einsetzbar sind. Sie werden in Form von standardisierten Archivdateien (EAR, WAR, JAR, RAR) ausgeliefert. Die grundsätzliche Konfigurations- und Installationsbeschreibung erfolgt mit Deploy-

schnell + kompakt

75

3-935042-97-3_geronimo.book Seite 76 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

ment-Deskriptoren in Form standardisierter XML-Dateien. Über den Kopf dieser XML-Dateien kann die jeweils verwendete J2EEVersion festgelegt werden. Der J2EE-Standard enthält aus Gründen der Übertragbarkeit von Anwendungen häufig nur abstrakte Beschreibungen von Schnittstellen zu Application Servern. Daraus resultiert für die Installation von J2EE-Anwendungen die Notwendigkeit der Zuordnung konkreter Umsetzungen dieser Abstraktionen. Typische Herausforderungen sind hier z.B. der Zugang zu relationalen Datenbanken, Anwenderrollen oder das Mapping von Entity-Beans. Für die Installation in den Geronimo Application Server stehen vier Wege zur Verfügung: 쐌 쐌 쐌 쐌

JSR-88-konformes Werkzeug dateibasiertes Hot Deployment Kommandozeilenwerkzeug Maven-Plug-in

Die Installationsprozedur selbst wird auf allen Wegen durch einen Deployment-Plan beschrieben. Kompakt Ein Deployment-Plan ist eine Geronimo-spezifische XMLDatei, die den Deployment-Deskriptoren der J2EE-Spezifikation ähnelt. Alle Fragestellungen der Installation und Konfiguration von Komponenten werden in Form von DeploymentPlänen bearbeitet. Bei Durchführung einer Installation kann dem jeweiligen Werkzeug der Deployment-Plan als zusätzliche Ressource neben der eigentlichen Komponente übergeben werden. Nur bei J2EE-Anwendungen können die Deployment-Pläne auch direkt innerhalb der standardisierten Archive abgelegt werden.

76

3-935042-97-3_geronimo.book Seite 77 Dienstag, 18. April 2006 11:17 11

Arbeiten mit dem Server

Beispiel Installation des J2EE-Enterprise-Archivs (EAR) meinAnwendungsArchiv.ear mit externem Deployment-Plan meinPlan.xml über die Kommandozeilenschnittstelle. deploy.bat deploy meinAnwendungsArchiv.ear meinPlan.xml

Die J2EE Application Deployment API (JSR-88) ist der Standard für das Deployment von J2EE-Anwendungsarchiven. Mithilfe dieses Standards können nur J2EE-Anwendungen installiert werden. Geronimo besitzt einen entsprechenden JSR-88 APITreiber im Verzeichnis /repository/geronimo/jars/geronimo-deploy-jsr88-1.0.jar. Dieser kann mit jedem JSR88-kompatiblen Werkzeug genutzt werden. Auf die Benutzung dieser Schnittstelle soll in diesem Kapitel nicht weiter eingegangen werden, da sie keine besonderen Features oder Merkmale präsentiert. Ein nützliches Feature des Geronimo Application Servers, insbesondere im Entwicklungsfall, stellt die Möglichkeit des Hot Deployments dar. Dabei handelt es sich um einen innerhalb der Standardinstallation gestarteten Geronimo Service, der das Verzeichnis /geronimo/deploy auf darin enthaltene J2EE-Standardarchive überwacht. An diese Stelle kopierte Archive werden automatisch installiert und gestartet. In diesem Fall ist es notwendig, den Deployment-Plan innerhalb des J2EE-Archivs abzulegen. Hinweis Durch die Ablage eines Deployment-Plans innerhalb eines Archivs sind für die Namensgebung der Datei Einschränkungen gegeben (siehe „J2EE-Archive installieren“).

schnell + kompakt

77

3-935042-97-3_geronimo.book Seite 78 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Außerhalb der Standardinstallation existiert in den Ressourcen des Geronimo-Projekts mit der Datei geronimo-deployment-plugin1.0.0.jar ein Maven-1-Plug-in, das als Geronimo-DeploymentPlug-in bezeichnet wird. Das Plug-in bietet zusätzlich zur Installation von J2EE-Anwendungen und Geronimo Services die Möglichkeit, den erfolgreichen Start des Application Servers zu überwachen. Das Kommandozeilentool deploy ist eine Java-Anwendung, die im /geronimo/bin/deployer.jar ausgeliefert wird. Das JSR-88-kompatible deploy-Werkzeug greift über einen eigenen JSR-88-API-Treiber auf Geronimo zu. Der vollständige Funktionsumfang erlaubt die Installation von J2EE-Anwendungen und Geronimo Services. Dabei können Deployment-Pläne sowohl als externe Ressource (GBeans, J2EE-Anwendungen) als auch innerhalb der standardisierten Archive (J2EE-Anwendungen) zum Einsatz kommen. Da die Nutzung des Kommandozeilentools die volle Bandbreite der Installationsmöglichkeiten gewährt, wird dieses Werkzeug im Folgenden als Referenz für die Installationsmöglichkeiten des Geronimo Application Servers detaillierter beschrieben. Bei der Installation von Komponenten in den Server kommen bestimmte, an die JSR-88 angelehnte Grundbegriffe zum Einsatz. Diese sollen hier abschließend definiert werden, bevor auf Einzelheiten zu Werkzeugen, Archiven und Deployment-Plänen eingegangen wird: 쐌 Module Module bezeichnet eine in einem Application Server installierbare Erweiterung. Im Falle von J2EE-Anwendungen ist jedem Module ein standardisiertes Archiv, z.B. EAR- oder WARDatei, zugeordnet. Nach der Installation resultiert aus einem Module eine Server Configuration.

78

3-935042-97-3_geronimo.book Seite 79 Dienstag, 18. April 2006 11:17 11

Arbeiten mit dem Server

쐌 ModuleID Die ModuleID ist ein eindeutiger Bezeichner eines Moduls. Dieser Bezeichner wird im Deployment-Plan des Moduls definiert. 쐌 Target Das Target bezeichnet ein logisches Ziel der Installation eines Moduls. Bei Geronimo handelt es sich um den ConfigStore. 쐌 TargetModuleID Die TargetModuleID ist ein eindeutiger Bezeichner, gebildet aus dem Target-Namen und der ModuleID. Die TargetModuleID erlaubt die eindeutige Bezeichnung einer mehrfach im Geronimo Application Server installierten Komponente. 쐌 Deployment-Plan Der Deployment-Plan ist die Beschreibung der Installation und Konfiguration eines Moduls in Form einer XML-Datei. Entweder wird der Deployment-Plan innerhalb des zugeordneten J2EE-Archivs gespeichert oder er muss in Form eines Verweises auf eine externe URL angegeben werden. 쐌 Server Configuration Die Server Configuration bezeichnet die grundlegende Einheit, auf der das Deploy Tool operiert. Das Deploy Tool kann unter anderem Server Configurations verteilen, installieren und starten. J2EE-Anwendungen, die mittels eines EAR-Archivs installiert werden, bilden eine Server Configuration, deren ModuleID im Deployment-Plan des EAR festgelegt ist. Eine alleinstehende J2EE-Komponente erhält eine eigene Server Configuration gemäß dem Deployment-Plan des zugeordneten Archivs.

schnell + kompakt

79

3-935042-97-3_geronimo.book Seite 80 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

5.1 Das Kommandozeilentool deploy Das Kommandozeilentool ist ein ausführbares Java-Archiv, das auf weitere Bibliotheken und relative Ressourcen zurückgreift. Daher kann es aktuell nur innerhalb der Geronimo-Standardinstallation wie folgt gestartet werden: java –jar /bin/deployer.jar

Zum bequemeren Einsatz des Werkzeugs wird im Weiteren auf die Benutzung des in der Standardinstallation bereitgestellten Skripts zurückgegriffen. Der Aufruf entspricht folgendem Muster: /bin/deploy [Standardoptionen] Kommando [spezifische Optionen]

Als Parameter für das Deploy Tool können Benutzername und Passwort für einen Systembenutzer angegeben werden. Fehlen diese Angaben beim Aufruf des Tools, werden sie über die Kommandozeile abgefragt. Mithilfe der Standardoptionen werden Art und Weise der Verbindung mit einem Geronimo Server-Prozess bestimmt. Falls keine Standardoptionen angegeben werden, wird die Verbindung mit einem lokalen Server-Prozess aufgebaut. Beispiel Ein lokales Deployment des Archivs ear-sample.ear mit eingepacktem Deployment-Plan kann mit folgender Kommandozeile ausgeführt werden. Ein gültiger Administrationsbenutzer system mit dem Passwort manager wird vorausgesetzt.

80

3-935042-97-3_geronimo.book Seite 81 Dienstag, 18. April 2006 11:17 11

Das Kommandozeilentool deploy

/bin/deploy.bat↵ --user system↵ --password manager↵ deploy↵ ear-sample.ear

Für eine erfolgreiche Verbindung zu einem Server-Prozess existieren zwei Voraussetzungen. 쐌 RMI-Dienst innerhalb des Servers 쐌 Möglicher Dateitransfer zwischen Deploy Tool und Server Für den Fall eines lokalen Server-Prozesses kann der Dateitransfer über ein gemeinsames Dateisystem erfolgen. Zur Standardinstallation des Geronimo Application Servers gehört die Applikation remote-deploy, die im Webcontainer installiert ist. Diese Applikation kann im Falle eines nicht lokalen Server-Prozesses für den Dateitransfer benutzt werden. Im Anschluss werden die einzelnen Kommandos beschrieben: 쐌 Login Mit diesem Kommando kann die Authentifizierungsinformation für das Deploy Tool lokal innerhalb des Benutzerverzeichnisses in der Datei .geronimo-deployer abgespeichert werden. Die Informationen werden beim ersten Aufruf gegen den Server validiert. Bei weiteren Aufrufen des Deploy Tools wird die abgelegte Authentifizierung benutzt. Profitipp Obwohl Username und Passwort verschlüsselt abgelegt werden, sollte die Authentifizierungsdatei gegen unberechtigten Zugriff geschützt werden!

schnell + kompakt

81

3-935042-97-3_geronimo.book Seite 82 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

쐌 Deploy/Undeploy/Redeploy Installiert bzw. deinstalliert Server Configuration in den ConfigStore und startet bzw. stoppt diese automatisch. Auf diesem Weg können neben Anwendungen auch Server-Konfigurationen verwaltet werden. 쐌 Distribute Installiert Server Configuration in den ConfigStore. Diese werden nicht automatisch gestartet. 쐌 Start/Stop Startet bzw. stoppt eine Server Configuration. 쐌 List-modules Führt alle Module auf, auf die der Server zugreifen kann. In der Standardinstallation handelt es sich um alle Server Configurations im lokalen ConfigStore. 쐌 List-targets Führt alle verfügbaren Targets auf. 쐌 Help Mit dem Help-Kommando können weitergehende Hilfen auf der Kommandozeile angefordert werden. Beispiel deploy.bat help – führt allgemeine Hilfe zum Werkzeug auf. deploy.bat help options – führt die gemeinsamen Optionen auf. deploy.bat help – führt die speziellen Optionen des

Kommandos auf. deploy.bat help all – führt die vollständigen Optionen aller

Kommandos auf.

82

3-935042-97-3_geronimo.book Seite 83 Dienstag, 18. April 2006 11:17 11

J2EE-Archive installieren

5.2 J2EE-Archive installieren Geronimo bietet die Möglichkeit, nicht nur komplette Anwendungen in Form von EAR-Archiven, sondern auch einzelne Anwendungskomponenten in Form von J2EE-KomponentenArchiven zu installieren. Eine Trennung dieser Installationsarten erfolgt im Weiteren nur, falls unbedingt erforderlich. Die Installation von J2EE-Archiven lässt sich in folgende Bestandteile zerlegen: 쐌 Erstellung des Deployment-Plans 쐌 Kombination von Deployment-Plan und J2EE-Archiv Die Erstellung der Deployment-Pläne wird in Kapitel 5.3 gezeigt. Für die Kombination der Deployment-Pläne stehen im Fall der J2EE-Archive verschiedene Optionen zur Verfügung. Deployment-Pläne können entweder als externe Ressource benutzt oder innerhalb eines Archivs abgelegt werden. Die Plandateien selbst ähneln in ihrer Form und ihrem Inhalt den Standard-Deployment-Deskriptoren der J2EE-Spezifikationen. Für jede Komponentenart existiert ein definiertes XML-Format in Form eines XML-Schemas: 쐌 쐌 쐌 쐌 쐌 쐌

Webkomponenten (WAR) – geronimo-web.xsd EJB-Komponenten (JAR) – openejb-jar.xsd J2EE-Connectoren (RAR) – geronimo-connector_1_5.xsd Client-Komponenten (JAR) – geronimo-application-client.xsd Enterprise Application (EAR) – geronimo-application.xsd Geronimo Deployment-Pläne – geronimo-config-1.0.xsd

Diese Schematadateien befinden sich in der Standardinstallation im Unterverzeichnis /geronimo/schema. Innerhalb der Archive werden die Deployment-Pläne grundsätzlich in den standardisierten Metadatenverzeichnissen abgelegt. Die Deployment-Plan-Dateien müssen zur automatischen Er-

schnell + kompakt

83

3-935042-97-3_geronimo.book Seite 84 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

kennung durch die Geronimo-Deployment-Werkzeuge vorgegebene Namen tragen. Tabelle 5.1: Namen der Deployment-Pläne

Archiv

Deployment-Plan-Datei im Archiv

.war

WEB-INF/geronimo-web.xml

.ear

META-INF/geronimo-application.xml

.jar (EJB)

META-INF/openejb-jar.xml

.jar (Client)

META-INF/geronimo-client.xml

.rar

META-INF/geronimo-connector.xml

Zwischen den Deployment-Plänen von einfachen Modularchiven und Application-Archiven besteht ein enger Zusammenhang. Indem innerhalb eines EAR ein Deployment-Plan abgelegt wird, können Einträge in diesem Plan die Deployment-Pläne der eingebetteten Modularchive überschreiben. Zu diesem Zweck existiert das Element , um den Ablageort der überschreibenden Deployment-Pläne zu spezifizieren. Hier ein Beispiel des application.xml-Deskriptors eines EAR, in dem ein Connector als Resource Archive (RAR) gekapselt ist. .. .. <module> tranql-connector-1.1.rar ..

84

3-935042-97-3_geronimo.book Seite 85 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Unter META-INF/geronimo-connector.xml liegt innerhalb des RAR-Archivs die automatisch erkennbare Deployment-Plan-Datei. Durch folgenden Eintrag in der META-INF/geronimo-application.xml wird die alternative Datei mysql-plan.xml innerhalb des EAR-Archivs zum Einsatz gebracht. <module> tranql-connector-1.1.rar mysql-plan.xml

5.3 Erstellung von Deployment-Plänen Deployment-Pläne dienen der Installation und Konfiguration eines J2EE-Archivs in die Geronimo-Umgebung. Dabei wird auf eine deklarative Beschreibung der Umgebung zurückgegriffen. Um die Benutzung dieser speziellen Beschreibungssprachen zu erleichtern, wurden sie als XML-Dialekte, die durch Schemata definiert sind, angelegt. Die Dialekte enthalten Elemente verschiedener Namensräume. Diese XML Namespaces dienen der eindeutigen Kennzeichnung gleichartiger Elemente innerhalb verschiedener XML-Dokumente. Durch diese Konstruktion sind identische Umgebungsdeklarationen innerhalb der verschiedenen Dialekte auch gleich. Kompakt In allen Deployment-Plänen können die gleichen XML-Elementtypen verwendet werden.

schnell + kompakt

85

3-935042-97-3_geronimo.book Seite 86 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Die Deklaration einer Benutzerrolle, eines Datenbankzugangs oder einer Referenz auf eine EJB sind so z.B. für WAR- bzw. EJBJAR-Archive gleich. Dies ermöglicht hier auch eine ökonomische Beschreibung der Erstellung von Deployment-Plänen anhand der zu deklarierenden Umgebungsfeatures. Hinweis Eine einmal anhand eines Beispiels erlernte Deklaration kann auf andere Archivtypen, welche die gleichen Umgebungsfeatures benötigen, leicht durch Kopieren in den DeploymentPlan übertragen werden. Im Einzelnen kommen folgende Namensräume zum Einsatz. 쐌 sys Der Deployment-System-Namensraum erlaubt die Identifikation von Bibliotheken und zusätzlichen Services. http://geronimo.apache.org/xml/ns/deployment-1.0 쐌 connector Der Connector-Architektur-Namensraum erlaubt die Anbindung und Konfiguration der Zugänge zu Fremdsystemen wie Datenbanken, Messaging-Systemen und Enterprise Services. http://geronimo.apache.org/xml/ns/j2ee/connector-1.0 쐌 naming Der Geronimo Naming-System-Namensraum dient der Auszeichnung von Referenzen auf EJB und externe Ressourcen. Diese Arten von Referenzen werden über einen logischen Namensdienst deklariert. http://geronimo.apache.org/xml/ns/naming-1.0 쐌 ejb Der OpenEJB-Namensraum kapselt Elemente zur Konfiguration von EJB-Komponenten innerhalb des Containers OpenEJB. http://www.openejb.org/xml/ns/openejb-jar-2.0

86

3-935042-97-3_geronimo.book Seite 87 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

쐌 web Der Geronimo Webcontainer-Namensraum enthält die Standardelemente für die Konfiguration von Webkomponenten. http://geronimo.apache.org/xml/ns/j2ee/web-1.0 쐌 security Der Geronimo Security-Namensraum wird benutzt, um gemeinsame Elemente der Konfiguration eines Security Realm, der Basiseinheit des Sicherheitsmanagements von Anwendungen und Komponenten im Geronimo, durchzuführen. http://geronimo.apache.org/xml/ns/security-1.1 쐌 application Der Application-Namensraum bildet den Rahmen für die Beschreibung des Deployments von J2EE Application-Archiven. http://geronimo.apache.org/xml/ns/j2ee/application-1.0 쐌 client Der Application Client-Namensraum dient der Konfiguration des J2EE Application Client-Containers. http://geronimo.apache.org/xml/ns/j2ee/application-client-1.0 Obwohl der Geronimo Application Server es erlaubt, Deployment-Pläne zu erstellen, in denen auf die Deklaration dieser XML-Namespaces verzichtet wird, empfiehlt sich für die korrekte Bearbeitung durch XML-Werkzeuge eine Deklaration. Eine einführende Beschreibung der einzelnen Elemente erfolgt im Anschluss entlang der zu deklarierenden Features.

Auf Bibliotheken und Dienste verweisen Bei der Konfiguration von komponentenbasierten Anwendungen besteht die Notwendigkeit zur Deklaration gemeinsam genutzter Bibliotheken gegenüber dem Container. Dazu dient das Element dependency. Ein dependency-Eintrag erlaubt die Spezifikation einer gemeinsamen Bibliothek, die unterhalb des Verzeich-

schnell + kompakt

87

3-935042-97-3_geronimo.book Seite 88 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

nisses /geronimo/repository abgelegt sein muss. Zur Deklaration der Abhängigkeit existieren zwei Varianten. Mit dem Element uri kann der Pfad unterhalb des repositoryVerzeichnis direkt angegeben werden. Hier ein Beispiel des Deployment-Plans für ein RAR-Archiv, das die Datei /geronimo/repository/CRM/jars/ util-2.11.jar benutzt. <dependency> CRM/util/2.11/jar ..

Alternativ kann eine ausführliche Deklaration mithilfe einer Maven-artigen Syntax über die Elemente groupid, artefactId und version erfolgen. Hinweis Der Ausdruck bildet eine Referenz in das Repository. Der obige Deployment-Plan verändert sich bei Einsatz dieser Syntaxform entsprechend. <dependency> CRM <artefactid>util<artefactid> 2.11 ..

88

3-935042-97-3_geronimo.book Seite 89 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Mithilfe des Elements gbean kann ein J2EE-Archiv die Benutzung eines Geronimo-Service deklarieren. Dieser Dienst wird gemeinsam mit dem Archiv verteilt und gestartet. Die benutzten Klassen des Service müssen innerhalb des Servers verfügbar sein und mithilfe eines dependency-Elements für die Applikation freigegeben sein. Die spezielle Syntax innerhalb des gbean-Elements entspricht dem Deployment von Standard-GBean-Komponenten.

JCA Connectoren Die Java Connector-Architektur (JCA) definiert ein einheitliches Architekturmodell für die Interaktion von J2EE-Anwendungskomponenten, J2EE-Containern und Fremdsystemen. Die skalierbaren, multiusersicheren, transaktionalen Fremdsysteme, beispielsweise Datenbanken oder Transaktionsmonitore, werden verallgemeinert als Enterprise Services (EIS) bezeichnet. Zentrale Komponente in diesem Modell ist der Resource-Adapter, der in Form von Resource-Archiven (RAR) in jeden J2EE-Server installiert werden kann. Der Resource-Adapter ist eine EIS-spezifische Treibersoftware, die zwischen den Java-Schnittstellen der J2EEWelt und dem Enterprise Service vermittelt. Resource-Adapter stellen den J2EE-Komponenten häufig spezifische Java-Programmierschnittstellen zur Verfügung. Diese Schnittstellenobjekte, in der Spezifikation als Administered Objects bezeichnet, werden vom J2EE Application Server im Rahmen der JCA als anonym typisierte Objekte behandelt. Das Interaktionsmodell der JCA 1.5 erlaubt drei Treibervarianten, die als inbound, outbound bzw. combined bezeichnet werden können. Mit einem inbound-Adapter fließen Nachrichten vom Fremdsystem asynchron zu den J2EE-Komponenten. J2EE-Komponenten können Abfragen an ein Fremdsystem mit synchroner Antwort über einen outboundTreiber stellen. Ein Treiber, der beide Kommunikationsarten ermöglicht, wird als combined bezeichnet.

schnell + kompakt

89

3-935042-97-3_geronimo.book Seite 90 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Zur Installation und Konfiguration eines J2EE Connector in den Application Server dient ein connector-Element. Der Deployment-Plan für den J2EE Connector hat folgenden grundlegenden Aufbau: .. .. externalName <workmanager>.. .. .. .. ..

Innerhalb der connector-Deklaration muss mindestens ein resourceAdapter spezifiziert werden. Zusätzlich können noch adminobject-Einträge zur Spezifikation von Administered Objects für den Connector vorgenommen werden. Die Basiseinstellungen eines Resource-Adapters erfolgt über den Eintrag resourceadapter-instance. Neben einer Angabe des Elements name zur Identifikation des Treibers ist hier noch die Spezifikation eines workmanager in Form einer Referenz auf eine externe Ressource erforderlich.

90

3-935042-97-3_geronimo.book Seite 91 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Profitipp Innerhalb der Standardinstallation steht nur eine GBean als DefaultWorkManager zur Verfügung. Ein deklarierter resourceAdapter besitzt zusätzlich einen outbound-resourceadapter-Eintrag, wenn er als outbound oder combined Adapter genutzt werden kann. Die Struktur des obigen Deployment-Plans lässt sich unterhalb des Eintrags outbound-resourceadapter wie folgt verfeinern: javax.sql.DataSource MySqlDS jdbc:mysql://localhost:3306/jbossdb ..

Die Definition eines outbound-resourceadapter macht die Angabe connection-definition erforderlich. Neben der zwingenden Angabe des Typs der Resource Factory über das Tag connectionfactory-interface kann dann in einem connectiondefinitioninstance-Element die detaillierte Konfiguration des Fremdsystemzugangs erfolgen. Die spätere Referenzierung der Resource

schnell + kompakt

91

3-935042-97-3_geronimo.book Seite 92 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Factory in den J2EE-Komponenten ist hier durch einen eindeutigen Eintrag für das Element name zu unterstützen. Für die Deklaration einer externen Referenz zum Zugriff auf die Datenbank aus einer J2EE-Komponente lautet im obigen Beispiel der symbolische Name MySqlDS. Hinweis Zur flexiblen Konfiguration der konkreten Zugänge auf Fremdsysteme werden die config-property-setting-Elemente verwendet. Mit deren Attribut name wird der Name eines Konfigurationsparameters angegeben, der Inhalt des Elements spezifiziert den konkreten Konfigurationswert.

Referenzen auf externe Ressourcen Innerhalb des Geronimo Application Servers werden alle Ressourcen als GBeans repräsentiert. Die Spezifikation der benutzten Ressourcen einer J2EE-Komponente erfolgt daher im Deployment-Plan durch Anlegen von Referenzen zu GBeans. Die Ressourcen können in folgende Gruppen unterteilt werden: 쐌 JCA Resource Factories sind Zugangsobjekte, die von Treibern bereitgestellt werden und eines der Interfaces javax.resource. cci.ConnectionFactory, javax.sql.DataSource oder javax.jms. Connection-Factory implementieren. Sie geben den J2EE-Komponenten Zugriff auf Enterprise-Information-Systeme, relationale Datenbanken oder Messaging-Systeme. 쐌 Administered Objects sind Zusatzobjekte, die von Treibern externer Ressourcen für den Zugriff durch J2EE-Komponenten zur Verfügung gestellt werden. In der J2EE 1.3 werden z.B. Message-Destination-Objekte (Topic/Queue) auf diesem Weg bereitgestellt.

92

3-935042-97-3_geronimo.book Seite 93 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

쐌 JMS Message Destination Objects sind Quellen oder Senken für JMS-Messages. J2EE-Komponenten versenden JMSMessages an Senken und erhalten JMS-Messages aus Quellen. Die Nachrichten können entweder mit einem Point-to-PointMechanismus über ein Destination-Objekt vom Typ javax. jms.Queue oder mit einem Publish-Subscribe-Mechanismus über ein javax.jms.Topic übertragen werden. ObjectNameGroup Zur Erzeugung von gültigen Verweisen auf GBeans innerhalb eines Geronimo-Servers wird folgende Gruppierung von XMLElementen verwendet. .. <domain>geronimo.server <server>geronimo de/oio/KontoAnwendung < module> tranql-connector-1.1.rar JCAManagedConnectionFactory MySqlDS ..

Die gesamte Gruppierung wird als ObjectNameGroup bezeichnet. Sie bildet einen typisierten Zeiger auf ein im Geronimo Application Server installiertes GBean. Die verwendeten Elementnamen lehnen sich an die J2EE Management-Spezifikation (JSR-77) an. Das Element domain beschreibt den gleichnamigen Anteil des eindeutigen Namens einer GBean. Im Normalfall kann auf dieses

schnell + kompakt

93

3-935042-97-3_geronimo.book Seite 94 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Element verzichtet werden. Während des Deployment-Prozesses greift der Deployer auf den Namen der GBean zurück, welche den J2EE-Server bezeichnet, auf den installiert wird. Der Namensteil domain der zugehörigen J2EE-Server-GBean (Standarddeployment geronimo.server) wird dann als Wert verwendet. In gleicher Weise kann mit dem Element server ein weiterer Namensbestandteil der GBean-Referenz angegeben werden. Dieser Eintrag kann ebenfalls entfallen, dann wird hier beim Standarddeployment eine Einsetzung des entsprechenden Namensbestandteils der J2EE-Server-GBean des Zielservers vorgenommen. Der Wert lautet in diesem Fall geronimo. Um gleichnamige Ressourcen mehrfach innerhalb einer J2EE-Server-GBean installieren zu können, werden die Elemente application und module zur genaueren Identifikation der Ressourcen eingesetzt. Profitipp Durch Anpassen der configId im Deployment-Plan eines J2EEArchivs ändert sich die applicationID. So können mandantenspezifische Deployments identischer J2EE-Archive durchgeführt werden. Mit den Werten der jeweiligen Elemente kann auf die entsprechenden Elemente applicationId/configId bzw. JSR-77 ModuleId der Deployment-Einheit des Ziels der Referenz verwiesen werden. Im Eintrag type wird der JSR-77-Typ des referenzierten Objekts angegeben. Für Resource Factories ist der korrekte Wert JCAManagedConnectionFactory. Referenzen auf Administered Objects und Messages Destination Objects werden mit der Deklaration JCAAdminObject gekennzeichnet. Der eigentlich identifizierende Name der Ressource wird im Element name angegeben. Als Beispiel wird hier die Referenz auf die Resource Factory der im Abschnitt JCA Connectoren eingebundenen Datenbank gezeigt. Die Resource Factory wurde dort mit dem eindeutigen Namen MySqlDS ausgezeichnet.

94

3-935042-97-3_geronimo.book Seite 95 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Referenzen Referenzen auf Resource Factories werden aus drei Quellen konstruiert. Im Quellcode der J2EE-Komponente wird die Referenz durch folgende Zeile genutzt: .. connectionFactory = (javax.sql.DataSource) ctx.lookup("java:comp/env/jdbc/MyDB"); ..

Der passende Eintrag im J2EE Deployment-Deskriptor der Komponente lautet: .. jdbc/MyDB javax.sql.DataSource Container ..

Im Deployment-Plan wird die Referenz durch folgenden Eintrag innerhalb eines Elements auf die eingangs beschriebene Datenbank namens MySqlDS geleitet. .. jdbc/MyDB de/oio/KontoAnwendung <module>tranql-connector-1.1.rar

schnell + kompakt

95

3-935042-97-3_geronimo.book Seite 96 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

JCAManagedConnectionFactory MySqlDS ..

Zusammengehörige Einträge wurden durch Fettdruck markiert. Die Referenzierung von Administered Objects bzw. Message Destinations ist grundsätzlich ähnlich. Die Einbettung der korrekten ObjectNameGroup erfolgt in die jeweiligen Elemente resource-env-ref bzw. message-destination-ref. Hinweis Ein Spezialfall für eine Ressourcenreferenz ist die Referenz des EJB-Container-Persistenzmechanismus auf eine JDBCDatenquelle mit dem Element cmp-connection-factory. Die Referenzierung entspricht in ihrer Benutzung der Referenz auf eine Resource Factory und wird als Beispiel bei der Konfiguration von EJB demonstriert.

Referenzen auf EJB Die Referenzierung von EJB-Komponenten geschieht mit der gleichen Systematik wie bei den Ressourcen im vorangegangenen Abschnitt. Für die Bildung eines typisierten Zeigers bietet sich wieder eine ObjektNameGroup an. Zur Verwendung für EJB-Referenzen muss das Element type einem der folgenden Werte für die möglichen Schnittstellentypen entsprechen: StatefulSessionBean StatelessSessionBean EntityBean

96

3-935042-97-3_geronimo.book Seite 97 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Die korrekte Referenz entsteht dann analog des vorangehenden Abschnitts durch Verknüpfung der drei Ressourcenkomponenten Code, Deployment-Deskriptor und Deployment-Plan. .. home = (de.beispiel.AccountHome) ctx.lookup("java:comp/env/ejb/MyEB"); .. de.beispiel.AccountHome sb = home.create(..); ..

Der passende Eintrag im J2EE Deployment-Deskriptor der Komponente lautet: .. <ejb-ref> <ejb-ref-name>ejb/MyEB <ejb-ref-type>Entity de.beispiel.AccountHome de.beispiel.Account ..

Im Deployment-Plan wird die Referenz durch folgenden Eintrag innerhalb eines Elements <ejb-ref> auf eine Entity Bean des Typs de.beispiel.Account gesetzt. Die Entity Bean selbst wurde mit einer jar-Datei ejb-sb-sample.jar eines EAR mit der configId de/ beispiel/KontoAnwendung in den Application Server installiert. Im ejb-jar-Deployment-Deskriptor des Archivs ejb-sb-sample.jar wurde die Bean unter dem Namen Account registriert. Der Deployment-Plan verknüpft dann ähnlich den Ressourcereferenzen die Einträge der ausgehenden Komponente mit den Angaben application, module, name der Zielkomponente.

schnell + kompakt

97

3-935042-97-3_geronimo.book Seite 98 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

.. <ejb-ref> ejb/MyEB de/beispiel/KontoAnwendung <module>ejb-sb-sample.jar EntityBean Account ..

Für den Fall, dass der Zugriff auf die EJB über Local Interfaces erfolgt, ändert sich das einbettende Element im Deployment-Plan analog zum Deployment-Deskriptor von ejb-ref in ejb-localref. Die Erstellung von Referenzen kann im Fall des Zugriffs auf EJB innerhalb eines gemeinsamen Archivs ohne die Verwendung von ObjectNameGroups erfolgen. Das Ziel der Referenz wird innerhalb des Deployment-Plans stattdessen mit einem ejb-link-Eintrag definiert. Die Auflösung der Referenz geschieht dabei analog zur Verwendung eines ejblink in einem J2EE-Standarddeskriptor.

Konfiguration des EJB Containers Das Deployment von EJB verlangt beim Einsatz von Entity Beans, neben den in den vorangegangenen Abschnitten beschriebenen Deklarationen, spezielle Angaben zur Konfiguration des Persistenzmechanismus:

98

3-935042-97-3_geronimo.book Seite 99 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

쐌 Verbindung des Persistenzmechanismus mit einer konkreten Datenbank 쐌 Definition eines Mapping von Entity-Feldern auf Datenbankspalten Alle Angaben erfolgen innerhalb eines Elements openejb-jar. Die Datenbankanbindung des Persistenzmanagers stellt, wie bereits beschrieben, eine spezielle Referenz auf eine Resource Factory dar. Beispiel Anbindung der bereits in vorangehenden Beispielen unter dem Namen MySqlDS installierten Datenbank. <domain> geronimo.server <server>geronimo de/oio/KontoAnwendung <module> tranql-connector-1.1.rar JCAManagedConnectionFactory MySqlDS ..

schnell + kompakt

99

3-935042-97-3_geronimo.book Seite 100 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Die Beschreibung von EJB erfolgt analog dem ejb-jar.xml-Deskriptor mit den Elementen entity, session und message-driven. Die Kindelemente ejb-name und jndi-name dienen der Deklaration eindeutiger Namen für die Bean. Diese werden für Verweise auf die Bean zur Deployment- (ejb-name) bzw. Laufzeit (jndi-name) eingesetzt. Das Mapping von Feldern einer Entity Bean auf Tabellenspalten in der angebundenen Datenbank erfolgt innerhalb des Elements entity. Die Deklaration einer Entity Bean-Buchung, die auf eine Tabelle Transaktionen gemappt wird, hat dann folgenden Aufbau. .. <entity> <ejb-name>Buchung TRANSAKTIONEN id ID date DATE ... ..

Der Name der Tabelle wird über ein Element table-name gesetzt, das Mapping erfolgt mit jeweils einem cmp-field-mapping für jedes Feld der Entity Bean. Ein Mapping besteht minimal aus dem Namen des Entity Bean-Felds (cmp-field-name) und der entsprechenden Datenbankspalte (table-column).

100

3-935042-97-3_geronimo.book Seite 101 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

Hinweis Optional ist die Angabe der Typen von Entity-Feld und Datenbankspalte durch die zusätzlichen Einträge cmp-field-class und sql-type. Die Angaben entsprechen dabei dem vollständigen Klassennamen des Felds bzw. dem Namen der Typkonstante der Spalte in der Klasse java.sql.Types.

Konfiguration des Webcontainers Webapplikationen, die innerhalb eines EAR-Archivs installiert werden, können im Deployment-Deskriptor application.xml die Wurzel ihres Applikationskontexts deklarieren. Der Aufruf von Elementen der installierten Anwendung erfolgt dann über eine URL, die folgendem Muster genügt: http://server/port/contextwurzel/contextpfad Geronimo ermöglicht die zusätzliche Konfiguration der Kontextwurzel über das Element context-root innerhalb eines Webcontainer-Deployment-Plans. Dieses Element wird in gleicher Art ausgewertet wie ein Eintrag in der application.xml und ist im Falle des Fehlens dieses Eintrags zwingend erforderlich. Falls beide Einträge gesetzt sind, besitzt der Eintrag in der application.xml Priorität. <web-app .. configId="MyWeb"> /beispiel ..

Die Webanwendung ist dann unter folgender URL erreichbar: http://server/port/beispiel

schnell + kompakt

101

3-935042-97-3_geronimo.book Seite 102 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

Zur Konfiguration des Verhaltens des Classloader innerhalb des Geronimo-Webcontainers erlaubt das Element context-priorityclassloader das Ein- und Ausschalten der J2EE-Standardkonformität. Für den Fall des Ausschaltens nutzt Geronimo die Parentclassloader zum Laden benötigter Klassen, bevor er innerhalb der Webarchive die Klassen zu lokalisieren versucht. <web-app .. configId="MyWeb/commonLoader"> false ..

Der Webcontainer ist ein Geronimo Service. Für den Release 1.0 existieren mit Jetty und Tomcat zwei Varianten J2EE-kompatibler Webcontainer, für die innerhalb eines Deployment-Plans containerspezifische Konfigurationseinstellungen durch das Element container-config möglich sind. Innerhalb einer container-config können über config-param-Einträge konkrete Konfigurationsparameter an den Webcontainer übergeben werden. Der Inhalt eines config-param-Elements gibt den Wert eines Konfigurationsparameters an. Mit dem Attribut name wird der Name des Konfigurationsparameters definiert.

Sichere Anwendungen Zur Beschreibung des Geronimo-Sicherheitssystems werden hier einige allgemeine Begriffe in Zusammenhang mit der Sicherheit von Anwendungen verwendet. Aufgrund ihrer häufigen, teilweise widersprüchlichen Verwendung in anderen Kontexten sollen sie hier kurz angeführt und in ihrer Bedeutung für die Nutzung im Geronimo Application Server geklärt werden.

102

3-935042-97-3_geronimo.book Seite 103 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

쐌 Ein Principal ist eine gegenüber einem System authentifizierte Identität. Ein Principal kann neben der Identität weitere Attribute wie z.B. Gruppen- oder Lagezugehörigkeiten besitzen, diese werden als Principal-Merkmale bezeichnet. Zum Zwecke der Verwaltung von Identitätsmerkmalen des Principal sowie der Authentifizierung von Principals werden spezielle Dienste – die Identity Provider – eingesetzt. Die Zuordnung der weiteren Principal-Merkmale erfolgt durch weitere Dienste – die Attribute Provider. Zur Zuordnung von PrincipalMerkmalen nur auf Basis der Identität eines Principal wird eine spezielle Vertrauensbeziehung zwischen Identity Provider und Attribute Provider benötigt, über deren Zustandekommen vom Applikationsserver keine weiteren Annahmen gemacht werden. Zur Laufzeit wird ein Principal als ein Objekt vom Typ java.security.Principal repräsentiert. 쐌 Eine Login-Domäne ist für Geronimo eine Einheit von Identity und Attribute Provider, welche es dem Applikationsserver ermöglicht, einen Principal zu authentifizieren und mit Merkmalen auszustatten. Beispiele für eine Login-Domäne können eine Datenbank oder ein LDAP-System zur Authentifizierung mit Username und Passwort sowie einer Zuordnung von Rollen, Berechtigungen oder Schlüsseln zum Principal sein. Zu jeder Login-Domäne wird dazu ein spezielles Principal-Objekt angelegt. Gemäß der Java Authentication and Authorization Specification (JAAS) wird eine Login-Domäne im Geronimo Application Server durch ein Login-Modul repräsentiert. 쐌 Ein Security Realm konfiguriert und sichert eine anwendungsspezifische Authentifizierung und ist der Eintrittspunkt zu den Login-Domänen. Sie setzen dabei auf ein vielseitig einsetzbares Gerüst, in das verschiedene Authentifizierungsprotokolle und deren konkrete Konfigurationen zur anwendungsspezifischen Feineinstellung eingeklinkt werden können. Ein Realm definiert also eine Bewertung der Authentifizierung

schnell + kompakt

103

3-935042-97-3_geronimo.book Seite 104 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

eines Satzes von Login-Domänen bezüglich einer Anwendung. Ein Realm kann z.B. mit einer Datenbank- und einer LDAP-Login-Domäne konfiguriert werden und die Authentifizierung gegenüber beiden Dömanen als zwingend für die Anwendungsauthentifizierung definieren. In einem Deployment-Plan kann eine Zuweisung von abstrakten Rollen, welche in den J2EE Deployment-Deskriptoren containerunabhängig definiert wurden, zu konkreten Rollen eines installierten Security Realms durchgeführt werden. Dazu dient das Element security. <security> <default-principal> .. ..

Innerhalb des Elements security werden sämtliche Mappings definiert. Mit dem Kindelement role-mappings werden den abstrakten Rollen einer J2EE-Komponente oder Anwendung konkrete Principal-Objekte eines Realms zugeordnet. Das spezielle Kindelement für die Definition eines Standardbenutzers ist defaultPrincipal. Folgende Attribute erlauben eine Feinkonfiguration des Verhaltens des Security-Systems. Die Einträge in den role-mappings weisen den Rollendefinitionen der unabhängigen Anwendungskomponenten konkrete Principals des für die Anwendung zuständigen Realms zu. Das heißt, wenn eine Ressource der Anwendung nur bestimmten Rollen im Standard-Deployment-Deskriptor Zugriff gewährt, dann be-

104

3-935042-97-3_geronimo.book Seite 105 Dienstag, 18. April 2006 11:17 11

Erstellung von Deployment-Plänen

stimmt das Role-Mapping die echten Benutzer des Applikationsservers, welche die entsprechenden Zugriffsrechte erhalten. .. <principal name="systemAdmin" designated-run-as="true" class="org.apache.geronimo. security.realm.providers. GeronimoGroupPrincipal"/> ..

Pro Rollendefinition in einem Standarddeskriptor existiert unterhalb des role-mapping ein Eintrag role mit einem passenden nameAttribut. Die role kapselt die Zuordnung sämtlicher gültiger Principals durch einfache Deklaration des Principal innerhalb des Elements. Zur Deklaration eines Principal existieren mit den Elementen principal, login-domain-principal, realm-principal drei ver-

schiedene Ausprägungsvarianten. Die letzteren beiden dienen dabei der Assoziation einer Identität mit einem Satz ihrer Identity Provider. Dies erlaubt eine stärkere Differenzierung von externen Identitäten gegenüber der konfigurierten Anwendung. Durch Verwendung eines principal-Eintrags beschreibt man das Principal-Objekt durch dessen Attribute class und name. Die An-

schnell + kompakt

105

3-935042-97-3_geronimo.book Seite 106 Dienstag, 18. April 2006 11:17 11

5 – Arbeiten mit dem Server

gaben definieren die konkrete Implementierungsklasse und den Namen der Principal-Objekte (Rückgabewert der Methode getName()) des Principal. Außerdem kann das boolesche Attribut designated-run-as sinnvoll innerhalb eines role-mapping einmal auf true gesetzt werden. Der entsprechende Principal wird dann als Identität der verwiesenen Anwendungsrolle benutzt. Eine erste Erweiterung des principal-Elements bietet der Eintrag als login-domain-principal. Mit diesem kann eine Verknüpfung des Principal an eine Login-Domäne über das zusätzliche Pflichtattribut domain-name erfolgen. Die anderen Einträge wirken wie in einem einfachen principal-Eintrag auf das Sicherheitsmanagement der Anwendung. Die Definition eines Standardbenutzers durch die Einträge im Element defaultPrincipal beschreiben die Einstellungen für den anonymen Zugriff auf Ressourcen einer Anwendungskomponente. .. <default-principal> <principal name="unbekannt" class="org.apache.geronimo.security. realm.providers.GeronimoUserPrincipal"/> ..

106

3-935042-97-3_geronimo.book Seite 107 Dienstag, 18. April 2006 11:17 11

Stichwortverzeichnis A

J

applicationId 94 artifactId 34, 35, 38, 64

Jetty 8, 10, 12, 15, 18, 54, 55, 56, 57, 58, 62, 102 JMX 13, 36, 42, 45, 47 JSR-77 93, 94 JSR-88 11, 76, 77, 78

C car 28, 29, 45, 47, 48, 54, 55, 56, 70, 73 config.xml 23, 42, 43, 44, 47, 50, 51, 52, 54, 55, 56 configId 38, 70, 85, 88, 90, 94, 97, 101, 102 ConfigStore 27, 28, 29, 30, 31, 41, 42, 44, 45, 51, 52, 56, 79, 82 Configuration Builder 30, 31

D Deployment Deskriptor 63, 68, 72, 95, 97, 98 Deployment-Plan 18, 31, 32, 37, 52, 66, 67, 68, 74, 76, 79, 83, 86, 88, 90, 92, 95, 97, 102, 104

K Konfiguration 11, 17, 27, 30, 35, 41, 50, 51, 52, 55, 79, 82

M Maven 32, 34, 76, 78, 88 Module 78 Module Builder 30, 31 ModuleID 79

O ObjectName 96 ObjectNameGroup 93 OpenEJB 8, 13, 86 openejb-jar.xml 84

G GBean 25, 26, 27, 32, 36, 45, 52, 71, 89, 91, 93 geronimo-application.xml 68, 69, 74, 84, 85 geronimo-client.xml 84 geronimo-connector.xml 84 geronimo-web.xml 84 groupId 34, 38, 64

R Repository 18, 34, 37, 38, 51, 64, 65, 88

S Standardbenutzer 20, 23, 50, 104, 106

T H Hot Deployment 10, 17, 76, 77

schnell + kompakt

Target 79 TargetModuleID 79 Tomcat 10, 12, 15, 18, 23, 28, 31, 54, 55, 56, 57, 58, 59, 102

107

3-935042-97-3_geronimo.book Seite 108 Dienstag, 18. April 2006 11:17 11

3-935042-97-3_geronimo.book Seite 109 Dienstag, 18. April 2006 11:17 11

Die Autoren Kristian Köhler ist bei der OIO als Berater, Entwickler und Trainer im Bereich Java und XML tätig. Er ist Experte für Design und Entwicklung von J2EE Anwendungen. Seine Hauptinteressen gelten den J2EE Application Servern sowie den damit verbundenen Open Source Lösungen. Er ist Autor verschiedener Fachartikel und Sprecher auf Fachkonferenzen. Christian Dedek ist bei der OIO als Berater und Architekt in der objektorierten Softwareentwicklung mit Java tätig. Einer seiner Interessenschwerpunkt im Bereich Enterprise Java ist die Realisierung unternehmenskritischer Anwendungen und Prozesse mit ihren besonderen Qualitätsanforderungen. Seine dabei gesammelten Erfahrungen gibt gern er als Trainer und Autor weiter. Orientation in Objects ist das Competence Center für Softwareentwicklung mit Java und XML. Neue Technologien und Standards werden von OIO bereits während der Entstehung auf ihr Potential und ihre Marktfähigkeit geprüft. Die OIO-Akademie bietet neben umfassenden Java- und XML-Seminaren auch Weiterbildungsberatung und Coaching an. OIO berät unabhängig und herstellerneutral im Bereich objektorientierter Softwareentwicklung etwa mit Reviews, Machbarkeitsstudien oder Einsatzkonzepten für Open Source Server. Ihre Projekte unterstützt OIO mit Softwareingenieuren oder übernimmt die schlüsselfertige Realisierung. Schwerpunkte sind hierbei kritische Projekte und Softwareentwicklung mit Open-Source-basierten Werkzeugen.

schnell + kompakt

109