(Note: I tried replying to your blog but my remark did not appear there)

Nice idea to use AOP to address a problem in AOP.

Two remarks though:
- AspectJ is _not_ a proxy-based AOP solution so you would not have the problem there. It’s only when using Spring 1.x’s proxy-based AOP stuff that you’d have to aware of the problem I described.
- You can use inter-type declarations to introduce the member “proxy” in all @Proxied classes. See
http://www.eclipse.org/aspectj/doc/released/progguide/starting-aspectj.html#inter-type-declarations

Regards, Vincent.

Regarding the AopContext solution, I think this is not a real solution anyway.

In this case the class itself must know that there is an advise applied to some of its methods. In the case of the BankAccount this may seam trivial, but lets look at an even more down to earth example.

The textbook case for applying Aop would be logging or monitoring. Lets assume that we have a simple logging advice that we want to apply on each method of the interface.

Then the developer of each class must know whether this class will always have the advide applied to it. Sounds a little like mixing of concerns.

If we then want to turn of (and on again) the logging in a production environment we have to change all the code again. Like I saym not a real solution.

Just my five cents.

KR

Patrick

Regards, Vincent.

./alex
–
.w( the_mindstorm )p.
AspectWerkz developer

In applications where one comes across this issue occasionally, and one is not ready to use LTW, one can use the AopContext solution.

On any ProxyFactoryBean you can set the ‘exposeProxy’ property to ‘true’ (it is false by default, for performance reasons, but the performance impact is very small.)

This property cooperates with the class org.springframework.aop.framework.AopContext, in such a way that it makes the AOP proxy available to the proxied instance.

Sounds complicated?

An example:

Say your BankService’s processPayment method needs to call checkCreditRating, but needs all security inerceptors to be invoked.

Instead of calling this.checkCreditRating(), it calls

BankService proxy = (BankService) AopContext.getCurrentProxy();
proxy.checkCreditRating();

It won’t receive any awards for beautiful code, but if not too frequently used, it is a good workaround.

I’ve used it in practice with one addition: to make unit testing easier; adding a fallback to an injectable property in the case that AopContext didn’t return a value. (Which occurs when running the code without an interceptor, in a unit test)

Regards,
Erwin

I expect a lot from the LTW features of AspectJ 5. Not only will it solve this deficiency of the proxy-based AOP solution, it will also allow developers to use the more exotic AOP features such as introductions.

Regards, Vincent.

yes, provy-based AOP solution do have this specific drawback, although I haven’t seen it become a real bottleneck in any of the projects I’ve encountered. Good to spread the word though, as knowing about it is a good first step.

Your security use case is one situation where the problem might occur, another is different propagation levels on method within the same class.

class MyClass {

// propagation=REQUIRES
void doIt() {
this.doIt2();
}

// propagation=REQUIRES_NEW
void doIt2() {
}
}

Note that Load-Time-Weaving (LTW) has solved lots of the deploytime configuration problems that AspectJ used to come with. Using LTW does involve some additional configuration, but you don’t necessarily have to issue a post compilation step anymore. This works nicely together with the new Java 5 agents.

cheers,
Alef