Jetty und OSGi

Wie man Enterprise-Java mit den Vorzügen von Modularität verbindet

Marc Teufel
©Shutterstock/RachelArnott

Enterprise-OSGi-Anwendungen werden nicht selten als Webanwendungen umgesetzt. Damit diese Kombination gelingt, muss der verwendete Servlet Container in der Lage sein, auch im Umfeld von OSGi betrieben werden zu können. Wie verbindet man Jetty mit OSGi und welche Möglichkeiten gibt es, Webanwendungen zu betreiben?

Jetty als Alternative zu Apache Tomcat bietet erstaunlich viele Möglichkeiten. So kann man einen Jetty-Server als HTTP-Server betreiben. Anders herum existieren in der Jetty-Distribution Bibliotheken, um HTTP-Clients zu realisieren. Die Entwicklung und der Betrieb von REST-

und neuerdings auch WebSocket-Anwendungen gehören ebenso ins Portfolio. Über Jetty im Allgemeinen und WebSocket im Besonderen haben wir in vergangenen Ausgaben des Eclipse Magazins bereits ausführlich berichtet [1]. Auch wenn alle genannten Möglichkeiten sinnvolle Funktionen darstellen und man

sich das Schreiben moderner Webanwendungen ohne REST und WebSocket kaum noch vorstellen kann, ist und bleibt Jetty in erster Linie jedoch ein Servlet Container zum Betrieb von Webanwendungen. In der aktuellen Version 9.1 werden alle hierfür relevanten Protokolle unterstützt: HTTP/1.1, RFC2616, Web

Socket, SPDY und natürlich Servlet 3.0/3.1 und JSP 2.2.

Vielfältige Einsatzmöglichkeiten …

Ein Jetty-Server kann auf unterschiedliche Weise betrieben werden. Der klassische Betriebsmodus ist zugleich auch der einfachste: Man lädt die Jetty-Distribution herunter, installiert diese und betreibt den Server anschließend auf ähnliche Weise wie Apache Tomcat. Über ein Shellscript im bin-Order wird der Server gestartet und gestoppt, und über die Konfigurationsdateien (verteilt über die ganze Distribution) wird die Umgebung eingerichtet. Analog zu Apache Tomcat gibt es ein webapps-Verzeichnis, in das Webanwendungen (.war) deployt werden können. Wer Maven einsetzt, kann Jetty direkt in sein Projekt einbinden und während der Entwicklung bei Bedarf einen eingebetteten Jetty-Server starten, um die gerade in Entwicklung befindliche Webanwendung zu testen oder zu debuggen. Selbstverständlich lassen sich die Jetty-Bibliotheken auch in eigene Softwareprojekte einbinden und Jetty komplett eingebettet betreiben. Über das bereitgestellte API lassen sich Serverinstanzen konfigurieren, hochfahren, programmatisch Servlet-Kontexte generieren und Servlets oder ganze Webanwendungen bereitstellen. Die Möglichkeiten gehen hier so weit, dass man in der Lage ist, mit nur einer JAR-Datei, die ausgeliefert wird, eine komplette Webanwendung bereitstellen zu können.

Aufmacherbild: Abstract Network Design von Shutterstock / Urheberrecht: RachelArnott

[ header = Seite 2: … bis hin zu OSGi ]

… bis hin zu OSGi

