Een op spiegel-reflectie gebaseerde debugger voor aspect georiënteerd platformen. Wouter De Borger

Transcriptie

1 Een op spiegel-reflectie gebaseerde debugger voor aspect georiënteerd platformen Wouter De Borger 6 juni 2008

2 Inhoudsopgave 1 Inleiding Aspecten Debugging De vereisten van de aspectdebugger Structurele reflectie Zichtbaarheid Traceerbaarheid Inkapseling Het doel van de thesis Aanpak Tekststructuur Bestaande technologie AspectJ Syntaxis en Semantiek Joinpoint Model Bestaande ondersteuning voor debugging JBoss Syntaxis en Semantiek Joinpointmodel Bestaande ondersteuning voor debugging Java Platform Debugging Architecture JVM Tool Interface Java Debug Wire Protocol Java Debug Interface Alternatieve debugging strategieën Source Weaving Omniscient debugging Architectuur Rationale Het gebruik van JDI De splitsing front-end back-end

3 INHOUDSOPGAVE Ondersteunbare functionaliteiten Beperkingen Onderdelen AJDI ADB-Back-end Interface ADB ADB-Back-end Agent Beperkingen Identiteit API-overerving Object Consistentie Modulaire compositie Geïsoleerde aggregatie Evaluatie Eerste validatie: AspectJ AspectJ in relatie tot AJDI ABC Bytecode Singleton Aspect Per Object Aspect Per CFLOW Aspect CFLOW ITD ABC Bytecode in relatie tot ADB De Aspect Bench Compiler Onderdelen Het compilatieproces Agent Oorspronggebaseerde lijnnummers Aspectinformatie Crosscuttinginformatie Backend Resultaat Tweede validatie: JBoss JBoss in relatie tot AJDI JBoss weaving model JBoss weaving model in relatie tot ADB Agent Aspect naar klasse Klasse naar aspect Adviezen per aspect Applicaties per methode

4 INHOUDSOPGAVE Applicaties per advies Backend Resultaat Conclusie 71 A ABC-broncode 73 B Demotool 74 C Bibliografie 77 D Woordenlijst 79 E Acroniemen 82

5 Voorwoord Eerst en vooral wil ik een aantal mensen bedanken die elk op hun manier hebben bijgedragen aan deze thesis. Mijn speciale dank gaat uit naar: Prof. Dr. ir. W. Joosen, promotor, voor de kritische kijk en de mogelijkheid om AOSD te bezoeken. Bert Lagaisse, dagelijks begeleider, voor de psychologische steun en sturing. Stefan Walraven, lotgenoot, voor de vele boeiende gesprekken over onze thesissen. Mijn familie, voor het warme nest, de levenslange steun en het vele nalezen. Katrien, mijn lieve vriendin, voor alle steun. Excuses voor de vele maanden waarin mijn gedachten ver van de wereld waren. 4

6 Hoofdstuk 1 Inleiding De aspectgeoriënteerde technologie wordt stilaan volwassen. De gebruikte technieken worden geavanceerder. Het aantal bestaande talen is al groot en neemt nog toe. De overstap naar de industrie is begonnen. De gebruiksondersteuning is echter nog niet zo volledig. Een echte aspectdebugger bestaat nog niet. In de volgende paragrafen zullen aantonen dat hier nochthans grote nood aan is. Later in deze thesis zal ik ingaan op de architectuur en implementatie van een debugger die zowel AspectJ als JBoss AOP ondersteunt. De eerste twee paragrafen behandelen de fundamentele begrippen op het gebied van aspectgeoriënteerde technologie en debugging. De derde paragraaf behandelt het probleem en de vereisten die eigen zijn aan aspect debugging. Tot slot worden het doel en de aanpak toegelicht. 1.1 Aspecten De volgende paragraaf omvat een korte samenvatting van de belangrijkste terminologie op het gebied van aspectgeöriënteerde technologie. Aspectgeoriënteerde programmering is het antwoord op crosscuttingconcerns[11]. Dit zijn vereisten die niet modulariseerbaar zijn met klassieke technieken. Typevoorbeelden hiervan zijn logging, concurrency, distributie en persistentie. Een aspect is een samenhangend geheel van functionaliteiten die doorheen de structuur van de uitvoering ingeweven moeten worden. Dit is vergelijkbaar met een klasse. Net zoals klassen kunnen aspecten velden en methoden hebben en abstract zijn. In tegenstelling tot klassen kunnen aspecten niet door de programmeur geïnstantieerd worden: een aspect bepaalt zelf wanneer een instantie aangemaakt moet worden. Aspecten hebben adviezen. Dit zijn functionele eenheden die elders in de uitvoering ingevoegd kunnen worden. Dit is vergelijkbaar met een methode. Een fundamenteel verschil is dat een advies niet aangeroepen kan worden maar ingeweven wordt. Om te bepalen waar adviezen moeten inwerken zijn er joinpoints. Een joinpoint is een gebeurtenis of locatie in het programma waarop een advies kan aangrijpen. Een methodeoproep of toekenning aan een veld zijn voorbeelden van joinpoints. 5

7 HOOFDSTUK 1. INLEIDING 6 Een pointcut is een conditionele expressie waaraan een bepaalde set van joinpoints voldoet. Door een pointcut aan een advies te binden, wordt bepaald op welke joinpoints het advies ingeweven wordt. Wanneer een advies toegepast wordt op een joinpoint spreekt men van een adviestoepassing. Wanneer meer dan één advies aangrijpt op één zelfde joinpoint ontstaat er een advies keten. De volgorde binnen de keten wordt bepaald door de onderlinge voorrangsregels tussen aspecten. Zoals eerder aangehaald zijn aspecten zelfinitialiserend. De aspect scope bepaalt wanneer er een instantie moet worden aangemaakt. Tabel 1.1 beschrijft de verschillende scopes. naam verklaring synoniemen vormen singleton er is maar één instantie per VM per VM per class voor elke klasse is er één instantie per object voor elk object is er één instantie per instance per this per target per joinpoint voor elk joinpoint is er één instantie per joinpoint class voor elk joinpoint is er één instantie die gedeeld wordt tussen alle instanties die van dezelfde klasse zijn per CFLOW telkens als in een thread een bepaalde pointcut gepasseerd wordt, wordt er een nieuwe instantie aangemaakt Tabel 1.1: Aspect scopes en hun betekenis Figuur 1.1: Statisch ER model van aspectsystemen

8 HOOFDSTUK 1. INLEIDING 7 In dit basismodel ontbreken nog twee belangrijke elementen die we in de hedendaagse AO-systemen terugvinden: ITD en CFLOW. ITD staat voor inter type declaration. ITD s zijn declaraties binnen een aspect die in staat zijn de type structuur van een andere klasse aan te passen. Dit kan bestaan uit het toevoegen van methoden, velden en interfaces, het relaxeren van de foutpropagatie of het toewijzen van een andere superklasse. CFLOW is het gebruik van controleflow informatie in pointcuts. Dit komt erop neer dat een advies slechts uitgevoerd wordt als de uitvoeringsstapel van de huidige thread in een bepaalde toestand is. 1.2 Debugging Een groot probleem bij het zoeken naar fouten in software is het feit dat een programmeur de interne toestand van het programma niet kan onderzoeken. Een mogelijke oplossing hiervoor is println debugging: het invoegen van instructies die op bepaalde punten in de uitvoering gegevens uitprinten. Dit is natuurlijk een gevaarlijke manier van debugging omdat het programma ervoor aangepast moet worden. Een betere aanpak is debugging met een debugger. Een debugger is in staat het programma stil te zetten als aan bepaalde voorwaarden voldaan is. De programmeur kan dan, via de debugger, de interne toestand onderzoeken. Dit soort debugging vereist geen expliciete aanpassing aan het basisprogramma en de inspectie kan veel preciezer gedaan worden. Het meest vanzelfsprekende model voor een debugger is een gebruikersgericht programma, zoals bijvoorbeeld de Eclipse Java debugger[8]. Hier wordt er zoveel mogelijk aan de gebruiker overgelaten: er zijn breekpuntbreekpunten om de uitvoering stil te zetten en er is de mogelijkheid tot inspectie van objecten, maar het is niet mogelijk de type structuur te inspecteren. Het is wel zo dat men voor elk type een overzicht van de velden en methoden kan zien, maar dit is volledig van de broncode afhankelijk. Als de broncode en bytecode niet overeenkomen is de informatie fout. Een complexer model, dat meer consistentiegaranties geeft, is spiegel-reflectie [4]. Een spiegeldebugger is in staat een model op te bouwen van het onderzochte programma. Dit model bevat één object voor elke entiteit in het onderzochte programma. Het spiegelmodel kan ondervraagd worden om zo de toestand van het onderzochte programma te onderzoeken. Om het model in stand te houden, is er natuurlijk een zekere overhead. Het bewaren van de consistentie maakt het ontwikkelen van spiegeldebuggers veel complexer dan de puur gebruikersgerichte debuggers. Een voorbeeld van een spiegel-api is JDI[9]. De paper van Bracha[4] over spiegel-reflectie geeft een aantal principes voor het ontwerpen van een spiegel-api. De vier belangrijkste zijn: encapsulatie, stratificatie, structurele correspondentie en temporele correspondentie. Encapsulatie : de debugger moet zijn implementatie verbergen; Stratificatie : de debugger moet los staan van de taal;

9 HOOFDSTUK 1. INLEIDING 8 Structurele correspondentie : de structuur van de debugger moet overeenkomen met de structuur van de taal; Temporele correspondentie : de API moet zo gelaagd zijn dat er een verschil is tussen statische en dynamische functionaliteiten. 1.3 De vereisten van de aspectdebugger De programmeur wil dus de interne structuur van zijn programma s kunnen inspecteren. Bij OO-talen is het niet zo belangrijk dat er een overzicht is van de controleflow en type informatie, omdat deze informatie allemaal beschikbaar is in de broncode: als je weet welke lijn in de broncode de laatst uitgevoerde is, weet je ook waar alle gerelateerde broncode zich bevindt. Bij AO-talen is dit echter niet meer zo: ITD s kunnen de type structuur aanpassen en adviezen kunnen de controleflow ombuigen. Met een AO-debugger wil de programmeur kunnen zien waar aspecten inwerken en hoe. Een tweede punt dat aspectdebugging typeert, is dat de machinecode die na compilatie ontstaat structureel verschillend kan zijn van het geschreven programma, omdat er adviezen en ITD s zijn ingevoegd. Dit zorgt soms voor uitermate complexe machinecode, die in een basistaal-debugger heel moeilijk te begrijpen is. De interne toestand van de taalmechanismen is niet verborgen of verwerkt tot een duidelijk formaat. Om deze problemen op te lossen, stel ik vier aandachtspunten voor:structurele reflectie, Zichtbaarheid, Traceerbaarheid en Inkapseling Structurele reflectie Om de gebruiker in staat te stellen zijn idee te toetsen aan de toestand van het programma, is het in de eerst plaats belangrijk dat de verschillende structuren van het programma onderzocht kunnen worden. We kunnen drie belangrijk structuren onderscheiden: statische structuur : typeinformatie met eventuele ITD s; runtime structuur : de toestand van de uitvoeringsstapel en de waarden van alle velden en variabelen; cross cutting structuur : de inwerking van alle aspecten. Er zijn OO debuggers die structurele reflectie aanbieden, zoals JDI, of pseudo structurele reflectie, zoals Eclipse jdt debugging[8], die zijn structurele reflectie baseert op de broncode. Natuurlijk is er nog geen ondersteuning voor ITD s of cross cutting Zichtbaarheid Zichtbaarheid is de mogelijkheid om runtime-entiteiten terug te brengen tot taalentiteiten en hun lijnnummers. Zichtbaarheid is in OO-debuggers meestal zeer goed ondersteund als het over lijnnummers van instructies gaat, als het over andere entiteiten gaat echter niet. Bij OO debuggers is dit ook niet nodig omdat de broncode coherent

10 HOOFDSTUK 1. INLEIDING 9 is en alle relevante instructies dus in de buurt van de huidige instructie staan of in een ouderklasse. Bij AO-debuggers is het belangrijk dat alle entiteiten terug te brengen zijn tot lijnnummers, omdat ITD s entiteiten kunnen induceren in andere klassen Traceerbaarheid Traceerbaarheid is de mogelijkheid om de controleflow te inspecteren. In Eclipse en JDI wordt traceerbaarheid verwezenlijkt door een overzicht van alle stackframes in alle threads. Dit is ook bruikbaar voor een AO debugger, maar er moeten wel aangegeven worden waar de controleflow wordt aangepast door adviezen Inkapseling Om een duidelijk beeld van een programma te geven is het belangrijk dat we geen informatie laten doorlekken over structuren die niet voorkomen in het programma. Alle extra code die de weaver heeft aangemaakt, moet dus verborgen worden. Dit volgt ook uit het principe van de structurele correspondentie voor spiegel-api s: elke taal moet zijn eigen spiegel-api hebben en er mogen geen details uit de onderliggende taal doorlekken, zelfs niet als dit betekent dat er een heel raamwerk aan het oog moet onttrokken worden. De onderliggende structuur, zij het een taal, zij het een raamwerk, wordt verondersteld foutloos te werken. De debugger staat in voor het onttrekken van de juiste gegevens op een transparante manier. 1.4 Het doel van de thesis Uit het voorgaande valt af te leiden dat aspect debugging op zich een probleem vormt met duidelijk vereisten. Het is eigenlijk een zeer breed probleem met verschillende facetten: de communicatie met de gebruiker, de verwerking van de gegevens, het verzamelen van de gegevens en het (meta-)modelleren van de taal of taalfamilie. Langs de ander kant zijn er ook vele aspectgeoriënteerde talen. Het is niet mogelijk al deze problemen op te lossen binnen het bestek van deze thesis. Ik heb dus voor een specifiek deelprobleem gekozen: het construeren van een multiplatform spiegeldebugger. Dit omhelst dus niet de communicatie met de gebruiker, maar wel het modelleren van de taal en het verzamelen en verwerken van de debugging informatie en dat voor meer dan één taal. Het hoofddoel van mijn thesis is het onderzoeken van de mogelijkheden en knelpunten bij het bouwen van zo een debugger. Ik probeer dus niet zo veel mogelijk functionaliteit te implementeren, maar zoek een evenwicht tussen de meerwaarde voor de gebruiker, de haalbaarheid en de impact op de architectuur. Ik wil de architectuur zo veel mogelijk op de proef stellen, maar toch tijdig eindigen met een afgewerkt en nuttig geheel.

11 HOOFDSTUK 1. INLEIDING Aanpak Om zicht te krijgen op de problemen en mogelijkheden bij het bouwen van een multiplatform spiegeldebugger, zal ik een spiegeldebugger bouwen, die bruibaar is voor meerdere talen. Omdat een spiegeldebugger altijd nood heeft aan een accuraat taalmodel, is het niet zinvol is een spiegel-api te maken voor talen die niet semantisch gelijkaardig zijn. Ik beperk mij dus tot een familie van Java-gebaseerde talen die sematisch gelijkend zijn aan AspectJ. De eerste stap is het ontwerpen van een spiegel-reflectie gebaseerde debugging architectuur: de AO-debugging architecture (AODA). Deze architectuur omvat een spiegelmodel (AJDI) van de ondersteunde taalfamilie en een implementatie van de taalonafhankelijke componenten van de debugger (ADB). Daarna valideer ik de architectuur voor AspectJ en JBoss AOP door de taal afhankelijke componenten van de architectuur uit te werken. AspectJ is de eerste validatie, met een vrij brede ondersteuning. JBoss is de tweede validatie, die vooral moet aantonen dat de architectuur herbruikbaar is. Het is dus niet de bedoeling functionaliteit te ondersteunen waarvan de moeilijkheid vooral ligt in het onttrekken van informatie aan JBoss 1.6 Tekststructuur Hoofdstuk 2 brengt de beginselen aan van de gebruikte technolgie (AspectJ en JBoss), de ondersteunende technologie (JDPA) en de bestaande AO debugging technologie. Hoofdstuk 3 beschrijft en evalueert in detail de architectuur. Hoofdstuk 4 beschrijft en evalueert de validatie voor AspectJ. Dit omvat ook een gedetaileerde beschrijving van de werking van de ABC-compiler. Hoofdstuk 5 beschrijft en evalueert de validatie voor JBoss AOP. Dit omvat ook een gedetailleerde beschrijving van de werking van de relevante onderdelen van JBoss AOP. Hoofdstuk 6 tracht een conclusie te formuleren over de knelpunten en sterkten van de architectuur. Om het lezen van de tekst makkelijker te maken is achteraan een woordenlijst en een afkortingenlijst toegevoegd.

