2011-12-08 7 views
5

Uso il meccanismo di astrazione della cache da RC 3.0 Spring: ho impostato il codice byte (basato su AspectJ) in modo che il meccanismo della cache possa essere applicato ai metodi richiamati dalla classe stessa. Vale la pena di dire che prima stavo usando l'approccio basato su proxy: (. Per i metodi vengono richiamati da un altro oggetto) tutto funzionava beneProblemi di memorizzazione nella cache di Spring quando si utilizza AspectJ LTW

Appena posso passare al AspectJ (ho attivato LTW via, aggiunto i vasi giusti al loro posto - tutto funziona bene, nessuna eccezione viene lanciata, nessuna memorizzazione nella cache avviene

Qualche suggerimento? Grazie.

==== successivamente modificare ========

ho istituito i registri per eseguire il debug per org.springframework.

Se si utilizza la modalità proxy, posso vedere chiaramente il messaggio Aggiunta metodo di cacheable 'getLargeAssetContent' .... dove getLargeAssetContent è il mio metodo "cacheable" ... (vedi sotto)

Se si utilizza la modalità AspectJ, Non vedo questo messaggio .... ogni richiesta va al livello DAO ... dove come, nella situazione in cui la cache funziona, le richieste si fermano al livello di servizio.

Cosa sto facendo male? Ho bisogno di un aop.xml? Non stavo usando AOP ...., quindi non ho ancora un aop.xml.

Grazie per il vostro aiuto.

*> * 2011-12-12 16: 38: 55.998 DEBUG [org.springframework.cache.annotation.AnnotationCacheOperationSource]

(http-127.0.0.1-8080-6) Aggiunta metodo cacheable ' getLargeAssetContent' con l'attributo: [CacheOperation [pubblico com.mycompany.myprj.model.AssetContent com.mycompany.myprj.dao.jcr.AssetDAOImpl.getLargeAssetContent (java.lang.String) getta com.mycompany.myprj.dao .MyPrjPersistenceException] cache = [risorse] | condizione = '' | key = '# nodeId'] 2011-12-12 16: 38: 56,013 INFO [com.mycompany.myprj.dao.jcr.AssetDAOImpl] (http-127.0.0-8080-6) Ottenere il contenuto (getLargeAssetContent) della risorsa dal nodo con id = 575d8dc0-01be-41e4-85ce-a654fab97fe8 2011-12-12 16: 38: 56,092 INFO [com.mycompany.myprj.dao.jcr.AssetDAOImpl] (http-127.0.0.1- 8080-6) Tornando il contenuto di risorsa dal nodo con id = 575d8dc0-01be-41e4-85ce-a654fab97fe8 **

*

// il conte nt viene memorizzato nella cache ora 2011-12-12 16: 38: 57,654 DEBUG [org.springframework.beans.factory.support.DefaultListableBeanFactory] (http-127.0.0-8080-6) Restituzione dell'istanza memorizzata nella cache del bean singleton ' assetController '2011-12-12 16: 38: 57,654 DEBUG [org.springframework.web.servlet.DispatcherServlet] (http-127.0.0-8080-6) Valore Ultima modifica per [/ myprj/asset/get/575d8dc0-01be-41e4-85ce-a654fab97fe8] è: -1 2011-12-12 16: 38: 57,654 INFO [com.mycompany.myprj.services.AssetService] (http-127.0.0.1-8080-6) Ottenere bene con id: 57

*

+0

Quando hai detto abilitato LTW, hai aggiunto '' nel tuo contesto, giusto? – Kilokahn

+0

Sono di fronte e = lo stesso identico problema. Sei riuscito a trovare una soluzione? –

+0

Quindi, non riesco ancora a farlo con LTW. Tornare indietro alla modalità proxy per ora. –

risposta

1

Accertarsi che la modalità AspectJ è abilitato (vedi 28.3.3 Enable caching annotations):

<cache:annotation-driven mode="aspectj"/> 

per astrazione la cache di default utilizza la modalità proxy, nonostante abbia abilitato LTW (dovrebbe passare automaticamente a aspectj IMHO, ma non lo fa).

Se questo non aiuta a esaminare la traccia dello stack quando si chiama il metodo memorizzato nella cache dall'esterno e dall'interno - quali sono le differenze?

+0

Grazie, ma l'ho fatto (). Proverò a cercare le tracce. – silverb77

+2

Solo per curiosità, qualcuno è riuscito a far funzionare questa cosa? (cioè usando l'astrazione di caching con l'aspettoj) – silverb77

0

ho provato con un progetto di esempio e aveva bisogno di fare quanto segue per passare dalla delega regolare per AspectJ LTW

  • Change <cache:annotation-driven mode="aspectj"/>
  • Aggiungere aspectj tessitore e la primavera-aspetti al classpath (facile identifica di fronte alla ClassNotFoundException generata)
  • Avere un aop.xml predefinito in un META-INF/aop.xml (questo è con le impostazioni e la configurazione predefinite per le classi proxy nel mio pacchetto specifico - altrimenti eseguirà le classi proxy nel intera JVM - a cui è necessario rispondere)
  • Aggiungi <context:load-time-weaver aspectj-weaving="on"/> (di default è autodetect che fallire in modo silenzioso se META-INF/aop.xml non viene trovato)
  • Aggiungere l'interruttore javaagent la VM e puntarlo al barattolo molla strumento se lo si utilizza autonomo. Se si è in un contenitore, è possibile utilizzare javaagent o configurarlo su uno specifico programma di caricamento classi come indicato nello reference.