Jüngst, und damit sind wir beim Thema dieses Artikels angekommen, scheint ein weiterer Jetty-Betriebsmodus immer populärer zu werden: Jetty in OSGi. Im Umfeld der so genannten Enterprise-OSGi-Anwendungen (früher sprach man hier auch von „Server-side OSGi“) geht es darum, Enterprise-Java mit den Vorzügen der Modularität von OSGi zu verbinden. Das Frontend oder UI solcher Anwendungen besteht dabei meist aus einer Webanwendung. Um eine solche bereitzustellen, muss der dahinterliegende Servlet Container eben auch in der Lage sein, sich in eine OSGi Runtime wie beispielsweise Eclipse Equinox [2] oder Apache Felix [3] einbringen zu lassen. Dieser Artikel soll zeigen, wie man ausgehend von einer frischen Equinox-Installation die Umgebung so konfiguriert, dass Jetty 9 in dieser laufen kann. Außerdem soll gezeigt werden, wie man eine einfache Webanwendung, die als .war-Datei vorliegt, zu einem OSGi Bundle macht und welche Möglichkeiten es gibt, diese innerhalb der OSGi-Umgebung bereitzustellen. Für den Betrieb von Webanwendungen im Umfeld von Enterprise OSGi gibt es bereits eine Vielzahl von vorkonfigurierten OSGi-Laufzeitumgebungen: Egal, ob Sie auf Apache Felix, Eclipse Equinox oder auf Server wie Virgo zurückgreifen, meistens sind Bundles für den Betrieb von Servlet-basierten Webanwendungen bereits enthalten, und nicht selten basieren diese auf Jetty. Besorgt man sich eine aktuelle Equinox-Distribution, ist neben der eigentlichen OSGi-Plattform eine Vielzahl weiterer Bundles an Bord. Jetty ist auch dabei, allerdings in etwas älterer Version. Da wir mit der aktuellen Version 9 von Jetty arbeiten wollen, ist es also sinnvoll, sich zunächst die neueste Jetty-Version entweder über Maven zu besorgen oder die Standarddistribution [4] herunterzuladen, in der die meisten der benötigten Dateien enthalten sind.

Vorbereitungen

Ziel des Artikels ist es, quasi „from scratch“ zu beschreiben, wie man Jetty mit OSGi zusammenbringen kann. Deswegen und vor allem, um den Überblick über die verwendeten Bundles zu behalten, benutzen wir möglichst wenige Bundles aus der Equinox-Distribution selbst. Eigentlich benötigen wir zu Beginn lediglich das org.eclipse.osgi-Bundle, das sich im Plug-ins-Verzeichnis der Equinox-Distribution findet. Um mit der OSGi-Umgebung interagieren zu können, etwa um zu sehen, welche Bundles installiert sind, in welchem Status sie sich befinden usw., bietet sich die Verwendung der OSGi-Konsole an. Diese wurde früher mit folgendem Aufruf gestartet:

java –jar org.eclipse.osgi_3.9.1.v20130814-1242.jar –console 

Leider funktioniert dieser Aufruf in den neuesten Equinox-Versionen so nicht mehr, da die Konsole modernisiert wurde. Es gibt nun zwei Möglichkeiten, um die Konsole zu starten: Entweder man sorgt dafür, dass neben der bereits genannten JAR-Datei noch mindestens vier weitere Bundles (Kasten: „OSGi Bundles starten“) gestartet werden, oder man benutzt einfach den Schalter

osgi.console.enable.builtin=true 

um die (nach wie vor enthaltene) alte Shell zu reaktivieren. Legen Sie sich bitte ein neues, leeres Verzeichnis an, kopieren Sie das org.eclipse.osgi Bundle aus dem Plug-ins-Verzeichnis in diesen neuen Ordner und starten Sie die Konsole mit folgendem Aufruf:

 java –Dosgi.console.enable.builtin=true –jar org.eclipse.osgi_3.9.1.v20130814-1242.jar –console 

Wenn man in der Konsole jetzt den Befehl ss zur Auflistung aller Bundles in der aktuell laufenden OSGi-Umgebung ausführt, stellt man fest, dass nur das soeben gestartete org.eclipse.osgi Bundle läuft. Sauberer und übersichtlicher geht es eigentlich nicht. So kann es jetzt auch schon mit der Jetty-Integration losgehen. Jetty macht uns das Einbinden in OSGi sehr einfach: Grundsätzlich sind nämlich alle JAR-Dateien, die das Projekt ausliefert, gleichzeitig auch OSGi Bundles, da sie entsprechende Manifesteinträge vorweisen. Um nun ein minimales Jetty-Set-up zu erhalten, sind mindestens die in Tabelle 1 gelisteten JAR-Dateien aus der Jetty-Distribution in den Ordner zu legen, in dem auch das org.eclipse.osgi Bundle liegt. Die nachfolgende Tabelle zeigt die benötigten JAR-Dateien für ein minimales Jetty-OSGi-Set-up.