12 Hoofdstuk 2 Bestaande technologie Dit hoofdstuk omschrijft de belangrijkste technologieën die in mijn thesis gebruikt worden. Eerst komen de ondersteunde talen aan bod: AspectJ en JBoss AOP. Van de talen wordt telkens de syntaxis en semantiek, het joinpoint model en de bestaande ondersteuning voor debugging besproken. Dan komt de ondersteunende technologie aan bod: de Java Platform Debugging Architectuur(JPDA). Tot slot worden ook nog kort twee andere mogelijke werkwijzen voor aspectdebugging behandeld. 2.1 AspectJ AspectJ is een taaluitbreiding op Java, die buiten de normale Java syntaxis ook een syntaxis voor aspecten aanbiedt. Het is een levende taal : er worden nog steeds mogelijkheden aan toegevoegd. AspectJ is vooral gericht op het aanbrengen van aspecten bij de compilatie. In dit hoofdstuk zal ik de belangrijkste mogelijkheden van versie overlopen Syntaxis en Semantiek Zoals in Listing 2.1 te zien is, worden aspecten gedefinieerd zoals klassen. Aspecten kunnen methodes en velden hebben en abstract zijn. Ze kunnen overerven van klassen, abstracte aspecten en interfaces. Een aspect mag slechts één constructor aanbieden en deze mag geen argumenten hebben. Klassen kunnen nooit overerven van aspecten. Een aspect kan een willekeurig aantal adviezen declareren. Aspecten kunnen ook hun onderlinge voorrang declareren. Hiermee kan bepaald worden welk advies eerst moet uitgevoerd worden, als er meerdere adviezen inwerken op één joinpoint. Aspecten kunnen ook privileged zijn, dit wil zeggen dat ze toegang hebben tot de private velden van andere klassen en aspecten. Een advies kan before, after, after throwing, after returning en around zijn. Before advice wordt uitgevoerd voor het joinpoint waarop het wordt toegepast. After advice 11

13 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 12 Listing 2.1: AspectJ code sample 1 package sample ; 2 3 public aspect Sample1 { 4 pointcut stringmethod ( String s): 5 call (* method *( String )) && args (s); 6 7 before (): execution ( String method *()) { 8 System. out. println (" called "); 9 } before ( String s): stringmethod (s){ 12 System. out. println (" called 2 " + s); 13 } 14 } wordt uitgevoerd na het joinpoint, ongeacht of de terugkeer normaal was of exceptioneel. After throwing advice en after returning advice worden ook uitgevoerd na het joinpoint, maar enkel als de terugkeer respectievelijk normaal of exceptioneel was. Around advice wordt uitgevoerd in plaats van het joinpoint. Bij around advice is de speciale functie proceed() beschikbaar waarmee men de normale uitvoering kan voortzetten. Hiermee bedoel ik het volgende advies op het zelfde joinpoint uitvoeren of, als er geen volgend advies meer is, de code van het joinpoint uitvoeren. Elk advies is gebonden aan juist één pointcut. De pointcut kan argumenten doorgeven aan het advies. De argumenten moeten juist getypeerd zijn, anders zal het advies niet uitgevoerd worden. Deze typering wordt uitgevoerd door de compiler en is dus statisch. Een advies kan beschikken over informatie van het joinpoint waarvoor het uitgevoerd wordt door de referenties thisjoinpoint en thisjoinpointstaticpart. Elk joinpoint heeft een this en een target referentie om, respectievelijk, naar de uitvoerder en het doel van uitvoering te verwijzen. Een advies kan gebruik maken van deze twee referentie via de thisjoinpoint referentie. Elk aspect kan een willekeurig aantal pointcuts definiëren. Deze kunnen een naam hebben als ze direct onder het aspect gedefinieerd zijn (zoals stringmethod in het voorbeeld) of anoniem zijn, als ze deel uitmaken van een adviesdeclaratie. In een abstract aspect kunnen abstracte pointcuts voorkomen. Door een advies te binden aan een abstracte pointcut kan men een advies één keer definiëren en meerdere keren binden. Hierdoor kan men herbruikbare aspecten maken zonder meervoudige of externe binding toe te staan. Aspecten kunnen vier verschillende scopes hebben: singleton, per this, per target en per CFLOW. De scope bepaalt welke aspectinstantie het huidige aspect is. Als er geen huidig aspect is, worden er geen adviezen uitgevoerd.

14 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 13 Singleton wil zeggen dat er één instantie is per VM en het huidige object altijd hetzelfde is. De per CFLOW scope heeft een pointcut als argument. Telkens de controleflow een joinpoint binnengaat dat deze pointcut matcht, wordt er een nieuwe instantie op een stack geduwd. Als het joinpoint weer verlaten wordt, wordt de instantie weer van de stack gehaald. Het bovenste element van de stack wordt altijd gebruikt als het huidige aspect. Per target en per this hebben ook een pointcut als argument. Als de controleflow een joinpoint binnen gaat dat deze pointcut matcht, wordt een instantie van het aspect verbonden aan respectievelijk het this- of targetobject van deze joinpoint. Het huidige aspect op elk gegeven joinpoint is dat aspect dat verbonden is met respectievelijk het this of target object van dat joinpoint. AspectJ ondersteunt ook ITD s: elk aspect kan velden, methodes, interfaces en constructoren invoegen bij klassen of interfaces. Het is zelfs mogelijk om de ouderklasse van een klasse aan te passen. CFLOW is natuurlijk ook ondersteund: uit elke basis-pointcut kan een CFLOWpointcut afgeleid worden. Een CFLOW-pointcut matcht elke andere joinpoint wanneer het basis-joinpoint op de uitvoeringsstapel staat. Als de basis-pointcut argumenten heeft, die de CFLOW-pointcut gebruikt, dan worden deze op een stack geduwd voor het begin van de basis-joinpoint en er weer af gehaald nadat de basisjoinpoint verlaten wordt. Tot slot zijn er nog de statische mogelijkheden van AspectJ: declare error en declare warning. Hiermee genereert de compiler een waarschuwing of fout wanneer een bepaalde pointcut toegepast wordt. Soften exception is een andere statische feature: hiermee kan men checked Exceptions omzetten in RuntimeExceptions Joinpoint Model Het joinpointmodel van AspectJ omvat zes joinpointtypes, met elk een of meerdere varianten. In dit paragraaf zal ik deze overlopen. method omvat de uitvoering van methoden en heeft twee varianten. call omvat het aanroepen van de methode. Het joinpoint omvat dus de instructies die de methode-oproep realiseren. De thisreferentie van dit soort joinpoint refereert naar het aanroepende object en de targetreferentie naar het aangeroepen object. execution omvat het uitvoeren van de methode. De joinpoint omvat dus het lichaam van de methode. De this- en targetreferentie van dit soort joinpoint refereren beide naar het aangeroepen object constructor omvat de uitvoering van constructoren en heeft twee varianten. call omvat het aanroepen van de constructor. Het joinpoint omvat dus de instructies die de constructoroproep realiseren. De thisreferentie van dit soort

15 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 14 joinpoint refereert naar het aanroepende object en de target-referentie is onbestaand omdat het doelobject nog niet is aangemaakt. execution omvat het uitvoeren van de constructor. De joinpoint omvat dus het lichaam van de constructor. De this- en targetreferentie van dit soort joinpoint refereren beide naar het aangeroepen object initialisation omvat de initialisatie van klassen en objecten en heeft drie varianten. sinit omvat het uitvoeren van de statische initialisatie van een klasse. De context is statisch, dus er is geen this- of targetreferentie beschikbaar. init omvat het initialiseren van de klasse, of met andere woorden, het uitvoeren van elke constructor van de klasse. Als een constructor een andere constructor aanroept, wordt dit joinpoint geen tweede keer binnen gegaan. Dit is het grote verschil met constructor execution joinpoints. De this- en targetreferentie verwijzen naar het uitvoerende, nieuwe object. pinit omvat de pre-initialisatie van een klasse: dit zijn de instructies die zich in de constuctor bevinden voor de aanroep van een super (of this) constuctor. De this- en targetreferentie zijn niet beschikbaar. field omvat de toegang tot velden en heeft twee varianten. ref omvat het lezen uit een veld. De thisreferentie refereert naar de aanroepende klasse en de targetreferentie naar de klasse die het veld bevat. set omvat het schrijven naar een veld. De thisreferentie refereert naar de aanroepende klasse en de targetreferentie naar de klasse die het veld bevat. advice omvat de uitvoering van adviezen en heeft één variant. execution komt overeen met methode execution, maar dan voor adviezen in plaats van methoden. De this- en targetreferentie refereren dus naar het uitvoerende aspect. handler omvat de uitvoering van exception handlers en heeft één variant. execution omvat het lichaam van een exception handler. De this- en targetreferentie refereren dus weer naar het uitvoerende aspect. Voor meer details kan u de AspectJ programming guide raadplegen[15] Bestaande ondersteuning voor debugging AspectJ is een onderdeel van Eclipse en wordt er dus goed door ondersteund. Het AJDT project[1] onderhoudt niet enkel de compiler, maar ook een toolset. Op basis van de broncode kan de cross cutting en type-informatie weergegeven worden. Als de versie van de broncode en de bytecode verschillen kan deze informatie fout zijn. Voor al deze informatie kan de broncode locatie aangegeven worden. Lijnnummers, de stacktrace en

16 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 15 instantie-informatie worden op basis van JDI aangemaakt en deze worden als ongefilterde Java-gegevens weergegeven. 2.2 JBoss JBoss AOP is een van de belangrijkste onderdelen van de JBoss Application server. Het wordt actief verder ontwikkeld. Omdat het intensief gebruikt wordt in een middleware platform is de code geoptimaliseerd en bestaat er veel legacy code. De documentatie is eerder beperkt: de architectuur is grotendeels onbeschreven en de gebruikersdocumentatie is helemaal niet meer up-to-date. In deze thesis gebruik ik de SVN-versie Ik gebruik een SVN-versie omdat de volgende major release niet meer op tijd komt voor mijn thesis en omdat de code bruikbaarder is dan de vorige release. De code is meer actueel, gestructureerd en de gegevensstructuren zijn beter toegankelijk voor de debugger. Helaas is de documentatie schaars Syntaxis en Semantiek JBoss AOP is een raamwerk gebaseerd op Java. Er wordt gebruik gemaakt van gewone Java-code en een configuratie in XML of met Java-annotaties. De configuratie kan ook programmatorisch tot stand gebracht worden, maar dit is zeer foutgevoelig. JBoss biedt een functionaliteit aan die nog niet eerder besproken is: interceptors. Hiermee bedoelt men een aspect met juist één advies. Listing 2.2: JBoss interceptor code sample 1 import org. jboss. aop. joinpoint. Invocation ; 2 import org. jboss. aop. advice. Interceptor ; 3 ( pointcut =" execution ( String Test -> method *()) ") 6 public class S implei nterce ptor implements Interceptor { 7 public String getname (){ return " S implei nterce ptor ";} 8 9 public Object invoke ( Invocation invocation ) 10 throws Throwable { 11 System. out. println (" called "); 12 return invocation. invokenext (); 13 } 14 } Zoals te zien in Listing 2.2 is een interceptor een klasse die de interface org.jboss.- aop.advice.interceptor implementeert. Het enige advies van dit aspect heet invoke. De

17 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 16 Listing 2.3: JBoss intreceptor code sample 1 <? xml version =" 1.0 " encoding ="UTF -8"?> 2 <aop > 3 <bind pointcut =" execution ( String Test -> method *()) "> 4 < interceptor class =" SimpleInterceptor "/> 5 </ bind > 6 </ aop > invoke() methode heeft een argument van het type org.jboss.aop.joinpointinvocation. Dit Invocation-object bevat alle metadata en contextinformatie. Het Invocationobject kan ook gebruikt worden om invokenext() en invoketarget() aan te roepen. invokenext() roept het volgende advies aan en invoketarget() slaat alle volgende adviezen over en roept het joinpoint aan. Als de programmeur vergeet invokenext() of invoketarget() aan te roepen, wordt de advies keten gebroken. Het joinpoint wordt dan nooit uitgevoerd. De geeft aan dat dit een interceptor is. annotatie geeft de binding aan. Een alternatieve notatie is te zien in Listing 2.3. Door gebruik te maken van XML kan de configuratie aangepast worden zonder in de code te moeten graven. Gewone aspecten bestaan uit klassen die meerdere methoden bevatten die een Interceptor-argument aanvaarden. Om uit deze klassen een aspect te vormen kan de naam van de klassen meegegeven worden via een annotatie of XML. Een ander optie is het doorgeven van de naam van een factoryklasse. Deze factory wordt aangeroepen telkens er een aspectinstantie nodig is. Het is mogelijk om superinterfaces van Interceptor als argument voor een advies te gebruiken. Dan wordt dit advies enkel aangeroepen als het Invocation object een instantie van dat specifiek subtype is. Men kan dus ook adviezen overloaden. De exacte semantiek hiervan is zeer slecht gedocumenteerd. De huidige versie van JBoss AOP bevat fouten in de code die dit gedrag bestuurt, dus de juiste werking is niet volledig duidelijk. Net zoals in AspectJ is het mogelijk om de voorrang tussen aspecten (en interceptors) te regelen met de precedence-constructie. JBoss AOP ondersteunt ook ITD s in de vorm van interface introductions, annotation introduction en mixins. Interface introductions staan in voor het toevoegen van interfaces aan klassen. Annotation introduction laat toe annotaties in te voegen en mixin compositie laat toe om zowel een interface als een implementatie toe te voegen aan een klasse. Ook CFLOWwordt ondersteund door de constructie CFLOW-stack. Hiermee kan men een patroon definiëren waaraan stack moet voldoen voor het advies uitgevoerd wordt. Dynamische residu s worden ook ondersteund door de constructie dynamic- CFLOW. Hiermee kan men willekeurige code laten uitvoeren om te bepalen of een advies

18 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 17 uitgevoerd moet worden. De code moet verpakt worden in de shouldexecute() methode van een klasse van het type org.jboss.aop.pointcut.dynamiccflow. In JBoss AOP kan de configuratie on-the-fly aangepast worden: adviezen kunnen toegevoegd of verwijderd worden op bestaande joinpoints. Er kunnen echter geen nieuwe joinpoints toegevoegd worden. Om een joinpoint dat geen enkel advies heeft toch te laten voorbereiden voor gebruik bestaat de prepare-constructie. Net zoals bij AspectJ zijn er nog de statische mogelijkheden: declare error en declare warning. Hiermee genereert het raamwerk een waarschuwing of fout wanneer een bepaalde pointcut toegepast wordt. In tegenstelling tot AspectJ heeft JBoss AOP ook ondersteuning voor het gebruik van metadata: adviezen kunnen metadata doorgeven aan elkaar. Bij het initialiseren van aspecten kunnen metadata uit verschillende bronnen uitgelezen worden Joinpointmodel Het JBoss AOP joinpointmodel biedt geen this- of targetreferentie aan. Het Invocationobject dat bij een joinpoint hoort, heeft specifieke methoden om de context op te vragen die afhangen van het joinpointtype. Het joinpointmodel met de aangeboden contextmethoden is te zien in figuur 2.1. Het model lijkt erg op dat van AspectJ, maar is semantisch verschillend. Figuur 2.1: JBoss joinpointmodel

