¿Aspectj no capta todos los eventos en el marco de primavera?

Question

Mi proyecto se basa en Spring Framework 2.5.4.Y trato de agregar aspectos para algunos controladores (uso aspectoj 1.5.3).

Habilité el proxy automático en application-servlet.xml, simplemente pegué estas líneas al final del archivo xml:

<aop:aspectj-autoproxy />
<bean id="auditLogProcessor" class="com.example.bg.web.utils.AuditLogProcessor" />

Aspecto creado:

package com.example.bg.web.utils;

import org.apache.log4j.Logger;
import org.aspectj.lang.annotation.After;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class AuditLogProcessor
{
    private final static Logger log = Logger.getLogger(AuditLogProcessor.class);

    @After("execution(* com.example.bg.web.controllers.assets.AssetThumbnailRebuildController.rebuildThumbnail(..))")
    public void afterHandleRequest() {
        log.info("test111");
    }

    @After("execution(* com.example.bg.web.controllers.assets.AssetThumbnailRebuildController.rebuildThumbnail(..))")
    public void afterRebuildThumbnail() {
        log.info("test222");
    }
}

Mis controladores:

class AssetAddController implements Controller
class AssetThumbnailRebuildController extends MultiActionController

Cuando establecí puntos de freno en asesores de aspecto e invoco controladores que capto solo después de Handlerequest () pero no después de la corona de thumbnail () ¿Qué hice mal?

NOTA

Hago esta pregunta en nombre de mi amigo que no tiene acceso a SO beta y no tengo idea de qué se trata.

EDITAR

De hecho, hubo algunos errores ortográficos, gracias Cheekysoft.Pero el problema persiste.

Answer 1

Sus puntos de interrupción no se ven afectados porque está utilizando los proxies AOP de Spring.Ver comprensión-aop-proxies para obtener una descripción de por qué los Proxies AOP son especiales.

Básicamente, el marco MVC llamará al handleRequest método en el proxy de su controlador (que por ejemplo el MultiActionController que está utilizando como implementos de clase base), este método realizará una llamada "interna" a su método buildThumbnail, pero esto no pasará por el proxy y, por lo tanto, no detectará ningún aspecto.(Esto no tiene nada que ver con que los métodos sean definitivos).

Para lograr lo que desea, investigue el uso de AOP "real" mediante tejido de tiempo de carga (que Spring admite muy bien).

Answer 2

AspectJ no funciona bien con clases en el marco Spring Web MVC. Lea la parte inferior del cuadro "Abrir para extensión..." en el lado derecho de la página.

En lugar de eso, eche un vistazo a ManejadorInterceptor interfaz.

Las nuevas anotaciones de Spring MVC también pueden funcionar desde entonces, las clases de controlador son todas POJO, pero no lo he probado yo mismo.

Answer 3

La configuración básica parece estar bien.

La sintaxis se puede simplificar ligeramente al no definir un punto de corte in situ y simplemente especificar el método al que se debe aplicar el consejo posterior.(Los puntos de acceso con nombre para los métodos se crean automáticamente).

p.ej.

@After( "com.example.bg.web.controllers.assets.AssetAddController.handleRequest()" )
public void afterHandleRequest() {
    log.info( "test111" );
}

@After( "com.example.bg.web.controllers.assets.AssetThumbnailRebuildController.rebuildThumbnail()" )   
public void afterRebuildThumbnail() {
    log.info( "test222" );
}

Siempre que el método buildThumbnail no sea definitivo y el nombre del método y la clase sean correctos.No veo por qué esto no funcionará.

ver http://static.springframework.org/spring/docs/2.0.x/reference/aop.html

Answer 4

¿Es esto tan simple como la ortografía?¿O simplemente hay errores tipográficos en la pregunta?a veces escribes rebuildThumbnail y a veces escribes rebildThumbnail

Los métodos que intenta anular con consejos no son métodos finales en el marco MVC, por lo que, si bien la respuesta de bpapas es útil, tengo entendido que este no es el problema en este caso.Sin embargo, asegúrese de que el rebuildThumbnail la acción del controlador no es definitiva

@bpapas:Por favor corrígeme si estoy equivocado.La propia acción del controlador del programador es lo que intenta anular.Al observar la fuente de MultiActionController (y sus padres), el único método finalizado potencialmente en la pila es MultiActionController.invokeNamedMethod, aunque no estoy 100% seguro de si esto estaría en la pila en ese momento o no.¿Tener un método finalizado más arriba en la pila causaría un problema al agregar consejos de AOP a un método más abajo?