Jar

Bundle Symbolic Name

Quelle

jetty-util

org.eclipse.jetty.util

Jetty-Distribution

jetty-http

org.eclipse.jetty.http

Jetty-Distribution

jetty-io

org.eclipse.jetty.io

Jetty-Distribution

jetty-security

org.eclipse.jetty.security

Jetty-Distribution

jetty-server

org.eclipse.jetty.server

Jetty-Distribution

jetty-servlet

org.eclipse.jetty.servlet

Jetty-Distribution

jetty-webapps

org.eclipse.jetty.webapp

Jetty-Distribution

jetty-deploy

org.eclipse.jetty.deploy

Jetty-Distribution

jetty-xml

org.eclipse.jetty.xml

Jetty-Distribution

servlet-api-3.0

javax.servlet

Jetty-Distribution

org.eclipse.osgi.util

org.eclipse.osgi.util

Equinox-Distribution

org.eclipse.osgi.services

org.eclipse.osgi.services

Equinox-Distribution

Leider reicht ein Neustarten der OSGi Runtime nicht aus, damit die Bundles automatisch erkannt werden. Stattdessen müssen die Bundles entweder per Parameter beim Starten der OSGi-Umgebung mit angegeben oder über eine Konfigurationsdatei bekannt gemacht werden. Der Kasten „OSGi Bundles starten“ zeigt am Beispiel der neuen OSGi-Konsole, wie man Bundles bekannt macht und automatisch startet. Die gleiche Vorgehensweise gilt auch für die Jetty-Bundles. Listing 1 zeigt eine beispielhafte config.ini, die dafür sorgt, dass die entsprechenden Jetty-Bundles gestartet werden.

osgi.bundles.defaultStartLevel=4 osgi.bundles=jetty-deploy-9.0.6.v20130930.jar@start, jetty-http-9.0.6.v20130930.jar@start, jetty-io-9.0.6.v20130930.jar@start, jetty-osgi-boot-9.0.6.v20130930.jar@start, jetty-security-9.0.6.v20130930.jar@start, jetty-servlet-9.0.6.v20130930.jar@start, jetty-server-9.0.6.v20130930.jar@start, jetty-util-9.0.6.v20130930.jar@start, jetty-webapp-9.0.6.v20130930.jar@start, jetty-xml-9.0.6.v20130930.jar@start, org.eclipse.osgi.services_3.3.100.v20130513-1956.jar@start, org.eclipse.osgi.util_3.2.300.v20130513-1956.jar@start, servlet-api-3.0.jar@start osgi.noShutdown=true eclipse.ignoreApp=true 

In Abbildung 1 sieht man schließlich das Ergebnis in der OSGi-Konsole. Die Jetty-Plug-ins wurden erkannt und befinden sich im Status ACTIVE. Das bedeutet: Jetty in OSGi ist grundsätzlich gestartet und einsatzbereit.

Abb. 1: OSGi Framework und Jetty-Bundles sind geladen und gestartet

[ header = Seite 3: Jetty in OSGi booten ]

Jetty in OSGi booten

Jedoch reicht es auch nicht aus, die Jetty-Bundles lediglich in der OSGi-Umgebung zu installieren und zu starten. Wichtige Aufgaben wie die Konfiguration so genannter Konnektoren, die eine Netzwerkkommunikation mit Jetty (etwa über HTTP) überhaupt erst ermöglichen, das Einrichten von Ports, Data Source Connection Pools, Security, Kontextpfade und schließlich das Booten der Jetty-Serverinstanz selbst müssen natürlich auch im Umfeld von OSGi erfolgen. Die Jetty-Entwickler stellen – speziell für OSGi – hierfür ein zusätzliches Bundle bereit, das nicht nur die Konfiguration eines Jetty-Servers übernimmt, sondern diesen auch startet. Leider ist dieses Bundle nicht in der Jetty-Distribution enthalten, stattdessen kann es bei Maven [5] bezogen werden. Eine kurze Beschreibung zu diesem Bundle, Downloadmöglichkeit inklusive, findet sich auch in der Jetty-Dokumentation unter [6]. Damit die Jetty-Instanz von dem Jetty-OSGi-Boot-Bundle überhaupt hochgefahren werden kann, sind drei Umgebungsvariablen von Bedeutung.