19 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 18 De joinpoints die het meest overeenkomen met hun AspectJ-equivalenten zijn de constructor en method call joinpoints. Ze hebben een doel en een oproeper en worden ingeweven in de oproeper. De structuur is in 4 gesplitst om meer precieze context methoden te kunnen aanbieden, die een onderscheid maken tussen methoden en constructoren. Het method execution joinpoint is ook niet erg verschillend. Het joinpoint omvat de uitvoering van een methode en wordt ingeweven in die methode. Het constructor execution joinpoint daarentegen vertoont wel een verschilend gedrag. Het joinpoint omvat de constructor en wordt daarin aangeroepen, maar beinvloedt ook de instructies waardoor de constructor aangeroepen wordt. Het construction joinpoint komt overeen met het constructor execution joinpoint van AspectJ. Het wordt ingeweven in de constructor en beïnvloed de aanroepende klassen niet. Uiteindelijk is er ook nog field access. Hier zijn zoals in AspectJ twee subtypen. Het ene is schrijftoegang, het andere leestoegang Bestaande ondersteuning voor debugging Voor zover wij weten, is er geen specifieke ondersteuning beschikbaar voor JBoss. Er is in de documentatie[10] sprake van een JBoss AOP IDE Eclipse plug-in. Deze plug-in bestaat niet meer en is opgenomen in de JBoss Tools. Deze bieden ondersteuning voor JBoss, maar niet voor AOP debugging. Er zijn ook referenties naar een management bean die in staat is om de informatie over de cross cutting weer te geven. Hierover is verder geen informatie terug te vinden. Er zijn verschillende pagina s op de site van JBoss over AOP debugging, de meeste zijn al meer dan drie jaar niet bijgewerkt. De werkwijze die daar gepromoot wordt is het gebruik van een standaard Java debugger. Gegeven de complexiteit van JBoss AOP is dit zeer onproductief. Println debugging is waarschijnlijk de beste oplossing. 2.3 Java Platform Debugging Architecture De Java Platform Debugging Architecture(JPDA)[9] is de standaardarchitectuur voor Java-debugging. Zoals te zien in figuur 2.2 bestaat de architectuur uit drie delen: JVM- TI, JDWP en JDI. De volgende paragrafen behandelen deze onderdelen JVM Tool Interface De JVM-TI is een native interface die aangeboden wordt door de JVM. Als de JVM opstart, kunnen er een of meerdere agenten ingeladen worden die dan de JVM-TI kunnen gebruiken. De JVM-TI laat de agenten toe om de JVM te monitoren zonder deze al te veel te vertragen. De agenten zijn in C geschreven (native) en zijn dus platform afhankelijk. De agenten kunnen op 3 manieren aan informatie komen. Ten eerste zijn er 31 verschillende soorten events die de JVM kan doorgeven naar de agenten. Ten tweede is er de mogelijkheid om de JVM te ondervragen. Ten derde is er de mogelijkheid

20 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 19 Figuur 2.2: Overzicht van de Java Platform Debugging Architecture om bytecode te instrumenteren. Dit wil zeggen het invoegen van instructies in de bestaande bytecode. Hierdoor kan men de bytecode zelf events laten uitsturen waardoor er geen contextwissel moet gebeuren naar de agent. Voor systemen met zeer regelmatige eventpatronen zoals profilers en omniscient debuggers zorgt dit voor een grote tijdswinst Java Debug Wire Protocol JPDA voorziet zelf een JVM-TI agent die met elke JVM meegeleverd wordt. Deze agent kan bestuurd worden met het Java Debug Wire Protocol(JDWP). De agent kan gebruikt worden om normale debugging functionaliteit aan te bieden. JDWP laat de transportlaag ongedefinieerd. De meest gebruikte transportmedia zijn natuurlijk TCP voor remote debugging en shared memory voor lokale debugging. JDWP is een binair protocol en dus niet leesbaar zonder cliënt die instaat voor de marshaling en unmarshaling van de gegevens. Er wordt gewerkt met twee soorten pakketten: command en response. Zowel de agent als de debugger kunnen beide soorten paketten uitsturen en de volgorde is niet vastgelegd. Elke response wordt gelinkt aan zijn command door een uniek volgnummer. Events kunnen aangevraagd worden door de debugger aan de agent, deze antwoordt dan met een uniek volgnummer voor het request. Elk event dat uitgestuurd wordt, is een commando van de agent naar de debugger waarop geen antwoord komt. Elk event zal het volgnummer van zijn request dragen. Events worden altijd in sets uitgestuurd, zodat gelijktijdige events ook als dusdanig behandeld worden. Elke referentie naar een object of een type wordt door JDWP behandeld als een uniek nummer. Om meer informatie te bekomen moeten er meerdere berichten uitgewisseld worden.

21 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE Java Debug Interface JDI is de standaard spiegel-api voor Java. De standaardimplementatie is een JDWP cliënt. De implementatie staat in voor het correct gebruikt van JDWP, caching en het aanbieden van een bruikbaarder eventsysteem. JDI bestaat uit meer dan honderd interfaces die de structuur van Java modeleren. Het centrale spiegelobject is de afspiegeling van de JVM: VirtualMachine. Dit spiegelobject kan men bekomen door met de VirtualMachineManager een connectie op te zetten met een JDWP-agent. In figuur 2.3 kan men de belangrijkste delen van JDI terugvinden. De structuur van Java is er makkelijk in terug te vinden. Alle verbanden tussen afspiegelingen van types zijn navigeerbaar langs beide zijden. Het verband tussen een afspiegeling van een waarde en die van haar type is slechts navigeerbaar van waarde naar type. De afspiegeling gaat niet tot op instructieniveau. De link tussen entiteiten en broncodelocaties bestaat enkel voor instructiegerelateerde entiteiten: StackFrames, Events en Methods. StackFrame is een belangrijke entiteit die niet in de taal Java voorkomt. Elke afspiegeling van een thread heeft een lijst met StackFrames die de huidige toestand van de stack voorstellen en inspectie van de uitvoering toelaten. Buiten de afspiegeling van het programma is er ook nog het eventsysteem waarmee een debugger zich kan inschrijven voor bepaalde events. De meest belangrijke zijn class prepare, method entry, location breakpoint en step. 2.4 Alternatieve debugging strategieën Volgende paragrafen behandelen twee alternatieve debugging strategiëen: source weaving en omniscient debugging Source Weaving Source weaving is een techniek waarbij de broncode wordt geweven, in plaats van de bytecode. Hierdoor bewaart de programmeur makelijk het overzicht. De geweven broncode is ook gelinkt aan de originele broncode. Het grote nadeel is dat source weaving niet altijd bruikbaar is, omdat de meeste systemen inherent bytecode weavers zijn. Een voorbeeld van een krachtige source weaver is Wicca [5]. Helaas ondersteunt deze debugger enkel zijn eigen specifieke taal Omniscient debugging Omniscient debugging, of alwetende debugging, is een debugging strategie waarbij men de volledige toestand van een programma opslaat tijdens de gehele uitvoering. Hierdoor zijn alle gegevens altijd beschikbaar en kan men vrij door de executie bewegen, voorwaarts en achterwaarts in de tijd. Het is dus zeer simpel om oorzaken van fouten op te sporen, zelfs als deze in het verleden liggen.

22 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 21 Figuur 2.3: Overzicht van de belangrijkste JDI interfaces

23 HOOFDSTUK 2. BESTAANDE TECHNOLOGIE 22 Deze techniek is extreem krachtig voor elke soort van debugging en dus ook voor AOdebugging[14]. Het grote nadeel is dat het opnemen van de volledige toestand van een programma extreem veel gegevens voortbrengt. Deze gegevens moeten zo opgeslagen worden dat ze nog makkelijk doorzocht kunnen worden, maar het wegschrijven moet toch voldoende snel gebeuren. Dit wil zeggen dat omiscient debugging over langere tijd of van grotere systemen dedicated hardware vereist, wat niet altijd haalbaar is. Dit is een zeer krachtige en geavanceerde techniek, toch kan deze thesis een contributie zijn voor omniscient debugging, meer bepaald op het gebied van aggregatie van aspectgeoriënteerde gegevens. Een omniscient debugger mag dan alles weten, hij is niet noodzakelijk in staat om de juiste informatie uit de gegevens te halen.

24 Hoofdstuk 3 Architectuur De architectuur(aoda) die ik voorstel bied een spiegel-api(ajdi) aan die steunt op JDI. De architectuur heeft 4 belangrijke componenten: de Java debugging interface(jdi), de aspect Java debugging interface (AJDI), de aspectdebugger(adb) en de ADB-backend. De grijze onderdelen maken deel uit van JPDA, de Java platform debugging architecture en zijn dus niet door mij ontworpen. Figuur 3.1: Algemeen architectuur overzicht JDI (3) is de interface waarmee de standaard debugging mogelijkheden van de JVM aangesproken kunnen worden. Dit werd al besproken in paragraaf AJDI (1) is de spiegel-api die aan de gebruiker zal blootgesteld worden. Het is een op JDI gebaseerde set van interfaces, die meer in detail besproken zal worden in paragraaf ADB (2) is de implementatie van AJDI die instaat voor het aggregeren van alle debuginformatie, het bewaren van de consistentie en caching van gegevens. Dit wordt 23

25 HOOFDSTUK 3. ARCHITECTUUR 24 mee in detail besproken in paragraaf ADB-back-end interface (4) is een set van interfaces waarmee de aspectdebugger (ADB) debuginformatie kan opvragen op een doelplatform onafhankelijk manier. Dit wordt besproken in paragrafen en Agent (7) is de component die instaat voor het verzamelen van debuginformatie. Elke agent heeft zijn eigen agent protocol(6) om met de ADB-back-end(5) te communiceren. De ADB-back-end zet deze agent informatie om naar de neutrale ADB-back-end interface. Dit wordt meer in detail besproken in paragraaf De rest van dit hoofdstuk licht de architectuur verder toe. Eerst wordt de rationale toegelicht. Daarna worden alle ondersteunbare functionaliteiten overlopen en hieruit wordt een subset gekozen die ik zal proberen te implementeren. Dan worden de beperkingen overlopen die aan de architectuur opgelegd worden om de complexiteit te beheersen. Daarna wordt elke onderdeel in detail uitgewerkt. Vervolgens worden de zwakheden van de architectuur, die door de validatie aan het licht zijn gekomen, overlopen. Tot slot volgt een conclusie. 3.1 Rationale De architectuur steunt op twee fundamentele beslissingen: het gebruik van JDI en de verdeling in een back-end en een front-end. In de volgende paragrafen zal ik deze beslissingen toelichten en uitdiepen Het gebruik van JDI De Java Platform Debugging Architecture geeft ons de mogelijkheid om op drie plaatsen informatie te verzamelen: JVM-TI, JDWP en JDI. Op elk van die punten is alle benodigde informatie verkrijgbaar. We moeten er dus de beste uitkiezen. Het eerste interceptiepunt is de JVM Tooling Interface die ons toelaat een agent in de JVM te laden die daar alle bewerkingen kan volgen. De agent moeten in C geschreven worden en bij het opstarten van de JVM ingeladen worden. JVM-TI heeft als voordeel dat er zeer snel gereageerd kan worden met een lage overhead. Er is ook een ernstig nadeel: de agent moet in C geschreven worden, wat foutgevoeliger en platformafhankelijk is. Het tweede punt is het Java Debug Wire Protocol. Dit is een communicatieprotocol dat ons toelaat om met de standaard debuggingagent, die deel uit maakt van de meeste virtuele machines, te praten over verschillende transportprotocols. Dit interceptiepunt heeft als voordeel dat er op een laag niveau gewerkt kan worden, waardoor er veel controle en plaats voor optimalisatie is. Een ander voordeel is dat men zo de performante en betrouwbare standaard debuggingagent kan gebruiken. Het nadeel is dat de implementatie van de protocolcliënt van Sun Microsystems niet open source is, dus dat het protocol zelf volledig geïmplementeerd moet worden, wat tijdrovend en foutgevoelig is.

26 HOOFDSTUK 3. ARCHITECTUUR 25 Het derde punt is JDI, de Java debugging interface. Dit is een spiegel-api die steunt op een JDWP-cliënt. Het grote voordeel is dat JDI ons een betrouwbare spiegel-api geeft om mee van start te gaan. Het nadeel is dat die gaat over een honderdtwingtigtal interfaces die allemaal gewrapped moeten worden, wat veel werk is dat eigenlijk geen functioneel nut heeft. Het tweede probleem is dat JDI aan caching moet doen om zijn gegevens consistent te houden en dat ADB al dat werk moet overdoen. De keuze is op JDI gevallen omdat dit een stabiele en platform-onafhankelijke ondersteuning biedt. Het overdoen van caching en het maken van de wrappercode is misschien een spijtig tijdverlies en een zeer vervelend werkje, maar het is ook een veilige keuze die niet veel kansen heeft op fouten De splitsing front-end back-end Het is uiteindelijk de bedoeling verschillende Java-gebaseerde aspectsystemen te ondersteunen. Daarom is het interessant om alle doelplatform afhankelijke bewerkingen apart onder te brengen en de complexiteit zo goed mogelijk te verdelen. De front-end, ADB, wordt verantwoordelijk voor drie belangrijk taken: consistentie, caching en aggregatie. De back-end is verantwoordelijk voor het aanleveren van de juiste debuginformatie. De eerste taak van de front-end, het bewaren van de consistentie, is op zich een complexe taak met vele verschillende facetten. Het omvat hoofdzakelijk het aanmaken en relateren van spiegelobjecten. Omdat het niet de bedoeling is om de volledige toestand te weerspiegelen, moeten spiegelobjecten enkel aangemaakt worden indien nodig. De meeste relaties in een spiegel-api zijn langs beide zijden toegankelijk en er moeten dus veel dubbele bindingen in stand gehouden worden. Soms is de bindingspartner niet beschikbaar, omdat zijn klasse nog niet geladen is en zijn spiegelobject dus niet aangemaakt kan worden. Als dit gebeurt en de gebruiker vraagt het spiegelobject op, dan moeten de juiste excepties doorgegeven worden. Eventueel moet de gebruiker in staat zijn toch informatie in te winnen over de bindingspartner. Door de vele dubbele bindingen is het ook belangrijk dat elk spiegelobject uniek is en niet per ongeluk twee keer wordt aangemaakt. Anders kan er een ketting van conceptueel identieke objecten ontstaan, wat de performantie niet ten goede komt. Om uniciteit te verzekeren moet alles gecached worden zolang er minstens een referentie naar bestaat. Deze taak is dus voorbehouden voor de front-end. Om de splitsing goed te realiseren, is het belangrijk dat er zo weinig mogelijk AJDI objecten in de back-end terechtkomen. Als de back-end AJDI-objecten zou opvragen, ontstaat er een risico op oneindige lussen, omdat de informatie die nodig is om AJDI-objecten aan te maken uit de back-end moet komen. Om oneindige lussen te voorkomen zou de back-end moeten weten op welke volgorde objecten opgevraagd mogen worden zonder risico op lussen of schending van de caching consistentie. Dit zou de back-end heel complex, foutgevoelig en verweven met de front-end maken. De back-end interface moet zich dus zoveel mogelijk beperken tot primitieve data en specifieke, AJDI ongerelateerde structuren. De tweede taak van de front-end is caching van spiegelobjecten. Dit is niet enkel belangrijk voor de performantie, maar ook voor de consistentie. Zoals al eerder gesteld

