I read about guice AOP in the documentation here :- https://github.com/google/guice/wiki/AOP
From the documentation :-
Behind the scenes, method interception is implemented by generating bytecode at runtime. Guice dynamically creates a subclass that applies interceptors by overriding methods. If you are on a platform that doesn't support bytecode generation (such as Android), you should use Guice without AOP support.
What does the documentation means by extending the subclass. Is this the method interceptor subclass? Does it work by using reflection to intercept the method? The reason I ask this question is because in the documentation, this line is followed by this :-
Due to this, we have the following limitations on the guice AOP
a) AOP cannot be applied to a private method.
Unclear to me why AOP cannot be applied to a private method.
Unclear to me why AOP cannot be applied to a private method.
Because private methods are not inherited by subclasses, i.e. there is no way to intercept a private method and then delegate to it because the subclass cannot even call that method. This is a normal Java limitation and has nothing to do with AOP specifically.
BTW, if you want a full-fledged, powerful AOP tool working with any JVM language and able to intercept private methods without the need to resort to dynamic proxies (subclasses created during runtime like Guice or Spring AOP), just use AspectJ.
What does the documentation means by extending the subclass.
The JRE knows the concept of dynamic proxies in order to be able to intercept method calls and (optionally) delegate to the original call before/after doing something else in an interceptor method. This works for interfaces only, but CGLIB extends this concept to subclasses of non-interface classes, which is why in proxy-based AOP frameworks such as Spring AOP (and maybe Guice, not 100% sure) proxies are used in order to implement AOP. AspectJ works differently, it does not use or need any dynamic proxies or other types of subclasses.
Related
Baeldung has this section:
this limits matching to join points where the bean reference is an
instance of the given type, while target limits matching to join
points where the target object is an instance of the given type. The
former works when Spring AOP creates a CGLIB-based proxy, and the
latter is used when a JDK-based proxy is created. Suppose that the
target class implements an interface:
public class FooDao implements BarDao {
...
}
In this case, Spring AOP will use the JDK-based proxy, and we should
use the target PCD because the proxied object will be an instance of
the Proxy class and implement the BarDao interface:
#Pointcut("target(com.baeldung.pointcutadvice.dao.BarDao)")
On the other hand, if FooDao doesn't implement any interface, or the
proxyTargetClass property is set to true, then the proxied object will
be a subclass of FooDao and we can use the this PCD:
#Pointcut("this(com.baeldung.pointcutadvice.dao.FooDao)")
I'm still confuse why this just works with CGLIB proxy and target just works with JDK proxy. Could you help to tell me the different between them?
Actually, the explanation in the tutorial does not make much sense:
Both this(MyInterface) and target(MyInterface) work for JDK proxies, if the bean is declared as a MyInterface type.
Both this(MyClass) and target(MyClass) work for CGLIB proxies, if the bean is declared as a MyClass type.
Just try, and you will see that I am right. In Spring AOP, there is not real difference between this() and target(), because due to its proxy-based nature, it implicitly only supports execution() pointcuts from AspectJ.
In native AspectJ however, you also have other pointcut types such as call(), and there you would see a difference: this() would match the caller's type, while target() would match the callee's type. E.g., if you intercept a method A.a() calling B.b() via pointcut call(B.b()), this() would return an A instance, while target() would return a B instance. Do not worry, if this is difficult to understand for you, because for Spring AOP and execution pointcuts it really does not matter.
The only subtle difference I noticed in Spring AOP is, that for MyInterfaceImpl implements MyInterface, pointcut target(MyInterfaceImpl) would actually match, while this(MyInterfaceImpl) would not. This is because for JDK proxies, the proxy actually extends java.lang.reflect.Proxy, not MyInterfaceImpl. The proxy only delegates to a MyInterfaceImpl instance.
Edit: If you keep in mind that, in contrast to native AspectJ which involves no dynamic proxies, the semantics in Spring AOP are such that
this() relates to the proxy object, while
target() relates to the proxied object (proxy target),
it becomes clear why in this special case for JDK proxies target() matches, but this() does not.
Reference: Spring manual, section "Declaring a pointcut - examples":
this(com.xyz.service.AccountService): Any join point (method execution only in Spring AOP) where the proxy implements the AccountService interface.
target(com.xyz.service.AccountService): Any join point (method execution only in Spring AOP) where the target object implements the AccountService interface.
Only in this case, we are not asking for the interface class (which both the proxy and the target object implement), but for the implementation class itself.
Bottom line: For all intents and purposes, in normal use cases you can use either this() or target() for both JDK and CGLIB proxies. I recommend to stick with target(), because it best matches the implicit execution() semantics of Spring AOP, and usually you are interested in information about the target rather than about the proxy..
I am using AspectJ and Load-time weaving to trace methods calls in an arbitrary java program. I can trace all calls using the standard:
call(* *.*(..))
But what I now trying to do is separate out calls to the native java libraries and any application code:
nativeCalls(): !within(MethodTracer) && call(* java..*.*(..));
appCalls(): !within(MethodTracer) && call(* *.*(..)) && !call(* java..*.*(..));
The issue is that the nativeCalls() pointcut is picking out calls to application classes that inherit from native java classes, even though the signatures do not start with java.lang. or java.util, etc.
For example:
If I have a class tetris.GameComponent that inherits from java.awt.Component, my nativeCalls() pointcut will pick out tetris.GameComponent.getBackground() when the method is actually implemented in java.awt.Component.getBackground().
Is there a way to have my nativeCalls() pointcut ignore the calls to inherited methods?
I hope this is clear. I can provide additional info if necessary. Thanks for any help that can be provided.
Actually I have no idea why you want to exclude those inherited method calls from your trace because IMO it is important or at least interesting to know if a method was called on one of your classes, even if that method was defined in a JDK super class.
But anyway, the answer is no, you cannot exclude calls to JDK methods from your nativeCalls() pointcut if those calls are actually made upon target objects typed to one of your application classes. At the time the call is made, AspectJ does not know how the JVM will resolve the polymorphism. There can be several cases:
Call to Foo.aaa(), existing method Foo.aaa() is executed. This is the simple case where a called method actually exists.
Call to Foo.bbb(), inherited method Base.bbb() is executed (polymorphism). This is the case you want to exclude, but you cannot because the fact that a base method is called will only be known when the method is executed. Furthermore, if Base is a JDK class, you cannot even intercept its method executions with AspectJ.
Call to Base.ccc(), non-overridden method Base.ccc() is executed. This can happen if you directly create an instance of Base or also if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ccc() which has not been overridden by Foo.
Call to Base.ddd(), overridden method Foo.ddd() is executed (polmorphism). This also happens if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ddd() which has been overridden by Foo.
So much for not being able to easily exclude the polymorphism stuff when calling inherited JDK method.
Now the other way around: You can easily intercept execution() instead of call() upon your application classes and take advantage of the fact that JDK method executions cannot be intercepted anyway: pointcut appMethod() : execution(* *(..));
I read this on a guideline
"When using Spring AOP always use interfaces so normal AOP proxying can be used (rather than CGLIB)"
What could than mean? I have very good idea on AOP and have implemented AOP myself before. But completely out of clue.
Simply said there are 2 way for proxying an object :
dynamic : you create a new object that implement the same interface than the target object and encapsulate this last in addition with the proxy logic
static : when you compile the target class you add the aspect logic directly into the compiled class (cglib way)
Dynamic proxy can only apply on object that implement an interface and will be used only if you reference the instance using the interface (which is advised here) whereas static proxy can apply on everything
Following the spring guideline will allow you to use any of the method (you can simply switch using spring configuation) instead of being coupled to cglib.
Note than static proxy allow proxy logic to be applied even when you call a proxied method from another method inside the same class whereas with dynamic proxy the call must come from outside.
I'm using Autofac with DynamicProxy2 to intercept my classes like this
builder.RegisterType<Calculator>().As<ICalculator>().EnableInterfaceInterceptors()
.InterceptedBy(typeof (CallLogger));
This will intercept all methods on given interface.
Is there any way to intercept only particular methods of the interface ?
There are a couple of ways I can think of, and there are probably more out there.
You could create a custom attribute like [LogCall] or [DoNotLogCall] (opt in or opt out) and apply that to the methods to intercept, then check for the presence of the attribute inside CallLogger.
Or, you could configure the CallLogger with the names of (or rules to find) the methods that should be logged.
.NET 4.0 has that new Code Contracts feature. It works with interfaces too, as described here (scroll down to somewhere in the comments):
http://weblogs.asp.net/podwysocki/archive/2008/11/08/code-contracts-for-net-4-0-spec-comes-alive.aspx
Now my question is, can we use and abuse this "Default Interface Implementation Feature" by putting more custom code into those contract classes to achieve some MixIns functionality?
I don't think so. When defining code contracts for an interface, you can add a rela class that contains "requires" and "ensures" method calls that will be added to implementation methods, but the code rewriter will only run after the compiler has done its job (ie complaining that the interface method is not implemented by the class...)
Might be abused to implement aspects, though :-)
Anyway, I don't think the code rewriter would add anything else than requires and ensures method. And the code would not be added to the release assembly, only on the debug assembly.