Die Umgebungsvariable jetty.port gibt den Standardport für den HTTP-Konnektor vor. Ist diese Variable nicht gesetzt, wird in der Standardeinstellung hier Port 8080 verwendet. jetty.port ist somit eine optionale Umgebungsvariable. Anders verhält es sich mit jetty.home und jetty.home.bundle. Eine dieser beiden Umgebungsvariablen muss gesetzt sein. Wie zu Beginn dieses Abschnitts bereits erwähnt, setzt sich eine Jetty-Instanz aus mehreren Bausteinen zusammen, die in unterschiedlichen Konfigurationsdateien beschrieben werden und zusammen eine Jetty-Instanz bilden. Von besonderer Bedeutung sind dabei die Dateien:

  • jetty.xml
  • jetty-selector.xml
  • jetty-deployer.xml

[ header = Seite 4: Jetty in OSGi booten Teil 2 ]

Die wichtigste Datei ist sicher jetty.xml, denn in ihr wird der eigentliche Server vom Typ org.eclipse.jetty.server.Server definiert und mit einigen elementaren Einstellungen, zum Beispiel dem Handler-System oder wichtigen HTTP-Optionen, versehen. In der Datei jetty-selector.xml werden die Konnektoren konfiguriert, damit die Außenwelt auch Kontakt zu Jetty aufnehmen kann. Da mit Jetty vorrangig Webanwendungen betrieben werden, wird hier natürlich ein HTTP-basierter Konnektor konfiguriert. Weiterhin findet sich in dieser Datei auch die Umgebungsvariable jetty.port wieder, die – sofern vorhanden – ausgelesen und übernommen wird oder eben auf den Standardwert 8080 zurückgreift. In der Datei jetty-deployer.xml schließlich wird der Serverinstanz mitgeteilt, wie Webanwendungen zu deployen sind. Da wir im OSGi-Umfeld keine WAR-Dateien deployen, sondern unsere Webanwendungen ebenfalls in Form von OSGi Bundles in die Laufzeitumgebung einbringen, ist hier natürlich ein Deployer erforderlich, der mit JAR-Dateien umgehen kann. Vorlagen für diese Konfigurationsdateien finden sich im Übrigen im etc-Verzeichnis der Jetty-Distribution. Das Jetty-OSGi-Boot-Bundle enthält diese Konfigurationsdateien ebenfalls, allerdings müssen sie sich nicht zwangsläufig in einem Bundle befinden, sondern können auch irgendwo im Filesystem liegen. Hier kommt nun die Umgebungsvariable jetty.home ins Spiel. Über diese kann man nämlich festlegen, wo im Filesystem sich die genannten Konfigurationsdateien befinden. Will man die Einstellungen dagegen lieber in einem OSGi Bundle vorhalten, verwendet man die Variable jetty.home.bundle. Dabei verweist diese auf den Namen des Bundles (Bundle Symbolic Name), das die Konfiguration enthält. Wichtig dabei ist zu beachten, dass sich im Wurzelverzeichnis des Bundles ein Unterverzeichnis jettyhome/etc befinden muss, in dem die eigentlichen Konfigurationsdateien stehen. Im Jetty-OSGi-Boot-Plug-in findet sich ein Beispiel mit entsprechenden Standardeinstellungen.

Um eine Jetty-Instanz nun mit den Standardeinstellungen aus dem jetty-osgi-boot Bundle, aber dem vom Standard abweichenden Port 8888 hochzufahren, ist es jetzt eigentlich nur noch erforderlich, das jetty-osgi-boot Bundle ebenfalls ins Plug-in-Verzeichnis aufzunehmen, die Datei config.ini (Listing 1) wie folgt zu erweitern und die Equinox-Umgebung neu zu starten:

... servlet-api-3.0.jar@start, jetty-osgi-boot-9.0.6.v20130930.jar@start jetty.home.bundle=org.eclipse.jetty.osgi.boot jetty.port=8888 ... 

Damit wären die grundlegenden Arbeiten zum Einrichten von Jetty in OSGi auch schon erledigt. Öffnet man jetzt einen Browser und zeigt damit auf Port 8888, wird man sehen können, dass der Jetty-Server zwar läuft – aber im Moment noch ziemlich nutzlos ist. Auf dem Server ist ja noch keinerlei Webanwendung deployt.

[ header = Seite 5: OSGi Bundles starten ]

OSGi Bundles starten

Um einer Equinox-basierten OSGi-Laufzeitumgebung Bundles bekannt zu machen und zu starten, gibt es grundsätzlich zwei Wege: Entweder man verwendet den Parameter -Dosgi.bundles, um bereits beim Starten der OSGi Runtime die Bundles zu definieren; oder man verlagert die Konfiguration in die Datei config.ini, die man schließlich in ein Verzeichnis mit dem Namen configuration ablegt. Beim Starten einer Equinox-Umgebung wird in der Standardeinstellung immer in diesem Verzeichnis, sofern vorhanden, geprüft, ob sich eine Datei config.ini mit Einstellungen für die zu startende OSGi-Instanz darin befindet. Das gleiche Verzeichnis wird im Übrigen auch für die Ablage der Log-Dateien verwendet. Im Folgenden soll am Beispiel der neuen OSGi-Konsole gezeigt werden, wie man dessen Bundles entweder direkt über die Kommandozeile oder über die Datei config.ini bekannt macht. Folgende Bundles aus der Equinox-Distribution werden hierzu mindestens benötigt:

  • org.eclipse.equinox.console
  • org.apache.felix.gogo.command
  • org.apache.felix.gogo.runtime
  • org.apache.felix.gogo.shell

Möglichkeit 1: Kommandozeile

java -Dosgi.bundles=org.eclipse.equinox.console_<version>.jar@start,<die anderen Bundles…> -jar org.eclipse.osgi_<version>.jar –console
strong>

Möglichkeit 2: config.ini

Neues Unterverzeichnis configuration anlegen, darin neue leere Datei config.ini mit folgendem Inhalt:
osgi.bundles=org.eclipse.equinox.console_1.0.100.v20130429-0953@start,
org.apache.felix.gogo.command_0.10.0.v201209301215@start,
org.apache.felix.gogo.runtime_0.10.0.v201209301036@start,
org.apache.felix.gogo.shell_0.10.0.v201212101605@start

Anschließend OSGi Framework wie folgt starten:

java -jar org.eclipse.osgi_<version>.jar –console

[ header = Seite 6: Webanwendungen bereitstellen ]

Webanwendungen bereitstellen

Damit der OSGi Container die Klassen der Webanwendung überhaupt findet (und weil sich diese in einer klassischen Java-Webanwendung im Ordner WEB-INF/classes befinden) müssen diese dem Bundle Classloader mithilfe des Parameters Bundle-ClassPath mitgeteilt werden. Andernfalls werden die Servlets in der Webanwendung nicht erkannt. Der Parameter Web-ContextPath legt den Kontextpfad der Anwendung fest, ist allerdings optional. Lässt man diesen Parameter weg, wird der Name des Bundles automatisch als Kontextpfad verwendet. Es gibt eine ganze Reihe weiterer Parameter für die Manifestdatei, mit der Webanwendungen konfiguriert werden können. Viele sind vor allem dann interessant, wenn man, wie zu Beginn dieses Abschnitts angesprochen, die üblichen Pfade der Entwicklung von Webanwendungen verlässt.

