Ekkes Indigo Highlights - Teil 3: OSGi-Entwicklung

EclipseRT in Indigo: Equinox, Jetty, EclipseLink & Co.

Ekkehard Gentz

Eclipse basiert schon lange auf OSGi Bundles – auch historisch bedingt als „Plug-ins“ bezeichnet. OSGi wird bereitgestellt von Eclipse Equinox und ist nicht nur das Fundament für die IDE, sondern ebenfalls für Eclipse-Runtime-Umgebungen [1]. Was gibt es hier Neues im Indigo Release (Eclipse 3.7)?

Abb. 1: Eclipse-Runtime-Projekt
Equinox unterstützt OSGi 4.3

Die neue OSGi-Spezifikation 4.3 [2] wurde erst im April 2011 released, und Eclipse Equinox unterstützt bereits jetzt ein paar Wochen später mit dem Indigo Release diese Spezifikation. Wenn das nicht schnell ist!

OSGi R4.3 Core Framework API Aktualisierungen: OSGi unterstützt jetzt Generics – etwas, worauf viele schon lange gewartet haben. Ob ServiceRegistry, ServiceTracker, BundleTracker oder das Bundle Interface – überall kann jetzt mit Generics gearbeitet werden. OSGi unterstützt weiterhin J2ME 1.1 und J2SE 1.4 und ist trotz des Einsatzes von Generics in der Lage, den Code für diese Plattformen zu kompilieren. Selbstverständlich funktioniert das auch mit Equinox.

Achtung: die Packages


org.osgi.service.packageadmin

org.osgi.service.startlevel

sind deprecated und wurden ersetzt durch


org.osgi.framework.wiring

org.osgi.framework.startlevel.

Etwas Neues gibt es auch für die Freunde von Bytecode-Weaving, also der Manipulation von Bytecode zur Runtime. Dazu gibt es einen neuen „Weaving Hook“:

org.osgi.framework.hooks.weaving

Mit diesem Hook ist es dann sogar möglich, Package-Abhängigkeiten zu verändern – also ein mächtiges aber auch gefährliches Werkzeug.

Equinox und Logging

So flexibel OSGi ist, so einfach ist es aber auch, in den verschiedensten Eclipse-Projekten unterschiedliche Logging Frameworks einzusetzen: Log4J, SLF4J, java.util usw. Immer wieder bin ich in den letzten Jahren auf Konstellationen gestoßen, wo diese Abhängigkeiten als „Required Bundle“ definiert waren – das macht es sehr schwierig, mehrere Projekte zu nutzen und alles über ein einheitliches Framework zu loggen. Das sieht inzwischen viel besser aus, da es sich herumgesprochen hat, dass man besser mit Package-Importen arbeitet. Dann ist es möglich, mit einem Framework wie SLF4 alle abzudecken, da SLF4J die benötigten Packages bereitstellt. Was mich besonders freut: immer mehr Projekte setzen beim Logging auf SLF4J mit der nativen Implementierung LogBack – das ist auch meine Präferenz.

Bleibt aber neben dem „klassischen“ Logging noch das Logging aus dem OSGi Framework (Equinox) bzw. Eclipse (IDE). Es war bisher sehr schwierig, die diversen Logging APIs unter einen Hut zu bringen: ILog, FrameworkLog, OSGi LogService. Das ist jetzt viel einfacher, da der Equinox Extended OSGi LogService in das Core Framework mit aufgenommen wurde. Ob Eclipse oder Equinox – jetzt können Listener auf alle Log Events reagieren. Über die Thematik „Logging und OSGi“ befindet sich hier [3] eine detaillierte Blog-Serie.

Geschrieben von
Ekkehard Gentz
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.