27 HOOFDSTUK 3. ARCHITECTUUR 26 moet alles gecached worden zolang er minstens èèn andere referentie naar bestaat. Java biedt hier ondersteuning voor, via Java.lang.ref, maar het blijft een ongewone techniek. De derde en meest belangrijke taak voor de front-end is aggregatie van gegevens. Dit is het samenvoegen van de JDI spiegelobjecten met de back-endinformatie. Doordat een spiegel-api een gesloten geheel moet vormen en Java niet in staat is alle returntypes van JDI op een juiste manier te overriden moet JDI volledig gewrapped worden. (Zie paragraaf 3.5.2) De wrappercode vormt is een belangrijk onderdeel van de samenvoeging. Door de splitsing van front-end en back-end kan de wrappercode makkelijk herbruikt worden. Doordat de aggregatielogica in de front-end zit, kan de back-end interface heel concreet en duidelijk gemaakt worden, met korte, duidelijk queries. Dit schermt de backendprogrammeur goed af, zodat hij zich enkel moet bezighouden met het onttrekken en formateren van de gegevens. Dit verkleint de kans op onduidelijk en verweven backendcode. Hieruit volgt dat de back-end enkel instaat voor het echte werk: het verzamelen van aspectgerelateerde debuginformatie. In de back-end komen dus geen AJDI objecten voor, behalve in zeer specifieke, goed geïsoleerde, gevallen. De meeste back-ends hebben zelfs geen JDI objecten nodig om hun werk te doen. Deze splitsing stelt ons dus in staat om de complexiteit mooi te verdelen en code te herbruiken. 3.2 Ondersteunbare functionaliteiten De debugger kan een aantal verschillende functionaliteiten ondersteunen. Deze functionaliteiten zijn onderling gerelateerd. Ze kunnen afhankelijkheidsrelaties hebben met andere functionaliteiten als ze niet gerealiseerd kunnen worden zonder dat de andere al aanwezig zijn. Er kunnen ook consistentierelaties bestaan: als slechts een van de functionaliteiten beschikbaar is, zal er een inconsistentie ontstaan in de debuginformatie. Sommige functionaliteiten zijn ook onverenigbaar: als ze allebei voorkomen, zullen ze inconsistentie veroorzaken. In figuur 3.2 zijn de verbanden tussen de meest relevante functionaliteiten aangegeven. De vakjes binnen de zwarte kader bevinden zich op het niveau van AJDI, degene die er buiten staan op het niveau van JDI. De rode vakjes zijn functionaliteiten die niet aangeboden worden, de groene zijn wel geïmplementeerd. De zwarte pijlen geven functionele afhankelijkheid aan, de blauwe een consistentierelatie en de rode een consistentieconflict. (De functionaliteiten zijn zeker niet evenwaardig in belangrijkheid of in benodigde inspanning om ze te realiseren.) In de volgende paragrafen zal ik alle mogelijkheden uit het diagram bespreken en uitleggen waarom ik deze al dan niet geïmplementeerde heb. Type- en instantieafspiegeling zijn de meest fundamentele onderdelen. Ze voorzien de spiegelobjecten voor types en instanties. Deze functionaliteit wordt aangeleverd door JDI. Wrapping Om bruikbaar te zijn in AJDI moeten de JDI-spiegelobjecten gewrapped worden. Dit wil zeggen: herverpakt zodat ze open staan voor aanpassing en con-

28 HOOFDSTUK 3. ARCHITECTUUR 27 Figuur 3.2: Mogelijke functionaliteiten en hun onderlinge verbanden; zwarte pijlen: functionele afhankelijkheid; blauwe pijlen: consistentie afhankelijkheid; rode pijlen: consistentie conflict

29 HOOFDSTUK 3. ARCHITECTUUR 28 form AJDI zijn. Dit heb ik dan ook gedaan, omdat het de basis is voor de meeste andere mogelijkheden. Hierover is meer terug te vinden in paragraaf Aspect compositie informatie (ACI) is een grote uitbreiding van de afspiegeling van types die alle aspectgerelateerde informatie in het model inbrengt. Dit gaat over de typeinformatie van aspecten, het inwerken van adviezen, een basis voor pointcutafspiegeling en een basis voor residuafspiegeling. Dit is zonder twijfel het meest interessante onderdeel omdat het veel impact heeft op de de architectuur in zijn geheel: het vormt het grootste deel van de API en dus ook van de implementatie ervan. Alle voorzien datapaden worden gebruikt en het geheel wordt dus op de proef gesteld. Het is ook het voetstuk waarop de meer geavanceerde functionaliteiten steunen. Ook is het op zichzelf een heel bruikbaar onderdeel: het laat de gebruiker toe om de inwerking van aspecten te onderzoeken. Dit komt goed tegemoet aan de vraag naar structurele reflectie, wat toch een belangrijke vereiste was. Dit onderdeel vormt een groot deel van het werk. ITD ondersteuning lijkt op de ondersteuning van crosscutting informatie: het is ook een aanpassing aan de typeafspiegeling, maar een veel kleinere. In plaats van de inwerking van aspecten en aspect types te introduceren in het gehele model, voert het een enkel nieuwe notie van ouderschap in. Ook de relevantie voor de gebruiker is iets kleiner. Omdat het technisch gelijkend is aan ACI heb ik besloten hier geen tijd in te inversteren. Typefiltering bestaat uit het verwijderen van type-entiteiten die de compiler heeft ingevoegd om de AOP-functionaliteit te realiseren. Dit verbergt veel rommel voor de gebruiker. Omdat deze typefiltering zeer belangrijk is voor de inkapseling, maar niet echt een uitdaging voor de architectuur, heb ik ze gedeeltelijk aangebracht: de methodes en velden worden gefilterd in hun JDI-vorm en interfaces blijven ongefilterd. Multi-source lijnummering is een techniek die beschreven is in JSR45[6]. Het laat een standaard Java-debugger toe om lijnnummers correct weer te geven voor talen anders dan Java die naar Java-bytecode gecompileerd worden. Oorspronggebaseerde lijnnummering is het nummeren van de instructies zodat elke instructie het lijnnummer draagt van de lijn in de broncode die deze instructie veroorzaakt heeft. Initieel leek mij dit een nuttig onderdeel van de debugger en een goede manier om de compiler te leren kennen. Omdat het steunt op multisource debugging moet JDI niet aangepast of gewrapped worden. Later heb ik ondervonden dat dit het aanmaken van een duidelijke stacktrace veel moeilijker maakt, omdat de code die een advies inweeft door dit advies veroorzaakt wordt, maar in de stacktrace vermeld moet worden als onderdeel van de methode die het advies aanroept. Daarom heb ik deze functionaliteit wel gemaakt, maar gebruik ik ze niet.

30 HOOFDSTUK 3. ARCHITECTUUR 29 Stack-afspiegeling is het weergeven van de toestand van de uitvoeringsstack. Dit is ook voorzien door JDI en moet dus ook herverpakt worden om bruikbaar te zijn. Stack-afspiegeling kan uitgebreid worden met duidelijk indicaties over het inwerken van adviezen en filtering. Omdat de stacktraces van JBoss AOP uitermate complex zijn en het wrappen van de stack veel informatie kan herbruiken uit CCI, heb ik deze filtering geïmplementeerd. Eventsysteem is het onderdeel dat instaat voor breakpoints en andere waarschuwingen die de debugger kan voortbrengen. Om bruikbaar te zijn dient het echter ook gewrapped te worden. Dit is niet zo simpel omdat dit een van de minst duidelijk gespecifieerde delen van JDI is. De correcte afhandeling van het stilzetten en weer vrijlaten van de virtuele machine is erg belangrijk, maar ook heel foutgevoelig. De bestaande implementatie reageert niet altijd geheel zoals verwacht. Dit zou zeker een interessante uitdaging zijn, maar de tijd ontbrak. De implementatie van de wrapper is wel grotendeels af, maar nooit getest. Aspect events zijn berichten van de debugger als een aspect wordt ingeladen of aangeroepen of als een advies wordt opgeroepen. Dit soort berichten kan de programmeur gebruiken om de uitvoering beter te volgen. De grootste verandering aan de architectuur is het proactief worden van de agent. Deze toevoeging is ook zeer interessant, maar afhankelijk van een gewrapped eventsysteem. Dit was echter niet beschikbaar, dus deze functionaliteit heb ik niet voorzien. Dynamic ACI is aspectcompositie-informatie die zich live aanpast aan de toestand van het gespiegelde systeem. Dit kan bekomen worden door helemaal niets te cachen of door de nodige klassen naar de aspectevents te laten luisteren. Ik heb dit echter niet ingebouwd omdat de ondersteunende systemen nog niet klaar waren. CFLOW informatie kan ook aan de gebruiker verstrekt worden. Dit geeft twee grote punten van complexiteit: modellering en data-acquisitie. Dit laatste is niet uitzonderlijk moeilijk, maar het modelleren van CFLOW informatie is wel zeer moeilijk, zeker omdat dit concept niet op dezelfde manier voorkomt in de verschillende AOsystemen. Ik heb dus gekozen om deze uitdaging niet aan te gaan, omdat de andere functionaliteiten volgens mij meer praktisch nut hebben en omdat het wel eens zeer moeilijk zou kunnen zijn om CFLOW te modelleren. Instructie-afspiegeling stelt de gebruiker in staat de instructies te onderzoeken via spiegeling en ze uit te voeren en aan te passen via de debugger. JPDA ondersteunt dit niet omdat het veel beperkingen zou opleggen aan de uitvoerings- en compilatiemechanismen. Residu s zijn de stukken van een pointcut die niet statisch geëvalueerd kunnen worden en dus tijdens de uitvoering geëvalueerd moeten worden. Aangezien dit instructie sequenties zijn, is instructie-afspiegeling vereist voor geavanceerde residuafspiegeling.

31 HOOFDSTUK 3. ARCHITECTUUR 30 Pointcutafspiegeling vereist een pointcutmodel. Dit is echter een onderzoek op zich, zeker als het model intuïtief bruikbaar moet zijn en geschikt moet zijn voor meerdere talen. Daarom heb ik voor een tekstuele voorstelling van pointcuts gekozen in plaats van spiegelobjecten. 3.3 Beperkingen Om de architectuur te concretiseren moeten we niet alleen bepalen wat er wel moet kunnen, maar ook een aantal beperkingen opleggen. In deze paragraaf worden de belangrijkste beperkingen van AODA overlopen. Deze beperkingen zijn niet noodzakelijk voor een goede werking, maar een poging om het systeem niet al te complex te laten worden. Voor elke beperking wordt ook ingeschat wat de impact van de beperking is en hoeveel moeite het zou kosten om achteraf de beperking te doorbreken. De belangrijkste beperking is dat Java-types één-op-één moeten overeenkomen met aspecttypes. Het is dus niet toegestaan om een klasse als twee verschillende aspecten te gebruiken of als klasse en aspect tegelijkertijd. Deze beperking is ingevoerd omdat het anders niet mogelijk is om AJDI-types af te leiden van JDI-types. Het zou noodzakelijk worden om voor elke instantie aan de back-end te vragen wat het type ervan is. Hiervoor zou de back-end een notie van instantie-identiteit nodig hebben. In een spiegel-api is er hiervoor maar één kandidaat: het spiegelobject dat de instantie voorstelt. De backend zou dus erg verweven worden met JDI en ADB. Het zou zelfs noodzakelijk kunnen worden voor het back-end protocol om instantie identiteiten door te sturen. Dit zou een JDI-agent noodzakelijk maken, wat ook voor problemen kan zorgen. Het verwijderen van deze beperking zou in de front-end aanpassingen betekenen in slechts enkele klassen, die wel een stuk complexer zouden worden. De back-end-interfaces zouden volledig hervormd moeten worden. Back-ends voor systemen die niet aan het eenop-een-principe voldoen hebben een hoge inherente complexiteit en zullen waarschijnlijk voor problemen zorgen. Een tweede beperking is dat een aspect ook een (subklasse van) klasse is in het model (AJDI) en in de implementatie (ADB). In de ADB wil dit zeggen dat een aspect gedeclareerd kan zijn, maar toch niet beschikbaar als spiegelobject, omdat de klasse nog niet geladen is. Een andere beperking die hieruit voortvloeit, is dat de methoden die de adviezen vormen ook in die klasse moeten zitten. In het model wil dit zeggen dat aspect een subklasse is van klasse, maar dat sommige operaties (zoals instantiatie) een exceptie gooien. Het weglaten van deze beperking zou de notie van aspect veel vager maken. Het modelleren zal dus meer werk vergen en meer onzekerheid opleveren. De front- en backend zouden dus een stuk complexer worden en het is niet duidelijk of er systemen bestaan die niet aan deze beperking voldoen.

32 HOOFDSTUK 3. ARCHITECTUUR Onderdelen De volgende paragrafen omschrijven de onderdelen van de architectuur. De onderdelen van de front-end, die platformonafhankelijk zijn, worden in detail besproken. Voor onderdelen van de back-end, die platformafhankelijk zijn, wordt een mogelijke sub-architectuur aangeboden AJDI De aspect Java debugging interface(ajdi) is de spiegel-api die aan de gebruiker wordt aangeboden. AJDI is sterk geïnspireerd door JDI, omdat JDI een goede spiegel-api is voor Java. AJDI biedt niet alle mogelijkheden van JDI 1.6 aan, maar richt zich op versie In figuur 3.3 zijn de belangrijkste onderdelen van AJDI afgebeeld. De Figuur 3.3: Overzicht van de belangrijkste onderdelen van AJDI

33 HOOFDSTUK 3. ARCHITECTUUR 32 witte klassen zijn gebaseerd op JDI, de grijze zijn nieuw. De meest vanzelfsprekende toevoegingen zijn Aspect, Aspect Instance en Advice. Zoals al vermeldt in paragraaf 3.3 erven aspecten over van klassen. Adviezen erven over van methoden, omdat ze veel overeenkomsten vertonen. Methoden en adviezen zijn de enige entiteiten die uitvoerbare instructies bevatten. Een advies kan een aantal bindingen hebben, die elk één pointcut hebben. Een gebonden advies kan meerdere toepassingen hebben, die elk door één van de bindingen veroorzaakt zijn. Elke toepassing heeft een residu en een joinpoint. De joinpoints vallen uiteen in twee grote klassen, namelijk de statement joinpoints en de method execution joinpoints. Statement joinpoints grijpen aan op een specifieke bytecode-instructie. Voorbeelden hiervan zijn de call en field joinpoints van AspectJ. De method execution joinpoint omvatten de uitvoering van methodes zoals de execution en init joinpoints. Een methode kan dus een willekeurig aantal statement joinpoints hebben en een method execution joinpoint. Constructoren kunnen nog twee extra execution joinpoints hebben, namelijk PreInit en Init. Een klasse kan juist een statische initialisatie joinpoint hebben, die ook de method execution joinpoint is van de <cinit>() methode. Adviezen hebben natuurlijk geen gewone method execution joinpoint, maar een advice execution joinpoint. De statement joinpoints zijn niet verder uitgewerkt, om tijd te besparen. Het is natuurlijk perfect mogelijk om deze hiërarchie verder uit te splitsen. Alle verbindingen tussen entiteiten zijn navigeerbaar langs bijde zijden, behalve als het anders is aangegeven. Er zijn ook veel methodes om specifieke subsets op te vragen, zoals bijvoorbeeld alle methoden met een bepaalde naam. Een belangrijk aspect dat niet is afgebeeld is de locatiehiërarchie. Dit is de weergave van broncode- en bytecodelocaties. In JDI is er enkel het Location type dat een broncode- en een bytecodelocatie te gelijk aanbiedt. In AJDI is er een iets uitgebreidere hierarchie, zoals te zien in figuur 3.4. De locaties zijn opgesplitst in enerzijds broncodelocaties en locaties die zowel in broncode als bytecode voorkomen. Anderzijds is er een onderscheid tussen punten en gebieden. In de meeste gevallen zijn de punten in de bytecode die JDI aanwijst eigenlijk gebieden. Het gegeven punt is dan het begin van het gebied. Om niet te veel extra complexiteit te veroorzaken worden er punten gebruikt in klassen die van JDI afgeleid zijn en gebieden in nieuwe AJDI-klassen. Het broncodegebied van een joinpoint omvat de lijnen die het joinpoint vormen. Het bytecodegebied van een joinpoint is het gebied tussen de eerste en de laatste ingeweven instructie. Het is dus mogelijk, bij before en after advies dat de instructie die het joinpoint vormt, niet in het bytecodegebied ligt, maar er net voor of achter. Voor elk praktisch doel zou deze nummering voldoende moeten zijn: na het einde van het joinpointgebied zullen er geen adviezen meer uitgevoerd worden. Aangezien er geen instructie-afspiegeling mogelijk is, is het ook niet zo belangrijk om de juist instructie te kennen. Een tweede aspect dat niet is afgebeeld, is de aangepaste stackafspiegeling. Om aan te geven of de uitvoering normaal verloopt of geadviseerd wordt zijn er HookFrames voorzien. Als de uitvoering zich in een joinpoint gebied bevindt wordt er een hook frame ingelast. Hiermee kan de gebruiker het joinpoint opvragen. Het hook frame verbergt

34 HOOFDSTUK 3. ARCHITECTUUR 33 Figuur 3.4: Locatie hierarchie ook eventuele synthetische methodes ADB-Back-end Interface Het is uiteindelijk de bedoeling verschillende Java-gebaseerde aspectsystemen te ondersteunen. Daarom is het interesant om alle doelplatformafhankelijke bewerkingen apart onder te brengen. Alle informatie die niet op een onafhankelijk manier door JDI kan aangeleverd worden, komt via de ADB-Back-end Interface binnen. De ADB-Backend Interface bestaat uit meedere Java-interfaces. Er zijn drie belangrijke interfacetypes: ruwe informatieleveranciers, filters en factories. De ruwe leveranciers brengen de debuginformatie aan als primitieve data en specifieke data structuren. Ze gebruiken geen AJDI objecten en moeten zich dus niets aantrekken van caching en oneindige lussen. Ze zijn in principe bruikbaar zonder AJDI of ADB. Filters verbergen onnodige informatie door JDI of AJDI objecten uit te filteren. Ze kunnen gebruikmaken van de ruwe leveranciers. Ook hier gebeuren geen oproepen naar AJDI of ADB, dus er is geen speciaal risico. Deze onderdelen zijn wel zo verweven met AJDI en JDI dat ze er niet los van kunnen bestaan. De factories maken objecten aan die ADB niet zelf kan aanmaken. ADB zorgt er voor dat de objecten geen twee keer aangemaakt worden. Omdat factories AJDI objecten maken, kunnen factories niet zonder ADB en AJDI. Ruwe interfaces Er zijn drie leveranciers van ruwe gegevens: FieldLocationProvider, AspectInfoProvider en CrossCuttingInfoProvider. De FieldLocationProvider is de simpelste van de drie: het enige wat hij moet doen is voor elke veld het juiste lijnnummer en het juiste bronbestand aanleveren of een AbsentInformationException gooien. AspectInfoProvider is verantwoordelijk voor alle informatie over aspecten en adviezen. Dit omvat het omzetten van een aspectnaam naar een klassenaam en vice versa

35 HOOFDSTUK 3. ARCHITECTUUR 34 en het aanbrengen van de attributen van een aspect: scope, broncodelocatie en adviezen. Voor elk advies wordt doorgegeven in welke methode de code van het advies zich bevindt, waar de broncode te vinden is, welke bindingen er zijn en wat het type is. CrossCuttingInfoProvider brengt de joinpoints per methode en de toepassingen per advies aan. Factories Er is maar één pure factory: de AspectInstanceProvider. Het is een factory die instaat voor het aanmaken van spiegelobjecten van aspectinstanties. Het kan nodig zijn dat deze provider methode-oproepen doet in de doel VM om de JDI spiegelobjecten van de aspectinstantie terug te vinden. Hiervoor is een thread nodig in de doel VM, die actief is, maar stil staat op een breekpunt. Het is dus noodzakelijk dat de gebruiker een thread mee geeft wanneer hij een instantie opvraagt. Dit is conform de semantiek van JDI voor het oproepen van methoden en instantiëeren van klassen. Het opvragen van een instantie kan als neveneffect hebben dat er een nieuwe instantie aangemaakt wordt in de doel VM. In zeker zin doet deze factory het werk van een JDI-agent, maar omdat er een thread beschikbaar gesteld wordt door de gebruiker is dit niet problematisch. Filters Er is ook maar één pure filter. Deze staat in voor het filteren van methodes en velden op het niveau van JDI. Omdat deze filter volstaat is er nog geen AJDI-filter, omdat dit weer extra overhead is. Hybriden Tot slot is er nog een factory-filterhybride voor de uitvoeringsstapel. Omdat de uitvoeringsstapel niet enkel uitgefilterd moet worden, maar ook voorzien van nieuwe frames om aan te geven waar adviezen inwerken is het te complex voor de front-end om hier apparte interfaces voor aan te bieden en wordt alles gedaan in de back-end. Omdat stackframes een zeer korte levensduur hebben is caching niet nodig. De wrapping gebeurt ook in deze factory en dus is er toegang tot ADB-functionaliteit vereist. Er is geen risico op oneindige lussen omdat stacktraces nergens intern gebruikt worden ADB ADB is de implementatie van AJDI. Het is een vrij complexe structuur, dus ik zal enkel de belangrijkste ontwerpprincipes overlopen. JDI is gestructureerd om een centrale component, VirtualMachine, die een afspiegeling vormt voor een virtuele machine. Elke JDI-interface erft over van com.sun.jdi.- Mirror. Deze interface bied een virtualmachine() methode aan. Hiermee kan voor elk object het VirtualMachine spiegelobject opgevraagd worden dat verantwoordelijk is voor het object.

36 HOOFDSTUK 3. ARCHITECTUUR 35 ADB is op een gelijkaardige manier gestructureerd. Elke AJDI-interface erft over van ajdi.shadow. Deze interface biedt een methode shadowmaster() aan. Hiermee kan een ShadowMaster opgevraagd worden. Deze centrale component wrapt een VirtualMachine instantie. Om de caching optimaal te doen werken wordt er zo dicht mogelijk bij de consument gecached en zijn er twee soorten caching: harde caches en zachte caches. De hard caches houden hun gegevens vast tot het omvattende object opgeruimd wordt door de garbage collector. Zachte caches werken samen met de garbage collector en kunnen een object laten vallen als er geen enkele andere referentie meer naar bestaat. Het is belangrijk dat er geen ketens van harde referentie onstaan, waardoor de zachte caches niet meer leeggemaakt kunnen worden. Figuur 3.5: caching tussen de ADB enteiten Zoals in figuur 3.5 te zien is slaan alle klassen en aspecten hun methodes, velden en adviezen op in harde caches, nadat ze de eerste keer zijn opgevraagd. Methoden slaan hun joinpoints op in zachte caches nadat ze de eerste keer zijn opgevraagd. Adviezen zouden hun adviestoepassing zacht kunnen cachen, maar doen dit niet omdat er nog geen event systeem beschikbaar is om de cache te invalideren, wat in dit geval zeker nodig zou zijn. De shadow master heeft de belangrijkste caches en gebruikt alleen zachte caches: alle type-afspiegelingen en instantie-afspiegelingen worden gecached in de master om consistentie te verzekeren. Joinpoint en adviestoepassingen worden gecached in de joinpointmanager, die enkel aanspreekbaar is langs de shadow master. Als er JDI-objecten ingepakt moeten worden tot AJDI-objecten of omgekeerd, dan is dit de verantwoordelijkheid van de shadow master. Er wordt dan gecontroleerd of de instanties die geconverteerd worden wel onder de verantwoordelijkheid van deze shadow master en zijn VM vallen. Om de conversie te doen worden eerst de relevante caches gecontroleerd en indien er geen bestaand object gevonden kan worden, wordt de nodig informatie opgezocht en het nieuwe object wordt aangemaakt en in cache opgeslagen ADB-Back-end De ADB-Back-end is onafhankelijk van de kern architectuur en mag dus vrij ingevuld worden. Een praktische invulling die de verantwoordelijkheden goed afschermt is te zien

37 HOOFDSTUK 3. ARCHITECTUUR 36 in figuur 3.6. Figuur 3.6: Referentiearchitectuur ADB-Backend De Agent Protocol Controller staat in voor het opzetten, onderhouden en encapsuleren van de connectie met de agent. Deze component biedt een centrale interne interface aan waarlangs de andere componenten informatie kunnen opvragen. De andere componenten staan in voor de aggregatie van een bepaald type informatie en bieden elk een ADB-Back-end Interface aan. Dit model kan ook nog uitgebreid worden met een al of niet aspectgebaseerde caching service op de verschillende interfaces Agent Net zoals de ADB-Back-end is de agent onafhankelijk van de architectuur. We kunnen vijf soorten agenten onderscheiden: compiler agent, VM agent, statische JDI-agent, dynamische JDI-agent en half JDI-agent. De compiler agent zit ingebouwd in de compiler. Dit soort agent kan alleen gebruikt worden als we met voorgecompileerde klassen werken. Mogelijke communicatiekanalen zijn bestanden met debuginformatie, databases en attributen. Attributes[12] zijn gebieden in een classfile die de compiler zelf kan invullen, maar die de uitvoering niet beïnvloeden. De VM-agent is een server process dat mee opgestart wordt in de doel VM. De backend kan hiermee communiceren via een socketconnectie. Dit soort agent is vrij makelijk

38 HOOFDSTUK 3. ARCHITECTUUR 37 te maken, maar heeft als nadeel dat hij in de doel VM aanwezig is en invloed heeft op de toestand van de doel VM. Door zorgvuldig ontwerp kan deze invloed beperkt worden. ADB kan in staat gesteld worden om de agent weg te filteren uit de afspiegeling, zodat de gebruiker niet gestoord wordt. De agent moet normaal mee met het doelprogramma opgestart worden. Als dit niet het geval zou zijn, maar de agent bevindt zich wel in het classpath, dan kan JDI gebruikt worden om de agent op te starten. Een nadeel van een VM-agent is class loading: als een thread door de debugger stil gezet is tijdens het laden van een klasse en de VM-agent tracht ook, rechtstreeks of onrechtstreeks, een klasse te laden dan zal de agent blokkeren op de classloaderlock. Hierdoor kan de debugger ook blokkeren en ontstaat er deadlock. Een ander nadeel is dat wanneer de VM volledig stilgezet wordt op een breakpoint, de agent ook stil gezet wordt. Omdat er nog geen wrapping van het eventsysteem is, is dit een reëel risico. Een JDI-agent onderzoekt de toestand doorheen de debugging interface. Een statische agent doet dit door zelf het juiste resultaat te gaan zoeken in de datastructuren, zonder code uit te voeren in de doel-vm. Dit is natuurlijk extreem moeilijk en foutgevoelig omdat JDI niet in staat is om instructies te spiegelen en alle gebruikte klassen dus eigenlijk een nieuwe, identieke implementatie moeten krijgen die gebruik maakt van JDI-spiegelobjecten in plaats van echte data. Een dynamische JDI-agent gebruikt functies in de doel-vm om de informatie te vinden. Het grote nadeel hiervan is dat er een thread beschikbaar moet zijn die stilstaat op een breekpunt. Het verkrijgen van zo n beschikbare thread is soms zeer moeilijk. Een mogelijke oplossing hiervoor is het invoegen van een thread die een oneindige lus uitvoert en die thread steeds stil te zetten op een breakpoint. Een half-jdi-agent is een dynamische JDI-agent die bepaalde niet standaard functies gebruikt, die mee in het classpath van de doel-vm moeten zitten. 3.5 Beperkingen Na de validatie is gebleken dat de architectuur ook een aantal gebreken vertoont. Die worden in de volgende paragrafen besproken Identiteit In de context van een aspectdebugger kunnen we verschillende soorten eniteiten vaststellen die we moeten identificeren: instantie, klasse, aspect, methode, advies, joinpoint, binding en adviestoepassing. Er zijn zes belangrijk interfaces waardoor deze entiteiten moeten doorgegeven worden: JVM-TI, JDWP, JDI, ADB-Back-end Interfaces, agentprotocol en AJDI. Om de identiteit vast te leggen kunnen we gebruikmaken van betekenis volle en betekenisloze identiteiten. De naam van een type is een betekenisvolle identiteit, een identificatienummer is betekenis loos. Betekenisvolle identiteiten hebben het voordeel dat ze buiten de context van een sessie gebruikt kunnen worden. Betekenisloze identiteiten hebben het voordeel dat ze nergens aan vasthangen en dat verandering van de

39 HOOFDSTUK 3. ARCHITECTUUR 38 interfaces dus makelijker is. Ze kunnen veranderen zonder dat de gebruiker er last van heeft. In een spiegel-api zijn de referenties naar de spiegelobjecten de identiteiten. Dit zijn betekenis loze identiteiten. Meestal is er voor een spiegelobjecten ook een betekenisvolle identiteit af te leiden zoals een unieke naam. In de context van een VM- en een compileragent zijn betekenisvolle identiteiten zeer belangrijk, omdat er twee sessies zijn. De JDI-sessie en de agent protocolsessie. De gegevens van deze sessies kunnen slechts geünificeerd worden door de afgeleide identeiten. Ik had verwacht dat dit soort agenten het meest performant zouden zijn. Achteraf gezien zijn half-jdi-agenten met een eigen thread mischien toch beter, omdat ze maar één datakanaal hebben, ze een notie van instantie-identiteit kunnen ondersteunen en ze best werken als de JVM stil staat, wat de toestand van de JVM is die meest gebruikt wordt bij debugging. Ik heb echter nog geen half-agent gemaakt en ben dus niet zeker. Op dit moment gebruiken de ruwe ADB-Back-end Interfaces dus betekenis volle identiteiten. Daarom is het gebruik van instantie-identiteit uitgesloten. Aspect- en klasseidentiteit vallen samen door de beperking op meervoudige types en dus kan de unieke typenaam gebruikt worden. Methoden kunnen benoemd worden op basis van hun klasse, naam en signatuur. Adviezen kunnen altijd benoemd worden op basis van de methode waarin ze vervat zitten. Dit is soms onefficiënt. Joinpoints worden geïdentificeerd op basis van hun methode, hun type en locatie in de methode. Advies toepassingen worden herkend aan hun joinpoint en advies. Bindingen kunnen een naam hebben of als elke advies juist één binding heeft geidentificeerd worden op basis van hun advies. Als de back-end interface zou werken met JDI-identiteiten onstaan er andere beperkingen, zoals het onvermogen om puur synthetische aspecten, die geen Java-type hebben, te gebruiken. In de huidige vorm is de aanpassing die nodig is om volledig ingeweven aspecten te ondersteunen niet extreem groot omdat er JDI-onafhankelijk identiteiten gebruikt worden. Ik denk nu dat het doorgeven van identiteiten de grootste zwakte is van de architectuur in het kader van uitbreidbaarheid. Het gebruik van identificerende objecten was waarschijnlijk beter geweest. Dit had weer een indirectie meer betekend, maar ook meer flexibiliteit opgeleverd. Hiermee zou het mogelijk zijn om JDI identiteiten en betekenis volleidentiteiten samen te ondersteunen. Wat veel belangrijker is, het zou encapsulatie van identiteit opleveren, zodat de behandeling ervan aangepast kan worden bij de producenten en consumenten zonder de transport- en opslagmechanismen te wijzigen API-overerving Een van de problemen die veel tijd opslorpen bij het uitbreiden van JDI is het tekortschieten van de compositiemechanismen in Java. Omdat elke spiegel-api een gesloten systeem moet zijn, moeten alle returntypes uit JDI verstrengd worden tot hun overgeërfd equivalent uit AJDI. Het Lyskof-substitutieprincipe laat dit toe. Met generieke lijsten ontstaat er echter een probleem omdat lijsten invariant zijn. De lijsten die JDI teruggeeft zijn echter onwijzigbaar en dus covariant. In Java kan men dit aangeven door een wildcard (List<? extends T>). Het probleem is dat elke keer men de lijst wil gebrui-