So ist man beispielsweise nicht mehr gezwungen, seine Servlets in WEB-INF/classes zu hinterlegen, sondern kann sie ganz OSGi-typisch einfach im Root des Bundles ablegen. Der Parameter Bundle-ClassPath könnte in diesem Fall entfallen. Wenn man (wie das Beispiel in Listing 1 zeigt) das Servlet API in der Version 3.0 eingebunden hat, kann man unter Umständen auch gänzlich auf die web.xml verzichten, da Servlets hier auch über entsprechende Annotationen definiert werden können. Eine etwaige web.xml, die sich im Ordner WEB-INF befindet, wird jedoch trotzdem erkannt und verarbeitet. Möchte man die web.xml an eine andere Stelle innerhalb des Bundles verlagern, verwendet man den Parameter Jetty-WebXmlFilePathim Manifest. Hiermit kann ein ganz individueller Ablageort für die Datei web.xml innerhalb des Bundles festgelegt werden.

[ header = Seite 7: Webanwendungen bereitstellen Teil 2 ]

Sehr häufig kommt es vor, dass eine Webanwendung zusätzliche Ressourcen verwendet, zum Beispiel HTML-Dateien, Grafiken und Sounds. Diese dürfen natürlich auch in einem Webanwendungs-Bundle enthalten sein, müssen in der Standardeinstellung jedoch auf oberster Ebene, also im Root des Bundles liegen. Wer hierfür einen speziellen Unterordner definieren möchte, verwendet den Manifestparameter Jetty-WarFolderPath. In Tabelle 2 sind die wichtigsten Manifestparameter für die Bereitstellung von Webanwendungen in Jetty und OSGi zusammengefasst.

Parameter

Beschreibung

Bundle-ClassPath

Gibt ein Verzeichnis innerhalb des Bundles an, in dem der Bundle Classloader nach Java-Klassen suchen soll. Interessant, wenn man eine klassische Java-Webanwendung, deren Java-Klassen sich üblicherweise in WEB-INF/classes befinden, nach OSGi bringen möchte.

Web-ContextPath

