[Spring+AOP] Around advice op niet niet-container objecten

[Cuball]

Ik ben nu al enige tijd aan proberen, maar krijg het niet geklaard. Ik zou geen discussie willen opstaren omtrent de opzet van mijn probleem, maar ik zou een oplossingen moeten vinden hiervoor.

Ik heb een Class TestPerson

Java:

public Class TestPerson {
private Client client;

public Client  getClient() {
   return this.client;
}
...

Deze TestPerson klasse is een entity domainobject die aangemaakt wordt door hibernate. Nu zou ik willen een around advice schrijven op de getClient() methode van TestPerson. Volgende code heb ik in de applicationContext staan:

code:

    <bean id="retrieveClientExecutorBean" class="be.oz.ozfit.vo.aop.RetrieveClientExecutor">


    <aop:aspect id="retrieveClient" ref="retrieveClientExecutorBean">
            <aop:pointcut id="retrieveClientMethod"  expression="execution(public * be.xxx.TestPerson.getClient(..))"/>
           <aop:around
               pointcut-ref="retrieveClientMethod"
               method="retrieveClientOperation"/>
     </aop:aspect>

en natuurlijk de RetrieveClientExecutor ook

Java:

public class RetrieveClientExecutor {
      
       public Object retrieveClientOperation(ProceedingJoinPoint pjp) throws Throwable { 
           System.err.println("voor getClient operation");
              Object value= pjp.proceed();
             System.err.println("na getClient opeartion");
             return value;
       }

}

Op bovenstaande manier was ik eerst bezig, maar daar zag ik iets over het hoofd, de TestPerson klasse is nu een door hibernate "enhanced" klasse geworden, dus ik denk dat Spring er hier niet aankan. Ik heb dan gekeken in de handleiding en heb er een stuk gevonden over "Using AspectJ to dependency inject domain objects with Spring" maar daarin maken ze gebruik van Annotations. Aangezien we voor dit project geen annotations gebruiken vroeg ik me af of het wat ik wel wil opzetten enigsinds mogelijk is zonder gebruik van annotations?

[Alarmnummer]

De reden dat het niet werkt, is dat de bean niet door de applicationcontext wordt aangemaakt en het geen echte echte aspectj is. Als je de handleiding goed doorleest (was bij mij ook lang onduidelijk) dan zie je dat het nog steeds de proxy based versie (Spring AOP) is, ook al ruikt het naar AspectJ.

Je kunt gerust een aspectj aspect (dus weaving ipv proxy geneuzel) om een willekeurig object plaatsen. Daar ben je Spring niet voor nodig. Als je een aspectj aspect hebt, dan kan je het om willekeurige objecten lijmen (ook al worden die objecten niet aangemaakt door de appcontext).

Maar wat probeer je te bereiken? Stukje logging om een call heen?

[ Voor 36% gewijzigd door Alarmnummer op 21-12-2006 13:06 ]

[Cuball]

Met weaving ben ik totaal nog niet vertrouwd, ik zal wat opzoek werk moeten uitvoeren dan...

Nu heb ik het inderdaad zo opgezet dat er een around advice gebruikt wordt, maar voor wat ik op ogen heb zou ik evengoed een "repository" in men domein object willen injecteren, maar zoals je al zei, door dat dit object deze niet aangemaakt wordt door de container ben ik genoodzaakt andere oplossingen te zoeken.

Is het mogelijk om zonder annotations maar met weaving dergelijk probleem op te lossen ?

[Alarmnummer]

Cuball schreef op donderdag 21 december 2006 @ 13:10:
Met weaving ben ik totaal nog niet vertrouwd, ik zal wat opzoek werk moeten uitvoeren dan...

Nu heb ik het inderdaad zo opgezet dat er een around advice gebruikt wordt, maar voor wat ik op ogen heb zou ik evengoed een "repository" in men domein object willen injecteren, maar zoals je al zei, door dat dit object deze niet aangemaakt wordt door de container ben ik genoodzaakt andere oplossingen te zoeken.

Is het mogelijk om zonder annotations maar met weaving dergelijk probleem op te lossen ?

Er staat me bij van wel. Je kunt geloof ik een 'template' bean maken in je applicationcontext:

code:

<bean id="com.foo.Persoon" class="com.foo.Persoon">
    <property name="persoonDao" ref="persoonDao"/>
</bean>

Op basis van deze template kan aspectj dan een goed aangemaakt persoon aanmaken als dat nodig is.

Maar hoe dit precies zit weet ik ook niet meer.

Hou er verder ook rekening mee dat aspectj wel wat voeten in de aarde heeft. Je zult de vm ook moeten instrueren dat hij een bepaalde agent gebruikt, zodat aspectj op de hoogte gesteld wordt van nieuwe objecten. Staat wel in de documentatie hoe je dit moet doen.

Ik zou me dus 2 keer achter de oren krabben om aspectj te gebruiken (alhoewel ik de proxy versie ook niet geweldig vind aangezien het dus ook alles behalve transparant is).

algemene opmerking:
Het is erg jammer dat bij annotations, de annotations niet overgeerfd worden. Dus als jij een class/interface gaat extenden/implementeren, dan worden de annotations niet meegenomen.

Eigelijk denk ik dat annotations geen goeie abstractie zijn. Ik had liever gezien dat metadata volledig losgekoppeld was, van het mechanisme waarop die metadata tot stand komt. Dit kan een annotation in de source zijn, maar een extern xml bestand zou ook een optie zijn. Misschien dat er nog een keer een abstractielaag komt om dit op te vangen, en waarbij je ook meteen meer controle hebt over het overerven.

Spring documentatie raad verder (nu) ook aan om metadata op te nemen bij de implementerende class en niet bij de interface, puur om dit gezeik te voor komen. Imho een slechte ontwikkeling.

[ Voor 38% gewijzigd door Alarmnummer op 21-12-2006 13:27 ]

[Feyd-Rautha]

Cuball schreef op donderdag 21 december 2006 @ 13:10:
Met weaving ben ik totaal nog niet vertrouwd, ik zal wat opzoek werk moeten uitvoeren dan...

Is het mogelijk om zonder annotations maar met weaving dergelijk probleem op te lossen ?

Weaven is gewoon het toepassen van uw aspecten op de base-code. Dit kan statisch (compile-time) gebeuren, of dynamisch (at run-time) gebeuren.

Ik vind het een beetje raar dat je bezig bent met AOP en je kent de term 'weaving' niet.

[Alarmnummer]

Feyd-Rautha schreef op donderdag 21 december 2006 @ 13:36:
Ik vind het een beetje raar dat je bezig bent met AOP en je kent de term 'weaving' niet.

Normale Spring AOP, werkt mbv proxies en niet met weaving. Dus het valt op zich wel te verklaren.

[Cuball]

Feyd-Rautha schreef op donderdag 21 december 2006 @ 13:36:
Ik vind het een beetje raar dat je bezig bent met AOP en je kent de term 'weaving' niet.

ik heb niet gezegd dat ik de term weaving niet ken, maar heb er me gewoon nog niet erg veel mee bezig gehouden, voorlopig kon ik alles via de Spring container gaan uitvoeren, en zoals Alarmnummer zei proxy based aop oplossingen.

[Cuball]

Ik heb het nu via AspecJ gedaan en wat ik wel opgemerkt heb is dat mijn JVM enorm veel trager opstart bijna factor 4 (door de agent die ik toevoeg aan de JVM voor Load time weaving methode).

zijn er nog zaken waar je rekening mee moet houden als je gebruik maakt van AspectJ load time weaving? Geheugen, performantie van de JVM ? of is het enkel bij het opstarten dat de grootste vertraging merkbaar is ?

Of is het algemeen aangeraden compile-time weaving te gebruiken ?

[ Voor 13% gewijzigd door Cuball op 21-12-2006 16:32 ]

[Alarmnummer]

Cuball schreef op donderdag 21 december 2006 @ 16:09:
Ik heb het nu via AspecJ gedaan en wat ik wel opgemerkt heb is dat mijn JVM enorm veel trager opstart bijna factor 4 (door de agent die ik toevoeg aan de JVM voor Load time weaving methode).

Dat komt omdat alle classes nu bekeken worden om te adviseren Je moet daarom ff in je meta-inf dir een aop.xml bestand aanmaken met daarin de packages die geinspecteerd moeten worden.