40 HOOFDSTUK 3. ARCHITECTUUR 39 ken, hij gecast moet worden om de wildcard weg te werken. Daarom heeft JDI exacte typeparameters en kunnen de types van de lijsten niet gewijzigd worden. Er zijn binnen de context van Java wel oplossingen te bedenken om dit probleem op te lossen, maar die zijn weinig elegant. Een krachtiger typesysteem zou hier een goede oplossing kunnen bieden Object Consistentie Een spiegel-api vormt een zeer dicht netwerk van dubbelgelinkte entiteiten: alle members zijn aan hun ouder gelinkt en vice versa, alle joinpoints aan hun applicaties en hun eigenaar en vice versa,... Om aan de invarianten van de dubbele linken te voldoen en om het geheugengebruik te beperken is het noodzakelijk dat een spiegelobject niet twee keer aangemaakt wordt. Dit moet in JDI gebeuren en in AJDI, wat vrij veel inspanning vraagt, zowel op het vlak van ontwerp als op het vlak van uitvoering. Er zijn twee moelijke oplossingen voor dit probleem. Ten eerste kunnen key-value pairs in JDI spiegelobjecten voorzien worden, zodat het AJDI equivalent mee gecached kan worden. Ten tweede kan men een meer aspectgerichte implemenatie voor caching voorzien. Ik moet hier wel aan toevoegen dat ik geen concreete invulling voor de aspectgerichte oplossing kan bieden Modulaire compositie Zoals al eerder aangehaald zijn er vele mogelijk sets van functionaliteiten die we kunnen aanbieden. Het is echter niet mogelijk om die functionaliteiten modulair aan te bieden, enerzijds omdat API-inheritance niet goed genoeg werkt en anderzijds omdat er geen meervoudige overerving is. De modulaire compositie die Scala aanbiedt, zou hiervoor een zeer elegante oplossing kunnen bieden. Ik heb dit niet gebruikt om niet te veel onbekende factoren tegelijk in het project te betrekken Geïsoleerde aggregatie De instrcuties die de back-end gegevens aggregeren is verspreid over de gehele back-end. Dit maakt het moeilijk om ze aan te passen. Het zou ideaal zijn als deze code een afgescheiden geheel zou vormen, zodat ze herbruikt kan worden in andere debuggers. 3.6 Evaluatie Als we deze architectuur evalueren tegen de vooropgestelde aandachtspunten. Stucturele reflectie, zichtbaarheid, traceerbaarheid en inkapseling. Dan blijkt dat de architectuur hier goed aan voldoet. Structurele reflectie is fundamenteel voor spiegel-reflectie en dus goed ondersteund. Statische en dynamische reflectie zijn volledig ondersteund, aspectcompositie-informatie is ook beschikbaar. ITD s zijn afwezig maar liggen zeker binnen de mogelijkheden.

41 HOOFDSTUK 3. ARCHITECTUUR 40 Zichtbaarheid is ook beter ondersteund door de architectuur door een fijnere notie van lijnnummering en extra input langs de back-end. De traceerbaarheid is ook verbeterd door een filtering en transformatie van de stack. Dit ligt echter grotendeels in de handen van de back-end. De kwaliteit kan dus erg verschillen. Inkapseling is het paradepaardje van deze architectuur. Langs de ene kant is er inkaspeling van de basistaal. Hiervoor zijn er filters voorzien. De goede werking hiervan hangt ook weer af van de back-end. Een andere vorm van inkapseling ligt in de bruikbaarheid van de API voor meerdere platformen. Elke taal die het patroon volgt dat de architectuur vooropstelt kan volledig transparant opgenomen worden. Tot slot is er de inkapseling van de back-end. Door de splitsing tussen front-end en back-end kan een back-endprogrammeur een zeer gerichte inspanning leveren zonder echt vertouwd te zijn met ADB. Zoals in de vorige sectie vermeld zijn er nog veel punten van onzekerheid. De juiste groeirichting is nog niet bekend, dus de gemaakte keuzes kunnen nog niet volledig naar waarde geschat worden. De architectuur is ook nog niet volledig ontrold, niet alle mogelijkheden zijn al ingebouwd, veel dingen zijn niet getest tot in de details. Ondanks deze onzekerheden zijn er duidelijk sterke punten aan deze stuctuur.

42 Hoofdstuk 4 Eerste validatie: een debugger voor AspectJ Zoals al besproken in paragraaf 1.4 is het doel van de AspectJ-implementatie om zoveel mogelijk functionaliteit te ondersteunen en de architectuur te beproeven. In praktijk zal de AspectJ-implementatie dus alle functionaliteit beschreven in paragraaf 3.2 ondersteunen. De meest belangrijke onderdelen zijn aspectcompositie-informatie, verbeterde stack trace, instantie-afspiegeling en oorspronggebaseerde lijnnummering. Er zijn twee belangrijke compilers voor AspectJ: de AJC[7] en de ABC[2][3]. AJC is de referentiecompiler. ABC is een onderzoekscompiler die probeert AJC zo goed mogelijk na te maken. AJC is erg verweven met Eclipse en moeilijk los ervan te gebruiken. ABC is zeer goed gedocumenteerd en gestructureerd. Ik gebruik de versie van ABC. In de komende paragrafen zal ik eerst de technische details van AspectJ en ABC overlopen om daarna te bespreken hoe de debugger agent en back-end opgebouwd zijn. 4.1 AspectJ in relatie tot AJDI De relaties tussen AspectJ en AJDI-entiteiten zijn zeer goed. Uit vergelijking tussen figuur 3.3 en figuur 4.1 blijkt dat AJDI zelfs een beetje algemener is, in die zin dat AJDI meerdere bindingen per advies en meerdere adviezen per binding toelaat terwijl dit bij AspectJ altijd exact één binding voor één advies is. De mapping van AspectJ-joinpoints naar AJDIjoinpoints is goed. Alles is modeleerbaar, maar er is toch ook een verlies aan informatie. In figuur 4.2 is duidelijk te zien dat er veel verschillende soorten joinpoints afgebeeld worden op statement joinpoints. Hier is zeker nog plaats voor verfijning van het joinpoint model. Method en constructor execution worden ook afgebeeld op één type, maar hier kan men achteraf het onderscheid nog maken. Er zijn nu nog enkele functionaliteiten van AspectJ die niet voorkomen in AJDI. CFLOW en ITD zijn de belangrijkste, maar zoals al vermeld in 3.2 is dit ook niet de bedoeling. Declare warning en declare error komen niet voor, omdat deze functionaliteiten enkel effect hebben tijdens de compilatie en geen enkel spoor achterlaten in de 41

43 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 42 Figuur 4.1: Statisch AspectJ ER model Figuur 4.2: Joinpoints in AJDI en AspectJ

44 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 43 uitvoering. Soften exception zou mischien nog een interessante toevoeging aan het model kunnen zijn, maar er zijn ook een aantal nadelen aan verbonden. Ten eerste is de afspiegeling van excepties zeer minimaal ondersteund in JDI. Dit is waarschijnlijk zo omdat instructieafspiegeling belangrijk is zinvol aan exceptie-afspiegeling te doen. JDI ondersteunt geen exceptie-afspiegeling. Ten tweede kan declare soft omgevormd worden tot een around advice en zo gespiegeld worden. Voorlopig wordt declare soft niet ondersteund. Precedence tot slot is ook niet traceerbaar. Het is natuurlijk mogelijk om in het model te zien in welke volgorde de adviezen uitgevoerd zullen worden, maar het is niet mogelijk om vast te stellen hoe die volgorde tot stand is gekomen. Dit zou zeker nog een mooie toevoeging aan AJDI kunnen zijn. 4.2 ABC Bytecode De volgende sectie handelt over de vorm van de AspectJ-bytecode zoals ABC ze produceert. De AJC- en ABCbytecode zijn niet erg verschillend omdat ABC probeert AJC zo goed mogelijk te volgen Singleton Aspect Listing 4.1: aspectj code sample: singleton aspect en advice 1 public class Test { 2 private String method1 (){ 3 return " normal method 1"; 4 } 5 public static void main ( String [] args ){ 6 Test t = new Test (); 7 System. out. println (t. method1 ()); 8 } 9 } public aspect Ex1 { 12 before (): execution ( String method *()){ 13 System. out. println (" called "); 14 } 15 } In Listing 4.1 zijn een aspect met een advies en een klasse waarop het advies toegepast wordt zichtbaar. Na compilatie met ABC en decompilatie (zie Listing 4.2) is het aspect omgezet in een klasse en het advies in een methode. De nodige velden voor het singletongedrag zijn aangemaakt. Er is ook een aspectof() method aangemaakt om de

45 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 44 Listing 4.2: aspectj code sample: singleton aspect en advice, gedecompileerd 1 public class Test { 2 private String method1 (){ 3 Ex1 r1 = Ex1. aspectof (); 4 r1. before$0 (); 5 return " normal method 1"; 6 } 7 8 public static void main ( String [] r0 ){ 9 System. out. println ( new Test (). method1 ()); 10 } 11 } public class Ex1 { 14 public static final Ex1 abc$persingletoninstance ; 15 private static Throwable abc$initfailurecause ; static { 18 try { 19 abc$postclinit () 20 } catch ( Throwable $r0 ){ 21 abc$initfailurecause = $r0 ; 22 } 23 } private static void abc$postclinit (){ 26 abc$persingletoninstance = new Ex1 (); 27 } public static Ex1 aspectof () 30 throws org. aspectj. lang. NoAspectBoundException { 31 Ex1 r0 = abc$persingletoninstance ; 32 if ( r0!= null ) 33 return r0; 34 throw new NoAspectBoundException 35 (" Ex1 ", abc$initfailurecause ); 36 } public static boolean hasaspect (){ 39 if ( abc$persingletoninstance == null ) 40 return false ; 41 return true ; 42 } public final void before$0 (){ 45 System. out. println (" called "); 46 } 47 }

46 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 45 instantie op te vragen. Een hasaspect() method is ook verschenen. hasaspect() en aspectof maken deel uit van de AspectJ-specificatie[15] en zijn dus steeds aanwezig. In de klasse Test is het advies ingeweven op de juiste plaats Per Object Aspect Listing 4.3: aspectj code sample: Per object aspect and advice 1 public aspect Ex1 perthis ( voidmethod ()){ 2 pointcut voidmethod (): execution ( String method *()); 3 4 before (): voidmethod () { 5 System. out. println (" called "); 6 } 7 } In Listing 4.3 is de code te zien voor een per this aspect. In Listing 4.4 is weer de gedecompileerde code te zien. Het advies zelf is weggelaten. De belangrijkste vaststelling dat er geen map wordt bijgehouden van de objectaspectparen in het aspect, maar dat de aspect instantie opgeslagen is in een veld in de klasse Test en dat Test de interface Ex1$abc$PerThis implementeert. Dit wil in de praktijk zeggen dat elk per object aspect een interface en zijn implementatie toevoegt aan elke klasse in het systeem. Het inweven van deze interface zou natuurlijk beperkt kunnen worden, maar dat doet ABC niet omdat AJC het ook niet doet. Het binden van de instantie gebeurt door een synthetisch before-advies dat voorrang heeft op alle mogelijk niet-synthetische adviezen en dat gebonden is aan de pointcut die meegegeven wordt met de per object scope. Het advies roept de abc$perthisbind() methode aan met het juiste argument. Het synthetische advies verschilt van normale adviezen in die zin dat het statisch is en dus geen aspectinstantie nodig heeft. In AspectJ zelf bestaan statische adviezen niet. Ook het aanroepen van het advies is iets anders ingevuld omdat het niet meer zeker is dat er een instantie beschikbaar is. De hasaspect method wordt dus gebruikt Per CFLOW Aspect In Listing 4.5 is de code voor een per CFLOW aspect te zien. In Listing 4.6 is de gedecompileerde versie te zien. De uitvoering van het advies is identiek aan het per object geval en dus afwezig. Ook hier is er weer een synthetisch advies. Dit keer is het een statisch before-after advies. Omdat het belangrijk is dat niet alleen het binnengaan, maar ook het verlaten van de joinpoint gesignaleerd wordt, moet er een around advies gebruikt worden. Dit zou echter voor teveel overhead zorgen en men gebruikt dus before-after-advice. Dit is een speciaal advies type dat bestaat uit een before en een after advice samen.

47 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 46 Listing 4.4: aspectj code sample: Per object aspect en advice; decompiled 1 public class Test implements Ex1$abc$PerThis { 2 private transient Ex1 Ex1$abc$PerThisField ; 3 4 private String method1 (){ 5 String r1 = " normal method 1"; 6 Ex1. abc$perthisbind ( this ); 7 if(ex1. hasaspect ( this )) 8 Ex1. aspectof ( this ). before$0 (); 9 return r1; 10 } public Ex1 Ex1$abc$PerThisGet (){ 13 return Ex1$abc$PerThisField ; 14 } 15 public void Ex1$abc$PerThisSet ( Ex1 r1 ){ 16 Ex1$abc$PerThisField = r1; 17 } public class Ex1 { 21 public static void abc$perthisbind ( Object r0 ){ 22 if( r0 instanceof Ex1$abc$PerThis ){ 23 Ex1$abc$PerThis r2 = ( Ex1$abc$PerThis ) r0; 24 if (r2. Ex1$abc$PerThisGet () == null ){ 25 r2. Ex1$abc$PerThisSet ( new Ex1 ()); 26 } 27 } 28 } public static Ex1 aspectof ( Object r0) 31 throws org. aspectj. lang. NoAspectBoundException { 32 if( r0 instanceof Ex1$abc$PerThis ){ 33 Ex1 r2 = (( Ex1$abc$PerThis )r0 ). Ex1$abc$PerThisGet (); 34 if(r2!= null ){ 35 return r2; 36 } 37 } 38 throw new NoAspectBoundException (); 39 } public static boolean hasaspect ( Object r0 ){ 42 return r0 instanceof Ex1$abc$PerThis && 43 (( Ex1$abc$PerThis ) r0 ). Ex1$abc$PerThisGet ()!= null ); 44 } 45...

48 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 47 Listing 4.5: aspectj code sample: Per CFLOW Aspect and Advice 1 public aspect Ex1 percflow ( main ()){ 2 pointcut voidmethod (): execution ( String method *()); 3 pointcut main (): 4 execution ( public static void main ( String [])); 5 6 before (): voidmethod (){ 7 System. out. println (" called "); 8 } 9 } Belangijk is natuurlijk ook dat de CFlowStack threadlocale is en zich dus in alle threads gedraagt alsof hij slecht door een thread gebruikt wordt CFLOW In Listing 4.7 is een CFLOW pointcut te zien. Het CFLOW-gedeelte van deze pointcut zal resulteren in een synthetisch advies en een CFLOWresidu. Het synthetisch advies is vergelijkbaar met dat voor CFLOW-scoping: het advies duwt de nodige argumenten op een stack. Er zijn nog enkele optimaties ten opzichte van scoping, om de overhead te beperken. Het CFLOWresidubestaat uit een test die nagaat of de stack leeg is. Als dit het geval is, wordt het advies niet uitgevoerd, anders worden de argumenten afgehaald en het advies uitgevoerd ITD In Listing 4.8 is een voorbeeld van ITD te zien, dat een veld en een methode aanmaakt in Test. De nieuwe methode maakt gebruik van het private veld field. Dit is toegestaan omdat het aspect privileged is. De ITD-methode extra() wordt aangeroepen in het basis programma. In AspectJ is dit toegestaan. Het gedecompileerd programma is te vinden in listing 4.9. Het lichaam van de method wordt in het aspect gedefinieerd. Volgens de abc paper[3] is dit gedaan om makkelijkere toegang te hebben tot statische velden in het aspect en voor betere namematching. Het veld wordt ingeweven in de doelklasse, maar de initialisatie gebeurt in het aspect. Waarom dit zo gebeurt, is slecht gedocumenteerd, maar in de code staat (abc.weaving.- weaver.intertypeadjuster:1170) dat deze constructie bestaat om de whitin code pointcut correct te doen werken. Om toegang tot het private veld field te verkrijgen, worden er twee accessormethoden aangemaakt.

49 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 48 Listing 4.6: aspectj code sample: Per CFLOW Aspect and Advice; decompiled 1 public class Ex1 { 2 public static CFlowStack a bc$per CflowS tack = 3 new CFlowStack (); 4 5 public static Ex1 aspectof () 6 throws NoAspectBoundException { 7 return ( Ex1 ) a bc$per CflowS tack. peekinstance (); 8 } 9 10 public static boolean hasaspect (){ 11 return a bc$per CflowS tack. isvalid (); 12 } public static void abc$percflowpush (){ 15 bc$percflowstack. pushinstance ( new Ex1 ()); 16 } public class Test { public static void main ( String [] r0 ){ 22 Ex1. abc$percflowpush (); 23 try { 24 Test r3 = new Test (); 25 String r2 = " call "; 26 System. out. println (r3. method1 (r2 )); 27 } catch ( Throwable $r8 ){ 28 Ex1. abc$percflowstack. pop (); 29 throw $r8 ; 30 } 31 Ex1. abc$percflowstack. pop (); 32 } 33...

50 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 49 Listing 4.7: aspectj code sample: CFLOW pointcut 1 abstract pointcut creation ( Data data ); 2 abstract pointcut run ( String arg ); 3 4 pointcut activecreation ( Data data, String arg ): 5 creation ( data ) && cflow ( run ( arg )); Listing 4.8: aspectj code sample: ITD 1 public class Test { 2 private String field = " initval "; 3 public static void main ( String [] args ){ 4 Test t = new Test (); 5 t. extra (); 6 } 7 } 8 9 privileged aspect Ex1 { 10 String Test. field2 = " ITD "; 11 public void Test. extra (){ 12 System. out. println (" extra " + field + field2 ); 13 } 14 } 4.3 ABC Bytecode in relatie tot ADB Zoals te zien in Figuur is de mapping van AspectJ-types naar Java-types is één op één. Klassen worden klassen, aspecten worden klassen, methoden worden methoden en adviezen worden methoden. Figuur 4.3: mapping van AspectJ-entiteiten op Java-entiteiten

51 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 50 Listing 4.9: aspectj code sample: ITD; decompiled 1 public class Test { 2 private String field ; 3 public String Ex1$field2$2 ; 4 5 public String get$accessor$field$6 (){ 6 return field ; 7 } 8 9 public String set$accessor$field$7 ( String r1 ){ 10 field = r1; 11 return r1; 12 } public Test (){ 15 Ex1. fieldinit$8 ( this ); 16 field = " initval "; 17 } public void extra (){ 20 Ex1. extra ( this ); 21 } 22 } public class Ex1 { 25 public static void extra ( Test r0 ){ 26 System. out. println (" extra " + 27 r0. get$accessor$field$6 () + 28 r0. Ex1$field2$2 ); 29 } public static void fieldinit$8 ( Test r0 ){ 32 r0. Ex1$field2$2 = Ex1. init$field2$5 ( r0 ); 33 } public static String init$field2$5 ( Test r0 ){ 36 return " ITD "; 37 }

52 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 51 Ook de lijnnummering blijft behouden voor alle non-synthetische instructies. 4.4 De Aspect Bench Compiler Zoals eerder vermeld is de Aspect Bench Compiler (ABC) een modulaire onderzoekscompiler. Hij werd gebouwd door de Programming Tools Group van de Oxford University en de Sable research group aan McGill University in Montrea Onderdelen De ABC tracht zoveel mogelijk software te herbruiken en bouwt dus verder op bestaande technologie. In figuur 4.4 is hiervan een overzicht te zien. ABC gebruikt polyglot[13] als front-end voor parsing en typechecking en soot[16] als back-end voor weaving en optimalisatie. Polyglot op zijn beurt gebruikt Cup en JFlex als respectievelijk parseren lexergenerator. Soot gebruikt Jasmin om class files aan te maken. ABC Polyglot Soot Jflex Cup Jasmin Figuur 4.4: Technologische afhankelijkheden van de ABC compiler Polyglot is een uitbreidbare compiler front-end voor Java. ABC steunt op Polyglot De gehele architectuur van Polyglot is gericht op uitbreidbaarheid. De belangrijkse functionaliteiten voor ABC zijn uitbreidbare grammaticas, zeer dynamische job scheduling, veel herbruikbare compiler passes en een geavanceerd visitor systeem. Voor meer informatie zie[13]. Soot, de back-end, is een optimisatieraamwerk. Het heeft dus zeer uitgebreide ondersteuning voor analyse en adaptie van de programmastructuur. Er zijn heel wat bruikbare optimalisaties aanwezig in Soot. Soot beschik over meerdere interne taalrepresentaties: jimple is een three-address respresentatie, baf is een getypeerde vorm van het Javabytecodeformaat, shimple is een SSA(static single assignment) representatie, dava is geschik voor decompilatie,... Binnen Soot is het ook mogelijk om aan elke entiteit tags vast te maken, deze tags worden behouden doorheen de transformaties. Dit is natuurlijk praktisch voor het transport van debuginformatie. Als men informatie vastmaakt aan een instructie, zal de informatie vrijwel zeker de output-stage bereiken. Het enige nadeel aan Soot is dat de scheduling van de passes nogal gebrekkig is.

53 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ Het compilatieproces Het compilatieprocess van AspectJ is vrij complex in vele opzichten. Het zou ons een beetje te ver leiden om daar dieper op in te gaan. Een globaal overzicht van het proces is te zien in figuur 4.5. Een meer volledige behandeling is te vinden in [3]. Figuur 4.5: Controle flow door de ABC compiler Parse De broncode wordt gelexed en geparsed om zo een abstract syntex tree(ast) te verkrijgen. Clean De AST wordt schoongemaakt. De typeinformatie wordt verzameld en er worden disambiguaties doorgevoerd. Dit wil zeggen dat namen zoals List omgezet worden in volledig gekwalificeerde namen zoals java.util.list of java.awt.list. Deze stap komt twee keer voor omdat alle type informatie pas beschikbaar is na het invoeren van ITD s en het invoeren van ITD s al bepaalde type informatie nodig heeft. Transform types De type-informatie wordt aangepast aan de ITD s. Deze verandering wordt enkel doorgevoerd in de type-informatie en niet in de AST.

54 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 53 Collect aspect info Alle aspectgerelateerde informatie wordt opgehaald en opgeslagen in een centrale datastructuur. Check Alle checks worden uitgevoerd. Dit omvat onder andere type checking en excepion checking. Transform AST Alle Java-vreemde entiteiten worden omgezet in Java-entiteiten: aspecten worden klassen, adviezen worden methoden, joinpoints worden weggegooid. Het is belangrijk om te weten dat lijnnummers behouden blijven in dit process en dat de instructies die adviezen vormen dus correct genummerd is. Jimplify structure De AST wordt omgezet naar jimple, één van de interne taalrepresentaties van Soot. De eigenlijk instructies in de methoden worden nog niet aangemaakt. Weave ITD s De ITD s worden ingeweven in de Sootstructuren. Jimplify methods De omzetting naar jimple wordt volledig doorgevoerd: de lichamen van methoden worden gevuld met instructies. Match Alle pointcuts worden gematched tegen alle mogelijk joinpoints. tijdrovende stap omdat de matching nogal naief gebeurt. Dit is een Weave De eigenlijke inweving van de aspecten. Optimize residue de residus worden geoptimiseerd door analyse van de geweven code. Daarna wordt het weven ongedaan gemaakt en er wordt opnieuw geweven met de geoptimiseerde residus. Dit proces wordt herhaald tot een maximum aantal iteraties overschreden is of er geen verbetering meer merkbaar is. Optimize code De code wordt geoptimaliseerd met standaardoptimalisaties die Soot beschikbaar stelt, die uitgebreid zijn met kennis over de invarianten van de ingeweven code. Output De classfiles worden aangemaakt. Bij het aanmaken van de classfiles kunnen tags geagregeerd worden tot Jasmin tags. Deze kunnen als attributen mee verpakt worden in de classfile. 4.5 Agent De debugging agent moet welbepaalde gegevens verzamelen en door de compiler loodsen zodat ze de outputstage bereiken. De makkelijkste manier om gegevens daar te krijgen zijn tags. Het probleem van de agent bestaat vooral uit het oppikken van informatie wanneer ze beschikbaar is en ze dan in tags omzetten. Dan moeten de gegevens na de transformatie tot bytecode(baf) geagregeerd worden en in de class file opgeslagen als attributen.

55 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 54 Het doel van de aspectj ADB-back-end implementatie omvat het aanleveren van aspectcompositie-informatie, stacktrace-informatie, instantie-afspiegeling, oorspronggebasseerde lijnnummers en veldlijnnummers. De aspectcompositie-informatie valt uiteen in twee types: aspectinformatie en crosscutting-informatie. De stacktrace-informatie kan volledig afgeleid worden uit crosscutting-informatie. Instantie-afspiegeling kan zoals eerder besproken best in de back-end afgehandeld worden. Veldlijnnummers zijn aanwezig in de outputstage en moeten enkel nog geaggregeerd worden Oorspronggebaseerde lijnnummers Zoals eerder vermeld, is oorspronggebaseerde lijnnummering in conflict met de juiste werking van de ADB. Dit is dus een alleenstaande functionaliteit. Soot is in staat willekeurige tags aan te brengen op elke instructie en deze tags blijven bewaard onder alle transformaties. Onder de standaardconfiguratie worden alle lijnnummers en de naam van het oorspronkelijke bestand vastgemaakt aan elke eerste instructie die dit lijnnummer draagt. Deze worden als gewone Java-lijnnummers geaggregeerd en in de classfile verpakt. Ook de omzetting van advies naar methode behoudt de lijnnummers. Adviezen zijn dus juist genummerd. Hieruit volgt dat er maar twee soorten code zijn waarvoor een ingreep nodig is: synthetische code en geïnlinede code uit andere klassen. Synthetische code omdat ze helemaal geen lijnnummers heeft en geïnlinede code omdat ze uit een ander bestand komt. Standaard Java-lijnnummeringsmechanismen ondersteunen dit niet. Om de syntethische code van lijnnummers te voorzien zijn er drie problemen. Ten eerste moet het punt gevonden worden waar het productieproces van de code begint. Op dit punt (punt een) is de oorsprong van de synthetische code gekend en kan een lijnnummer afgeleid worden. Het tweede probleem is het vinden van alle locaties waarop synthetische instucties gemaakt worden (punten twee). Hier moeten tags bevestigd worden. Het derde probleem is dat het eerste punt hoog in de uitvoeringsstapel zit en het tweede helemaal beneden. Met traditionele OO-technieken zou dit betekenen dat er argumenten moeten meegegeven worden van punt een naar alle mogelijke punten twee. Daar aangekomen moeten de instructie-instanties één voor één van een tag voorzien worden. Dit is ondoenbaar en moeilijk onderhoudbaar. Het is een crosscutting concern. Dit probleem kan opgelost worden met een aspect: de context kan onderschept worden met een CFLOW-pointcut en het aanmaken van nieuwe instructies met een gewone pointcut. Een advies kan dan de tag toevoegen. Dit aspect is te zien in Listing Het opslaan van de nummering van geïnlinede code en van de synthetische code is niet mogelijk met het normale lijnnummeringsmechanisme van Java omdat dit ervan uitgaan dat al de broncode van één klasse in hetzelfde bestand zit. Er is echter wel een anders formaat dat de standaard Java-infrastructuur ondersteunt dat dit wel toelaat. Dit formaat is beschreven in JSR45[6]. Dit formaat is eigenlijk bedoeld voor programmeertalen die hun broncode outputten in een lagere taal en uiteindelijk Java-broncode outputten. In de terminologie van deze standaard vormt elke taal een stratum. Voor elk lijnnummer in de input-

56 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 55 Listing 4.10: Aspect voor het toevoegen van lijnnummers 1 public aspect DebugInformationPassing { 2 // creatie van statements 3 pointcut stmtcreation (): 4 call ( public Host + soot. jimple. Jimple.ne *(..)); 5 6 // het inweven van adviestoepassingen 7 pointcut pointcutcodegencontext 8 ( SootMethod meth, A dvicea pplica tion parent ): 9 cflow ( 10 execution ( private void 11 abc. weaving. weaver. PointcutCodeGen. weave_one ( 12 SootClass, 13 SootMethod, 14 LocalGeneratorEx, 15 A dvicea pplica tion )) 16 && args (*, meth,*, parent )); // het aanmaken van aspectof, hasaspect, pointcut aspectcodegencontext ( Aspect parent ): 20 cflow ( 21 execution ( public void 22 abc. weaving. weaver. AspectCodeGen. fillinaspect ( 23 Aspect )) 24 && args ( parent )); after ( Aspect parent ) 27 returning ( Host unit ): 28 stmtcreation () && aspectcodegencontext ( parent ){ 29 SootClass sc = 30 parent. getinstanceclass (). getsootclass (); 31 unit. addtag (sc. gettag (" SourceFileTag " )); 32 unit. addtag (sc. gettag (" SourceLnPosTag " )); 33 } after ( SootMethod meth, A dvicea pplica tion parent ) 36 returning ( Host unit ): 37 stmtcreation () && pointcutcodegencontext (meth, parent ){ 38 polyglot. util. Position pos = 39 parent. advice. getposition (); 40 unit. addtag ( new SourceFileTag ( pos. file ())); 41 unit. addtag ( new SourceLnPosTag ( pos. line (), 42 pos. endline (), pos. column (), pos. endcolumn ())); 43 } 44 }

57 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 56 taal wordt bijgehouden welke lijnen broncode in de outputtaal aangemaakt zijn. Dit is de source mapping(smap). Door alle opeenvolgende sourcemappings te combineren krijgt men een resolved SMAP die een stratum afbeelt op Java broncode. Deze SMAPS kunnen in de classfile verpakt worden. Alle JPDA-implementaties die JSR-45 ondersteunen zijn in staat om op basis van deze omzettingstabbellen en de standaard Javalijnnummerinformatie de juiste lijnnummers te outputten voor alle beschikbare strata. Het enige struikelblok voor het gebruik hiervan is dat ABC geen source-to-source compiler is. Daarom is het noodzakelijk om een virtuele broncode aan te maken. Deze broncode heeft juist een lijn voor elke jimple-instructie. Er wordt dan een SMAP aangemaakt die de juiste lijnnummers mapt op de virtuele source. De lijnnummers voor het Java-stratum worden vervangen door de virtuele nummers. Dit zorgt ervoor dat een debugger die JSR-45 niet ondersteunt enkel de virtuele lijnnummers te zien krijgt, die op zich betekenisloos zijn. Een technische ingreep is nog nodig om dit geheel te doen werken en dat is het opensmeren van de lijnnummers. In de standaardimplementatie zijn lijnnummers enkel bevestigd op de eerste instructie die dit nummer draagt. Ingeweven code kan dit gebied onderbreken en het is dus nodig om deze tag te repliceren naar al de volgende instructies. Oorspronggebasseerde lijnnummering werk dus in op de compiler in jimplify methods en weave. Het opensmeren wordt is een onderdeel van jimplify methods. De weaving moet voorzien worden van een aspect. En vlak na de weaving moeten de lijnnummers gevirtualiseerd worden. De virtualisatie kan de SMAP al klaar maken om in de class file verpakt te worden en de aggregatie van de lijnnummers is al onderdeel van de output stage, dus er is geen extra werk meer in de output stage Aspectinformatie De agent moet weten welke klassen eigenlijk aspect zijn, wat hun scope is, hun adviezen, de pointcut, het type en de signatuur van elk advies. Extra informatie die nuttig kan zijn, zijn de begin- en eindlijnnummers van de adviezen en het aspect. Als deze informatie is beschikbaar in de GlobalAspectInfo singleton. Dit is de groene lijn in figuur 4.5. Vlak voor het weaven kan al deze informatie verzameld worden, gefilterd en aan de klasse bevestigd worden als een AspectTag die klaar is voor output. Het filteren houdt in dat synthetische adviezen, zoals CFLOW setup (zie paragraaf 4.2.3), uitgefilterd worden Crosscuttinginformatie De crosscuttinginformatie bestaat uit een lijst met alle inwerkende joinpoints die aan elke methode bevestigd wordt. Voor elk joinpoint wordt bijgehouden wat het type is, het lijnnummer, de begin- en eindinstructie van de ingevoegde code en alle adviestoepassingen die inwerken op dat joinpoint. Per adviestoepassing wordt het residue bijgehouden en een referentie naar het advies. Deze referentie bestaat uit de naam van het aspect en de naam en signatuur van de implementerende methode.

58 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 57 Welke adviezen aangrijpen op welke methode is terug te vinden in de GlobalAspectInfo singleton. Deze informatie kan dan gesorteerd worden per joinpoint en alle informatie over adviestoepassing kan hieruit afgeleid worden. Deze informatie wordt in een CrossCuttingTag verpakt en aan de methode bevestigd. Dit kan gebeuren op elk moment na de matching. Het laatste stukje informatie dat we nodig hebben is de eerste en laatste instructie van een joinpoint om de stacktrace correct te kunnen weergeven. Het verkrijgen van deze informatie is een probleem dat analoog is aan dat van op oorspronggebaseerde lijnnumering omdat de informatie enkel beschikbaar is wanneer de instructies aangemaakt worden, maar zich hoger in de stack bevindt. Hiervoor bestaat een aspect, nagenoeg identiek aan dat van Listing 4.10 dat AdviceApplicationTags aanbrengt op de betrokken instructies. De aggregatie van al deze gegevens is iets ingewikkelder omdat de informatie in tags zit, verspreid over alle mogelijke klassen. De aggregatie heeft pas zin als alle instructies omgezet zijn in baf, vlak voor het aanmaken van de classfile. Dit is zo omdat het bijhouden van referenties naar instructies zinloos is omdat de instructies toch verloren gaan in de omzetting van jimple naar baf. De informatie moet dus in tags verpakt blijven tot in de output stage. De aggregatie is dus mee gepland in de finale aggregatiepass van Soot als BodyTransformer. Soot biedt alle method bodies aan de transformer aan op het meest geschikte moment. Als de methode adviezen bevat wordt de aggregatie aangevat. Eerst worden alle joinpoints die opgeslagen liggen in de CrossCuttingTag van de methode overlopen. Er wordt een map aangelegd die adviestoepassingen afbeeldt op joinpoints. Dan wordt het lichaam van de methode overlopen. Als een AdviceApplicationTag gevonden wordt, wordt deze verwijderd en het bijhorende joinpoint wordt opgezocht in de map. Als er nog geen eerste instructie gekend is voor het joinpoint, wordt de huidige instructie opgeslagen als de eerste en laatste instructie. Anders wordt ze enkel opgeslagen als de laatste. Met dit simpele algoritme worden de joinpoints van begin en eind instructie voorzien. 4.6 Backend De back-end volgt de voorgestelde referentie architectuur uit paragraaf De back-end moet in staat zijn attributen uit de classfiles te halen. De JVM en JPDA zijn hiertoe niet in staat. Daarom wordt gebruikgemaakt van de Byte Code Engineering Library (BCEL). De agentproctol controller zal, wanneer nodig, classfiles inladen en alle nuttige attributen hiervan decoderen en cachen. Deze back-end moet dus toegang hebben tot de classfiles. De providers aggregeren deze gegevens. Dit is meestal een simpele herverpakking, maar er zijn enkele speciale gevallen. In de CrossCuttingInfoProvider is de query die alle applicaties van een advies opvraagt een beetje een probleem, omdat applicaties enkel zijn opgeslagen in de methode waarop ze van toepassing zijn. Hiervoor moet de back-end dus alle methoden van alle geladen klassen overlopen en doorzoeken. Om te weten te komen welke klassen geladen

59 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 58 zijn heeft de CrossCuttingInfoProvider rechtstreekse toegang tot het VirtualMachine spiegelobject nodig. Deze provider krijgt dus via zijn constructor een referentie mee naar het VirtualMachine spiegelobject. Een andere mogelijk oplossing voor dit probleem zou het opslaan van de reverse mapping zijn in de classfile of een aparte debug assembly. Dit is sneller maar kan minder consistentiegaranties geven. De AspectInstanceProvider is natuurlijk ook een speciaal geval omdat hij methoden uitvoert in de doel VM. Om een aspectinstantie te vinden, komt dit neer op het uitvoeren van de aspectof() methode. De query om voor een per object aspectinstantie het juiste object te vinden werkt iets anders. Omdat deze mapping nergens wordt bijgehouden, ontstaat er een probleem. Gelukkig heeft JDI 1.6 de mogelijkheid om alle objecten die naar een andere object refereren op te vragen. Hiermee kan het juiste object makelijk opgespoord worden. De StackFilterManager en de FilterManager delen heel wat functionaliteit, daarom zijn ze uitgevoerd in één klasse. De FilterManager filtert synthetische entiteiten en advies methode weg. De synthetische entiteiten worden herkend aan bepaalde patronen, zoals de string abc$ of et$accessor$ die in de namen van synthetische velden voorkomen. De AspectInfoProvider wordt ook geraadpleegt om te zien of een klasse een aspect is. Als dit het geval is, worden de hasaspect() en aspectof() methoden verborgen. Adviesmethoden worden ook langs de AspectInfoProvider opgespoord en weggelaten. De StackFilterManager gebruikt enkel het interne back-end-protocol en een deel van de methodefilter. Alle stackframes waarvan de methode synthetisch is, worden weggelaten. Voor elke stackframe wordt er nagekeken of er joinpoints aangrijpen op de betreffende methode. Als dit het geval is wordt nagegaan of de instructie counter tussen de begin- en eindinstructie van een joinpoint ligt. Als dit zo is wordt er een HookFrame ingevoegd. 4.7 Resultaat Het doel van de AspectJ-implementatie was het testen van de architectuur en het onderzoeken van de mogelijkheden. Alle mogelijkheden die de architectuur op dit moment ondersteunt, kunnen door de AspectJ-back-end ingvuld worden. Zelfs met deze beperkte subset vormt dit een debugging API voor AspectJ die unieke mogelijkheden biedt. Hieruit kunnen we besluiten dat spiegel-reflectie van aspectsystemen waardevol en haalbaar is. Langs de andere kant heeft AspectJ nog mogelijkheden die AJDI niet ondersteunt, of waar meer detail geboden kan worden. De meeste van deze verbeteringen zouden zeker nog met de huidige architectuur ondersteund kunnen worden. Ook de architectuur heeft zijn nut bewezen: de volledige debugging functionaliteit kan aangeboden worden door implementatie van een back-end die volledig afgescheiden is van de front-end. Het implementeren van de back-end is vrij simpel. De echte complexiteit zit in de agent en de front-end. De front-end is herbruikbaar, dus de grote inspanning ligt bij de agent. Bij het construeren van de agent is het probleem het begrijpen van de compiler en

60 HOOFDSTUK 4. EERSTE VALIDATIE: EEN DEBUGGER VOOR ASPECTJ 59 het verzamelen van de gegevens. De studie van de compiler kost veel tijd en moeite. Als de agent echter zou worden gemaakt door de ontwerper van de compiler, zou dit zeer vlot kunnen gebeuren.

61 Hoofdstuk 5 Tweede validatie: een debugger voor JBoss Zoals vermeld in 1.4 is het doel van de JBoss AOP-implementatie om aan te tonen dat de architectuur bruikbaar is op een radicaal verschillend doelplatform. Er zal dus maar een minimale ondersteuning zijn. Alle functionaliteiten, behalve oorspronggebaseerde lijnnummering en aspectinstantie-afspiegeling worden ondersteund, maar minder volledig: enkel method execution joinpoints worden ondersteund, geen ondersteuning voor lijnnummers bij XML en annotaties,... Ik beperk me bij JBoss tot het minimum omdat JBoss AOP slecht gedocumenteerd is. Verder wordt er ook bytecode aanmaakt tijdens de uitvoering, wat de decompilatie moeilijk maakt. Omdat JBoss AOP vooral snel moet zijn, is alle code gericht op snelle uitvoering en niet op het verzamelen van informatie. Dit alles maakt de code complex en moeilijk begrijpbaar. Volledige ondersteuning zou om praktische redenen te veel tijd kosten. Eerst zal ik een technisch overzicht geven van de relevante onderdelen van JBoss AOP. Daarna zal ik de werking van de ADB back-end en de ADB agent voor JBoss AOP bespreken. Om te besluiten zal ik de resultaten overlopen. 5.1 JBoss in relatie tot AJDI De relaties tussen JBoss- en AJDIentiteiten is één-op-één, dit is duidelijk te zien in figuur 3.3 en figuur 5.1. De mapping van JBoss joinpoints naar AJDI joinpoints is ook goed in die zin dat alles modelleerbaar is, maar er is toch ook een verlies aan informatie. In figuur 5.2 is duidelijk te zien dat er veel verschillende soorten joinpoints afgebeeld worden op statement joinpoints. Hier is zeker nog plaats voor verfijning van het joinpoint model. Method en constructor execution worden ook afgebeeld op één type, maar hier kan men achteraf het onderscheid nog maken. Pinit, sinit en advice execution komen nooit voor. 60

62 HOOFDSTUK 5. TWEEDE VALIDATIE: EEN DEBUGGER VOOR JBOSS 61 Figuur 5.1: Statisch JBoss ER model Figuur 5.2: Joinpoints in AJDI en AspectJ

63 HOOFDSTUK 5. TWEEDE VALIDATIE: EEN DEBUGGER VOOR JBOSS JBoss weaving model In deze sectie worden de algemene AOP-functionaliteiten besproken van JBOSS AOP die nodig zijn om een minimale debugger-back-end te bouwen. Mixins, containers, etc komen niet ter sprake. Enkel method execution joinpoints worden behandeld. Om de uiteenzetting begrijpbaarder te maken is er een object diagram (figuur 5.2) dat de structuur weergeeft van de pointcut uit Listing 2.3 en een sequentie diagramma (figuur 5.4) dat de controleflow weergeeft bij uitvoering van de geadviseerd methode Test.method(). In JBoss AOP zijn er drie soorten weaving: er is weaving die voor het inladen van de klasse moet gebeuren, er is on-the-fly weaving en hot swapping. De eerste soort wordt gebruikt om joinpoints voor te bereiden. Na het inladen van de klasse kunnen er dus geen nieuwe joinpoints toegevoegd worden. On-the-fly weaving wordt gebruikt om adviesketens op te stellen. Hot swapping kan gebruikt worden om ongebruikte, maar voorbereide joinpoints sneller te laten uitvoeren Het voorbereiden van joinpoints bestaat in de eerste plaats uit het vinden van alle nodige joinpoints. Als een klasse een joinpoint bevat, wordt dit joinpoint voorbereid. Het voorbereiden omvat twee stappen: ten eerste wordt de klasse voorzien van drie advisor velden en de interface Advised. Ten tweede worden de instructies die het joinpoint vormen vervangen door een aanroep naar het raamwerk. Advisors zijn delegates die instaan voor de aspectgerelateerde gedragingen. Het eerste advisorveld is het statische veld aop$classadvisor$aop van het type Advisor. Dit veld bevat de advisor voor deze klasse. Het tweede veld is instanceadvisor$aop van het type InstanceAdvisor. Dit veld wordt enkel gebruikt als deze instantie van het object een specifieke adviesketen heeft. Het derde veld is currentadvisor$aop van het type Advisor. Het verwijst naar de classadvisor als er geen instance-advisor beschikbaar is, anders verwijst het naar de instance-advisor. De advisorinstanties die in de advisorvelden van een klasse zitten zijn van een type dat door middel van load time weaving speciaal is aangemaakt voor deze klasse. Dit type bevat een veld en een methode voor elk joinpoint in die klasse. De joinpointvelden zijn van een type dat uniek is voor dit joinpoint en dat overerft van Invocation. Als één van de joinpointmethoden aangeroepen wordt probeert ze haar bijhorend veld te vullen, als dit lukt roept ze de invokejoinpoint() methode op van haar invocationobject, als dit niet lukt roept ze de originele code van haar joinpoint aan. Het vullen van het veld is meer dan een gewone instantiatie van een object. Om het gebruik van reflectie voor het aanroepen van adviezen te voorkomen, wordt er een nieuwe type aangemaakt waarin de advice chain hardcodegehardcoded is. Dus telkens de adviesketen aangepast wordt, wordt er door middel van on-the-fly weaving een subtype van het unieke joinpointtype aangemaakt. Door middel van reflectie wordt er een instantie aangemaakt en deze wordt in het juiste veld opgeslagen. Een tweede verandering die elk joinpoint ondergaat is het verhuizen van de instucties die het joinpoint vormen naar een nieuwe methode, waarna ze vervangen worden door een aanroep van hun bijhorende joinpointmethode in de huidige advisor. De methode zal indien nodig het invocationobject aanmaken en hiervan de invokejoinpoint() methode

64 HOOFDSTUK 5. TWEEDE VALIDATIE: EEN DEBUGGER VOOR JBOSS 63 aanroepen. Hierdoor zal het invocationobject een nieuwe instantie van zichzelf aanmaken en hierop invokenext() aanroepen. Hierdoor wordt de adviesketen doorlopen. Al deze verrichtingen worden aangestuurd door een centrale component: de Aspect- Manager. Deze component is een goed beginpunt om de zoektocht naar debuginformatie te beginnen. 5.3 JBoss weaving model in relatie tot ADB De mapping van JBoss-entiteiten op Java-entiteiten is te zien in figuur 5.5. Hier kunnen we enkele opvallende vaststellingen doen: een Java-klasse kan meerdere JBoss aspecten en één JBoss klasse terzelfdertijd zijn, een advies kan op meer dan één methode afgebeeld worden en één methode kan meerdere adviezen vormen. Een Java-klasse kan zowel aspect als klasse terzelfdertijd zijn omdat JBoss geen poging doet om dit te voorkomen. De progammeur doet met klassen die als aspect gebruikt worden wat hij wil. Langs de andere kant is het mogelijk om dezelfde klasse te gebruiken om meerdere aspecten te declareren en hierdoor kan één methode meerdere adviezen zijn. De architecturale beperking op uniciteit van types is dus geschonden. Het is dus niet mogelijk om JBoss AOP-programmas die zich niet aan de 1-op-1 relatie houden correct te debuggen. Een advies kan bestaan uit meerdere methoden met dezelfde naam en een verschillend argument. Het argument moet altijd een subtype van Invocation zijn. Als dit het geval is, zal het advies enkel aangeroepen worden als het aanroepende joinpoint van het juiste type is. Dit soort overloading kan beschouwd worden als een splitsing van het advies in verschillende adviezen met een residu dat het joinpointype nakijkt. Op deze manier Figuur 5.3: Object en type structuur van de pointcut uit Listing 2.3