Optionaler Parameter; gibt man hier zum Beispiel /foo an, wird die Webanwendung unter genau diesem Kontextpfad (zum Beispiel http://localhost:8080/foo) erreichbar sein. Lässt man den Parameter weg, wird der Bundle-Name als Kontextpfad verwendet.

Jetty-WebXmlFilePath

In der Standardeinstellung wird die web.xml im Verzeichnis WEB-INF erwartet. Durch Verwendung dieses Parameters kann dieses Verhalten angepasst und für die web.xml eine andere Stelle innerhalb des Bundles festgelegt werden.

Jetty-WarFolderPath

Legt den Ort innerhalb des Bundles fest, an dem weitere Ressourcen der Webanwendung (HTML, Images, Sounds) liegen. Optionaler Parameter, im Standard werden die Ressourcen im Root des Bundles erwartet.

managedServerName

Für den Fall, dass innerhalb einer OSGi-Umgebung mehrere Jetty-Instanzen laufen, kann mithilfe dieses Parameters bestimmt werden, in welche der laufenden Instanzen die Webanwendung deployt werden soll (siehe Abschnitt „Managed Server“).

[ header = Seite 8: Ein paar Worte zu JSP ]

Ein paar Worte zu JSP

Gerade im Zusammenhang mit Webanwendungen drängt sich natürlich die Frage auf, wie man neben Servlets auch JSP (JavaServer Pages) mit Jetty und OSGi verwenden kann. Um JSP zu verwenden, sind über das minimale Set-up hinaus einige weitere Bibliotheken einzubinden. Speziell für JSP stellen die Jetty-Entwickler außerdem das Bundle jetty-osgi-boot-jsp zur Verfügung. Dabei handelt es sich um ein so genanntes Bundle-Fragment, welches das oben beschriebene Bundle jetty-osgi-boot um JSP-Support erweitert. Eine genaue Beschreibung, welche zusätzlichen Bibliotheken eingebunden werden müssen und wie der JSP-Support konfiguriert wird, findet sich unter [6].

Managed Server

Das jetty-osgi-boot Bundle liest die Jetty-eigenen Konfigurationsdateien ein, erzeugt eine Jetty-Instanz und stellt den Jetty-Server außerdem als OSGi Service bereit. Danach holt es sich alle Jetty-Server, die als OSGi Service registriert wurden, und startet diese.

Manchmal gibt es besondere Anforderungen, zum Beispiel das Starten mehrerer Jetty-Instanzen in der gleichen OSGi-Umgebung. Das kann zum Beispiel dann sinnvoll sein, wenn man getrennte Instanzen für Test und Entwicklung bereitstellen möchte. Für diesen Fall kann man so genannte „Managed Server“ konfigurieren. Das bedeutet, in einer OSGi-Umgebung existieren mehrere Jetty-Server, natürlich alle erreichbar unter einem anderen Port und gegebenenfalls auch mit abweichender Konfiguration. Damit man die einzelnen Jetty-Instanzen voneinander unterscheiden kann, erhalten sie einen eindeutigen Namen. So erhält die Jetty-Instanz, die initial durch das jetty-osgi-boot Bundle hochgefahren wurde, automatisch den Namen defaultJettyServer und ist über diesen auch referenzierbar. Einen eigenen Managed Server erstellt man sich am besten, indem man ein separates Bundle anlegt und die Jetty-Instanz über die Activator-Klasse des Bundles initialisiert.

jetty-osgi-boot wird dieses Bundle ebenfalls erkennen, da hier ja alle als OSGi Service registrierten Jetty-Server überprüft und gestartet werden. Der Managed Server wird somit in der OSGi-Umgebung bereitstehen. In Listing 3 sieht man ein Beispiel für eine Activator-Klasse, die einen Managed Server erzeugt. Hierfür wird ein neues Serverobjekt vom Typ org.eclipse.jetty.server.Server instanziiert und konfiguriert.

public class Activator implements BundleActivator { public void start(BundleContext context) throws Exception { Server server = new Server(); Dictionary serverProps = new Hashtable(); serverProps.put("managedServerName", "testServer"); serverProps.put("jetty.port", "9999"); serverProps.put("jetty.etc.config.urls", "file:/opt/jetty/etc/jetty.xml,file:/opt/jetty/etc/jetty-selector.xml,file:/opt/jetty/etc/jetty-deployer.xml"); context.registerService(Server.class.getName(), server, serverProps); } } 

Nachdem alle wichtigen Einstellungen erledigt sind (Name des Managed Server und Port festlegen, Pfad zu den Jetty-Konfigurationsdateien für diese Instanz bestimmen), wird der Server schließlich als OSGi Service registriert und ist damit auch sichtbar für das Bundle jetty-osgi-boot, das den Service verwendet, um diese Instanz – wie weiter oben bereits beschrieben – zu starten. Die Instanz ist ab sofort unter dem Namen testServer auf dem eingestellten Port erreichbar. Dies bedeutet insbesondere nun auch, dass beliebige Webanwendungs-Bundles in diesem Server deployt werden können, indem der Parameter managedServerName (siehe auch Tabelle 2) im Manifest der jeweiligen Webanwendung gesetzt wird.

Fazit

Der vorliegende Artikel hat gezeigt, wie man ein aktuelles Jetty mit OSGi zusammenbringt und welche Möglichkeiten es bezüglich der Konfiguration von Webanwendungen gibt. Nach der Lektüre dieses Artikels sollte der Leser in der Lage sein, die ersten Schritte selbstständig zu gehen und eine bestehende Webanwendung in OSGi zum Laufen zu bekommen. Wer tiefer in das Thema einsteigen will und wer sich vor allem näher mit dem Thema Enterprise OSGi beschäftigen möchte oder muss, dem möchte ich an dieser Stelle unbedingt die Lektüre von [7] empfehlen.

Geschrieben von
Marc Teufel
Marc Teufel
Marc Teufel arbeitet als Projektleiter und Softwarearchitekt bei der hama GmbH & Co KG und ist dort für die Durchführung von Softwareprojekten im Bereich internationale Logistik zuständig. Er ist Autor zahlreicher Fachartikel im Web-Services- und Eclipse-Umfeld. Er hat drei Bücher zu Web Services veröffentlicht, sein aktuelles Buch „Eclipse 4 – Rich Clients mit dem Eclipse 4.2 SDK“ ist kürzlich bei entwickler.press erschienen.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: