Download pdf - Eclipse Magazin15 - Performance Logging

20 www.eclipse-magazin.deeclipse magazin Vol. 15

AspectJ und EquinoxArchitektur

Die Allianz Deutschland AG führt der-zeit in einem strategischen Großpro-

jekt ein neues Softwaresystem für alle Be-lange des Versicherungs-Kerngeschäfts ein [1], [2]. Die neue Software, das Allianz Business System (ABS), stellt den Kunden in den Mittelpunkt und ermöglicht dem Sachbearbeiter eine umfassende Bearbei-tung der Kundenanliegen, die sich durch die täglichen Telefonate, den Brief- und E-Mail-Verkehr ergeben. Die ABS-An-wendung beruht auf einer modernen, mehrschichtigen Architektur, bei der die

Geschäftslogik und zukünftig auch das User Interface auf der Programmierspra-che Java und der Eclipse-Plattform [3] basieren. Die Komponentenarchitektur und Erweiterungsmöglichkeiten von Equinox [4] (ehemals Eclipse Runtime Core) stellen wesentliche Merkmale der ABS-Architektur dar und erfüllen die für ein strategisches Anwendungssystem wichtigen Anforderungen an Modula-rität, Flexibilität und Erweiterbarkeit. Gleichzeitig definiert die Verwendung der Eclipse-Plattform verschiedene Rahmen-

bedingungen, z.B. für den Build-Prozess und den Einsatz von AspectJ, worauf wir noch detailliert eingehen werden.

Eine wichtige Forderung an die ABS-Anwendung ist die Einhaltung der in Form von Service Level Agreements zugesicher-ten Antwortzeiten. Schließlich sind für ei-ne unternehmenskritische Anwendung die Verfügbarkeit und Performance noch vor der Funktionalität die wichtigsten Anfor-derungen, so Dr. Ralf Schneider, CIO der Allianz Deutschland AG. Zur Sicherstel-lung der Performance ist ein verlässliches Reporting der Performance-Kennzahlen im produktiven Betrieb erforderlich, um beispielsweise die Frage „Wie lange muss ein Sachbearbeiter warten, bis das Er-gebnis der Personensuche, sortiert nach Name und Postleitzahl, angezeigt wird?“ beantworten zu können. Anders als beim Profiling während der Entwicklungspha-se geht es hierbei um die kontinuierliche Performance-Ermittlung „in Produkti-on“ mit dem Ziel, rasch Gegenmaßnah-men einleiten zu können, wenn eine signi-

Säuberlich getrenntPerformance Logging mit AspectJ und der Eclipse-Plug-in-Architektur

>> heiko seeberger und harald griesbeck

Performance-Kennzahlen einer Software durch Logging im produktiven Betrieb zu ermitteln, ist geradezu eine Paradedisziplin für aspektorientierte Programmierung. Die Theorie ist simpel, in der Praxis sieht es etwas anders aus. In einer umfassenden Geschäftsanwendung kommen AspectJ und die Eclipse-Plug-in-Architektur bei der Lösung dieses Cross-Cutting Concerns zum Einsatz.

21www.eclipse-magazin.de eclipse magazin Vol. 15

ArchitekturAspectJ und Equinox

fi kante Verschlechterung der Performance erkannt wird. In der ABS-Anwendung werden hierfür im Prinzip Start- und End-Zeitpunkte von defi nierten Messstrecken in Logfi les ausgegeben, zentral gesammelt und dann ausgewertet.

Dieses Performance Logging ist ein typischer Cross-Cutting Concern [5], hat also nichts mit der grundlegenden bzw. primären Funktionalität zu tun, wie etwa der Suche von Personen anhand von Na-me und Postleitzahl. Vielmehr durchsetzt der Code zum Ausgeben der Messpunkte vielerorts den primären Code. Diese Ver-mischung verschiedener Belange verletzt das bewährte Prinzip der Separation of Concerns [6] und es entsteht dadurch unverständlicher und schlecht wartbarer Programm-Code. Die aspektorientierte Programmierung [7] adressiert dieses Prob-lem und bietet die Möglichkeit, auch die Cross-Cutting Concerns zu modularisie-ren, wodurch wiederum eine verbesserte Softwarequalität erreicht wird. Da die ABS-Anwendung mit der Programmier-sprache Java und mit der Entwicklungs-umgebung Eclipse SDK entwickelt wird, bietet sich die Verwendung von AspectJ [8] an. AspectJ stellt den Quasi-Standard für Aspektorientierung mit Java dar und verfügt mit AJDT [9] über eine hervorra-gende Integration in das Eclipse SDK. As-pectJ ergänzt die objektorientierte Spra-che Java um aspektorientierte Konzepte. Dabei werden die so genannten Primary Concerns, d.h., die grundlegenden An-forderungen an ein Software-System, mit objektorientierten Mitteln entwickelt, z.B. mit Java-Konstrukten wie Packages, Klassen, Methoden etc. Die Cross-Cutting Concerns werden dann mit den erweiter-ten Sprachmitteln von AspectJ, z.B. mit As-pekten, Advices und Pointcuts, umgesetzt. Für Details sei auf die Dokumentation auf der AspectJ-Website verwiesen.

Ein weiterer und entscheidender Punkt, der im konkreten Fall zum Einsatz von aspektorientierter Programmierung führte, ist die Fähigkeit von AspectJ, nicht nur auf Quellcode-Ebene arbeiten zu kön-nen, sondern auch mit vorhandenen Lib-raries. Das bedeutet, dass auch in vorkom-piliertem Code Aspekte eingebaut werden können. Die getrennten Belange, also der primäre Code und die Cross-Cutting Con-cerns, werden in der aspektorientierten Programmierung getrennt erstellt und müssen in einem späteren Schritt wieder zusammengeführt werden. Diesen Vor-

gang nennt man Weaving. AspectJ bietet zum einen die Möglichkeit, das Weaving beim Kompilieren durchzuführen (Com-pile-time Weaving), zum anderen erlaubt AspectJ, das Weaving zur Laufzeit – ge-nauer gesagt, beim Laden der betroffenen Klassen durch die Java Virtual Machine – durchzuführen (Load-time Weaving). Bei-de Varianten ermöglichen das Einweben von Aspekten in fremden Libraries. Im konkreten ABS-Projekt besteht die Not-wendigkeit, Performance-Messpunkte im sogenannten ABS-Kern, der als fertige Plattform zur Verfügung steht, einzubau-en. Mithilfe der Weaving-Technik kann diese Anforderung elegant gelöst werden.

Modularisierung par excellenceDas bereits erwähnte Prinzip der Se-paration of Concerns besagt, dass sich

komplexe Problemstellungen leichter lösen lassen, wenn sie in überschaubare und disjunkte „Häppchen“ zerlegt sind. Software sollte somit aus Modulen be-stehen, die möglichst wenig überlappen-de Funktionalität aufweisen. Java bietet als objektorientierte Sprache bereits strukturelle Konzepte zur Modularisie-rung, z.B. Packages, Klassen, Methoden etc. Mit dieser Strukturierung werden die Primary Concerns abgebildet, z.B. eine Klasse Person mit den Properties Vor- und Nachname. In der Praxis gibt es jedoch so gut wie immer Belange, die sich mithilfe der objektorientierten Pro-grammierung nicht modularisieren las-sen. Typische Beispiele für Cross-Cutting Concerns sind Querschnittsfunktionen wie Logging, Tracing, Security usw., also nichtfunktionale Anforderungen. Mit

Anzeige



aspektorientierter Programmierung las-sen sich auch diese Cross-Cutting Con-cerns modularisieren, sodass Klassen und Aspekte bzw. deren Methoden und Advices keine überlappenden Belange mehr enthalten (Abb. 1).

Neben dieser Form von Modularisie-rung auf „Mikroebene“ dient das Kon-zept von Komponenten [10] ebenfalls zur Separation of Concerns, jedoch auf grö-berer Ebene. Equinox implementiert mit OSGi [11] eine dynamische Komponen-tenarchitektur, welche die Zusammen-führung bzw. Installation von Kompo-nenten (Bundles im OSGi-Jargon) zum spätestmöglichen Zeitpunkt erlaubt, nämlich zur Laufzeit. Somit lassen sich Bundles von zusammengehörigen Klas-sen oder Aspekten bilden, z.B. ein Bundle Person für die Fachlichkeit rund um das Domain Object Person und ein Bundle Security mit Aspekten für Authentifizie-rung und Autorisierung. Diese Bundles sind in sich selbst konsistent und können unter Berücksichtigung ihrer Abhängig-keiten isoliert entwickelt und getestet werden. Wenn die Abhängigkeiten, die jedes Bundle explizit deklarieren muss, minimal gehalten und geschickt entwor-fen werden, z.B. in Form von Interfaces, dann ergibt sich automatisch ein hoher Grad an Separierung. In großen Projek-ten hat man hierdurch die Möglichkeit, die separierten Teile in unterschiedlichen Teams entwickeln zu lassen. Wie man sieht, ergänzen sich OSGi und AspectJ hervorragend, um eine durchgehende Modularisierung zu erzielen. Dabei wer-

den Cross-Cutting Concerns durch As-pekte modularisiert und diese wiederum in Aspekt-Bundles.

Die separierten Belange müssen letztendlich wieder zusammengeführt werden. Dieser Vorgang wird, wie be-reits erwähnt, als Weaving bezeichnet. Bei AspectJ gibt es dafür zwei Methoden: Compile-time Weaving und Load-time Weaving. Beim Compile-time Weaving werden Klassen und Aspekte bereits durch den AspectJ Compiler während des Build-Prozesses zusammengeführt und der vollständige Byte-Code erzeugt. Somit ist der AOP-Ansatz für die Lauf-zeitumgebung völlig transparent. Ein weiterer Vorteil von AspectJ Compile-time Weaving ist die gute Unterstützung in der Entwicklungsumgebung durch die AJDT Plug-ins. So werden zum Beispiel durch Marker diejenigen Stellen hervor-gehoben, an denen Aspekte verwoben werden (Abb. 2). Auch das Debugging funktioniert völlig transparent.

In der Praxis zu riskantAllerdings verlässt Compile-time Wea-ving die Modularisierung bereits beim Build-Prozess. Der oben aufgeführte Vorteil der Kombination von AspectJ mit den dynamischen Eigenschaften von OSGi geht dadurch verloren. Abgesehen von diesen prinzipiellen Gesichtspunk-ten spielt natürlich die Praxistauglichkeit eine entscheidende Rolle. Umfangreiche Anwendungen werden in der Regel nicht auf einem Entwicklerrechner „gebaut“, sondern es kommt ein zentraler Build-Prozess zum Einsatz. Eclipse stellt hierfür den PDE Build [12] zur Verfügung, der auf Apache Ant [13] basiert. Dieser kann zum heutigen Stand (Eclipse 3.3.1) nicht konfiguriert werden, um einen anderen Compiler als den Standard-Compiler zu verwenden [14]. Daher liefert AJDT ei-nen Patch für den PDE Build: Die Datei pdebuild.jar im Plug-in org.eclipse.pde.build muss durch eine modifizierte Datei ersetzt werden. Dadurch werden in der Folge alle Plug-ins nicht mehr mit dem originalen PDE Compiler übersetzt, son-dern mit dem AspectJ Compiler. Bei die-sem Vorgehen ist schon alleine aufgrund möglicher Versions-Inkompatibilitäten allerhöchste Vorsicht geboten. Der ge-nannte Patch wird von AJDT erst seit Version 1.4.1 geliefert, die kompatibel zu Eclipse 3.2.1 ist. Da die ABS-Anwen-dung auf Eclipse 3.2.0 entwickelt wird,

gab es Bedenken hinsichtlich der Ver-wendung des Patches. Diese wurden in einem Smoke-Test bestätigt: einerseits durch Warnmeldungen, die ohne Patch nicht auftraten, andererseits durch Ab-brüche beim Kompilieren von reinen Ressource-Plug-ins, d.h. Plug-ins ohne Klassen. Letztendlich erschien dadurch der Einsatz von AspectJ Compile-time Weaving als zu riskant und die hohen Abhängigkeiten der einzelnen Versions-stände als zu unflexibel, sodass Compile-time Weaving für die ABS-Anwendung nicht zum Einsatz kommt.

Bei Load-time Weaving findet die Zusammenführung von Klassen und Aspekten erst zur Laufzeit – genauer ge-sagt beim Classloading – statt. Dazu ist es nötig, das Classloading entsprechend zu modifizieren. AspectJ bietet dafür eine Unterstützung in Form von JVM Agents oder speziellen ClassLoaders [15] an. Load-time Weaving bietet den Vorteil, die Auswahl der Klassen, die mit Aspek-ten verwoben werden, nicht von Anfang an zu begrenzen. Während beim Com-pile-time Weaving nur die beim Build-Prozess vorliegenden Klassen verwoben werden, können später hinzukommen-de nicht mehr berücksichtigt werden. Für Security-Aspekte kann dies ein sehr wichtiges Kriterium sein, z.B. wenn vor jeglicher Ausführung einer execute()-Methode eines IAction-Interfaces zuvor die Authentifizierung und Autorisierung überprüft werden sollen.

Der große Vorteil von Load-time Weaving ist der Erhalt der Modulari-sierung über den Build-Prozess hinweg bis zum Zeitpunkt der Ausführung. Die Builds von Primary Concerns und Querschnittsfunktionen können sepa-rat erfolgen. Natürlich müssen die As-pekte, auch wenn das Weaving erst beim Classloading erfolgt, übersetzt werden. Allerdings reicht es nun aus, nur dieje-nigen Bundles, die Aspekte enthalten, mit dem AspectJ Compiler zu überset-zen. Dafür kann entweder ein separater PDE Build mit Patch aufgesetzt werden oder es wird einfach der Export aus der Entwicklungsumgebung verwendet. In beiden Fällen kann der ursprüngliche PDE Build für alle primären Bundles unverändert bleiben. Im konkreten Fall der ABS-Anwendung wird als pragmati-sche Zwischenlösung der Export aus der Entwicklungsumgebung verwendet, da AspectJ derzeit nur für das Performance

Abb. 1: Cross-Cutting Concerns werden in Aspekten modularisiert

Abb. 2: Marker zeigen die Stellen, an denen Aspekte verwoben werden

Abb. 3: Weaving erzeugt eine Abhängigkeit zum Aspekt



Logging verwendet wird und nur ein Bundle mit Aspekten existiert.

AspectJ Load-time Weaving unter EquinoxViele der herausragenden Eigenschaf-ten, die OSGi bietet, werden in Equinox durch eine ausgefeilte Classloading-Stra-tegie umgesetzt. Daher kann für AspectJ Load-time Weaving unter Equinox nicht die oben erwähnte Standardunterstüt-zung in Form von JVM Agents verwen-

det werden, sondern das Load-time Wea-ving muss in das Equinox Classloading integriert werden.

Weiter müssen Bundles unter OSGi ihre Abhängigkeiten explizit deklarie-ren. Zur Entwicklungszeit geschieht dies durch Einträge im so genannten Bundle-Manifest. Zur Laufzeit sind für ein Bundle dann nur diejenigen Abhän-gigkeiten sichtbar, die explizit importiert werden. Wenn eine Klasse mit einem As-pekt verwoben wird, entsteht dabei eine neue Abhängigkeit von der verwobenen Klasse zum Aspekt (Abb. 3).

Zur Entwicklungszeit sind diese Abhängigkeiten natürlich noch nicht vorhanden, denn schließlich werden die Cross-Cutting Concerns durch die aspektorientierte Programmierung separiert, d.h. der „eigentliche“ Code kennt die Aspekte gar nicht. Die Bundles können somit diese Abhängigkeiten, die durch das Load-time Weaving entstehen, nicht a priori im Bundle-Manifest de-klarieren. Daher harmoniert Load-time Weaving nicht out-of-the-box mit OSGi, sondern bedarf besonderer Unterstüt-zung: Die neuen Abhängigkeiten müssen den Bundles beim Laden dynamisch hin-zugefügt werden.

Equinox bietet seit Version 3.2 mit dem so genannten Hookable Adaptor [16] eine sehr flexible Implementierung von OSGi, die es ermöglicht, zahlreiche Funktionalitäten des Frameworks an-zupassen oder zu erweitern. Über einen HookConfigurator können verschiede-ne Hooks mit unterschiedlichen Funk-tionalitäten registriert werden, die vom Hookable Adaptor während der Aus-führung der jeweiligen Funktionalität aufgerufen werden. Diese Klassen und Ressourcen werden in einem so genann-ten Framework Extension Fragment ge-bündelt, dessen Host Bundle das System Bundle org.eclipse.osgi ist.

Im Eclipse-Projekt Equinox Aspects [17] sind nun verschiedene Hooks reali-siert, insbesondere ein BundleFileWrap-perFactoryHook und ein ClassLoading-Hook, um AspectJ Load-time Weaving für Equinox zu ermöglichen. Das ver-wendete Framework Extension Frag-ment heißt org.aspectj.osgi, und über die System Property osgi.framework.exten-sions wird es dem Hookabel Adaptor be-kannt gegeben:

osgi.framework.extensions=org.aspectj.osgi

Darüber hinaus besteht Equinox As-pects aus dem obligatorischen Bundle org.aspectj.osgi.service.weaving, das den Weaving Service anbietet. Für die J9-JVM von IBM stellt das optionale Bundle org.aspectj.osgi.service.caching.j9 einen Caching-Mechanismus zur Verfügung, wobei die Realisierung eines allgemeinen Caching Services für beliebige JVMs eine noch offene Aufgabe der Community ist.

Installieren und Konfigurieren von Equinox AspectsEquinox Aspects kann entweder aus dem Eclipse SDK über eine Update Site [18] installiert oder als ZIP-Archiv von der „Getting Started“-Seite [19] herunterge-laden werden. Da es sich hierbei um reine Runtime Plug-ins ohne Tooling oder an-dere Integration in das SDK handelt, ist es empfehlenswert, sie nicht in das SDK zu installieren, sondern die Plug-ins in die jeweilige Target Platform aufzuneh-men. Auf alle Fälle muss berücksichtigt werden, dass Equinox Aspects wie jedes Framework Extension Fragment un-bedingt im selben Verzeichnis wie das System Bundle org.eclipse.osgi abgelegt werden muss, da die Framework Exten-sion sonst nicht gefunden und infolge-dessen ignoriert wird.

Damit die Bundles, auf denen die Aspekte eines Aspekt-Bundles wirken sollen, zur Laufzeit mit den nötigen Ab-hängigkeiten versehen werden können, führt Equinox Aspects neue Manifest-Header ein, die in den Aspekt-Bundles verwendet werden:

•Eclipse-SupplementBundle•Eclipse-SupplementImporter•Eclipse-SupplementExporter

Den unter Eclipse-SupplementBundle aufgeführten Bundles wird beim Laden dynamisch die Abhängigkeit vom As-pekt-Bundle hinzugefügt. Analog dazu werden bei Eclipse-SupplementImpor-ter und Eclipse-SupplementExporter importierte bzw. exportierte Packages hinzugefügt. Im mitgelieferten Beispiel findet man im Bundle-Manifest des As-pekt-Bundles de.metafinanz.demo.aop.osgi.aspect den folgenden Eintrag:

Eclipse-SupplementBundle: de.metafinanz.demo.aop.osgi

Dadurch wird das Bundle de.metafinanz.demo.aop.osgi zur Laufzeit mit einer

Checkliste für Aspekt-BundlesDie folgenden Punkte müssen umgesetzt wer-

den, damit Aspekt-Bundles „funktionieren“:

•EinfügenderSupplementHeaderfürzu

aspektierende Bundles/Packages

•ExportierenderPackagesmitAspekten

•ExportierendesPackagesmitaop.xml

(in der Regel org.aspectj)•ReexportierenderAspectJLibrary

Abb.4:Eclipse-SupplementBundle erzeugtzurLaufzeitdienötigenAbhängigkeiten

Abb.5:BeispielinAktion:DerAspektgibtdieAus-führungsdaueraus

Abb.6:LauncherfürdasBeispiel: BundlesundStart-Level

25www.eclipse-magazin.de eclipse magazin Vol. 15

ArchitekturAspectJ und Equinox

Abhängigkeit auf das Aspekt-Bundle de.metafinanz.demo.aop.osgi.aspect versehen (Abb. 4).

Für die Angabe der Bundles können auch Wildcards verwendet werden, z.B.

Eclipse-SupplementBundle: de.metafinanz.*, org.eclipse.*

Alle Bundles, die mit de.metafinanz oder org.eclipse beginnen, erhalten in diesem Fall eine Abhängigkeit auf das Aspekt-Bundle. Equinox Aspects verwendet zur Identifizierung der Aspekte, die beim Load-time Weaving berücksichtigt wer-den sollen, aop.xml-„Standarddateien“ [20]. Nur die Aspekte, die dort aufge-führt sind, werden berücksichtigt. Im mitgelieferten Beispiel enthält die aop.xml-Datei nur einen Aspekt:

<aspectj>

<aspects>

<aspect name="de.metafinanz.demo.aop.osgi.console.

aspect.PerfHello" />

</aspects>

</aspectj>

Über die System Property org.aspectj.weaver.loadtime.configuration wird Equinox Aspects mitgeteilt, welche aop.xml-Dateien herangezogen werden sol-len. Als Standard hat sich hier org/as-pectj/aop.xml etabliert, aber natürlich sind beliebige andere Pfade möglich.

org.aspectj.weaver.loadtime.configuration=org/aspectj/

aop.xml

Selbstverständlich gilt auch für Aspekt-Bundles, dass nur exportierte Packages für abhängige Bundles sichtbar sind. Das bedeutet, dass sowohl die Packages, die Aspekte enthalten, als auch die Packages, welche die aop.xml-Dateien enthalten, exportiert werden müssen. Ansonsten findet entweder kein Weaving statt oder das Weaving bricht mit Fehler ab. Im mit-gelieferten Beispiel werden die folgenden Packages exportiert:

Export-Package: de.metafinanz.demo.aop.osgi.console.

aspect,

org.aspectj

Da die Aspekte von der AspectJ Runtime Library abhängig sind, entsteht beim Weaving eine mittelbare Abhängigkeit der zu aspektierenden Bundles von der AspectJ Runtime Library. Daher ist es

Heiko Seeberger leitet die Market Unit Enterprise Architecture der metafinanz GmbH (www.metafinanz.de). Er erstellt seit etwa zehn Jahren Enterprise Applications mit

Java, wobei sein aktueller Fokus auf Eclipse und AspectJ liegt. Kontakt: [email protected].

Harald Griesbeck arbeitet bei der Allianz Deutschland AG als Client- Architekt im ABS-Projekt. Er ist seit über zehn Jahren im Java-Umfeld tätig, mit Schwerpunkt Client-Fra-

meworks und Integration von Java-Client-Anwen-dungen in die Allianz-Anwendungslandschaft. Kontakt: [email protected].

wichtig, dass die Aspekt-Bundles diese Abhängigkeit reexportieren:

Require-Bundle: org.aspectj.runtime;visibility:=reexport

Eine Zusammenfassung der wichtigsten Konfigurationseinstellungen für die Ver-wendung von Equinox Aspects befindet sich im Kasten „Checkliste für Aspekt-Bundles“.

BeispielZur Verdeutlichung der vorgestellten Konzepte dient ein stark vereinfachtes Beispiel des Performance Loggings. Das Bundle de.metafinanz.demo.aop.osgi enthält ein „Hello World“-Command für die OSGi-Konsole: Wenn „hello“ auf der Konsole eingegeben wird, dann wird „Hello World!“ ausgegeben. Das Bundle de.metafinanz.demo.aop.osgi.aspect ent-hält einen Aspekt, der die Ausführungs-dauer dieses Kommandos misst und diese ebenfalls auf der Konsole ausgibt.

Um die Beispielapplikation auszufüh-ren, wird der OSGi-Launcher des Eclipse

[1] HandelsblattNr.220,14.11.2006,S.28: ALLIANZ:DerVersicherermachtsichfitfürdieZukunft.

[2] sueddeutsche.de,25.11.2007:www.sued-deutsche.de/,ra3m1/wirtschaft/ artikel/850/144524/

[3] www.eclipse.org/platform/

[4] www.eclipse.org/equinox/

[5] de.wikipedia.org/wiki/ Cross-Cutting_Concern/

[6] en.wikipedia.org/wiki/ Separation_of_Concerns/

[7] de.wikipedia.org/wiki/ Aspektorientierte_Programmierung/

[8] www.eclipse.org/aspectj/

[9] www.eclipse.org/ajdt/

[10] de.wikipedia.org/wiki/Komponente_%28Software%29/

[11] www.osgi.org

[12] www.eclipse.org/pde/pde-build/

[13] ant.apache.org

[14] PDB-Bug:https://bugs.eclipse.org/bugs/show_bug.cgi?id=147432/

[15] AspectJ-LTW:www.eclipse.org/ aspectj/doc/released/devguide/ ltw-configuration.html

[16] HookableAdaptor:wiki.eclipse.org/index.php/Adaptor_Hooks/

[17] EquinoxAspects:www.eclipse.org/equin-ox/incubator/aspects/

[18] EquinoxAspectsUpdateSite:download.eclipse.org/tools/aspectj/dev/update/

[19] EquinoxAspectsGettingStarted:www.eclipse.org/equinox/incubator/aspects/getting_started.php

[20]aop.xml:www.eclipse.org/aspectj/doc/released/devguide/ltw-configuration.html

[21] PeterFriese,MartinLippert, HeikoSeeberger:Securitydoes matter,EclipseMagazinVol.12

>>Links & Literatur

SDKs verwendet. Die oben aufgeführten System Properties werden im Reiter Ar-guments gesetzt und die zu verwenden-den Bundles werden im Reiter Bundles konfiguriert. Dabei ist es wichtig, den Weaving Service (org.aspectj.osgi.service.weaving) zu starten, bevor zu aspektieren-de Bundles geladen werden, z.B. indem ein geeigneter Start-Level gesetzt wird.

FazitMit Equinox Aspects steht eine Frame-work Extension für Equinox zur Verfü-gung, mit der AspectJ Load-time Weaving auch unter den besonderen Rahmen-bedingungen von OSGi bzw. Equinox funktioniert. So lassen sich die Vorteile von aspektorientierter Programmierung, Load-time Weaving und OSGi hervorra-gend ergänzen, sodass eine durchgängige Modularisierung erzielt werden kann. So konnte in einem Großprojekt der Alli-anz Deutschland AG der typische Cross-Cutting Concern Performance Logging mithilfe von AspectJ Load-time Weaving elegant realisiert werden.