Proxies are an important piece in the J2EE puzzle. They are powerful in that they offer a non-intrusive and more transparent way of weaving in advice/interceptors. However, none of the current proxy implementations utilizes all the rich semantics of AOP (as defined by AspectJ), the expressiveness of a real pointcut pattern language and has the speed of statically compiled code.
AW Proxy is here to try to narrow this gap. It makes use of the rich semantics for AOP in AspectWerkz and is very high-performant due to the use of static compilation (utilizing the AspectWerkz weaver). All wrapped up a very simple and intuitive API.
Read more about it AW Proxy: Proxy on steroids
I am eager to test it.
You guys rock. Been hoping for something like this in AW so this is great. Congrats on the performance numbers.
That's a nice replacement for CGLIB, but not more I think. I can't find any reach AOP semantic there. Yes, there some pointcut like Strings for selecting method name and return values but not more. Pointcut language contains other very powerfull features like conditions, unions, context values etc.
AW is a good AOP framework, but this proxy has nothing to do with AOP.
The main advantage over regular Proxy is perfomance, but AFAIK perfomance problems arise only using cflow type pointcuts and pointcuts like "* *.*(..)" or "!(pc())", then perfomance is essential, but for single objects....
We support unions, conditions, and context values:
The thing is that you can apply
- before, after, after returning, after throwing and around advices
- to any execution() pointcut on both methods and constructor - this is the sole limitation. This pointcut can be composed (or / and / not) with type related pointcut like within(), and can be used with cflow() as well (if the cflow target is himself exposed to AOP), and with bindings like args(), this(), target().
f.e. execution(* samples.tracing.Trace*.*(..)) AND this(t) AND args(arg)
The poincut are not a simple string, but you can reuse one of the aspect you already have for "real AOP" and have it applied to any proxy you may manipulate.
This means that the aspect becomes totally unaware of the fact that you may use a real weaver or a proxy approach, and only the proxy based architecture narrows down the matching to method/constructor executions. That 's the tradeoff.
As regards performance, cflow() will impact the runtime but just as it would for regular aspects with our regular weaver, and "wide" pointcut like "within(*)" will affect the weaving time (not the runtime) hence the time for the proxy creation but just as it would for regular weaving - though the weaved proxy class can be explictly cached.
Thanks for the detailed response. As far as I understood folllowing
This pointcut can be composed (or / and / not) with type related pointcut like within(), and can be used with cflow() as well (if the cflow target is himself exposed to AOP), and with bindings like args(), this(), target()...
Does this means that I may use cflow(), within(), args() etc. for every class which is "proxied" by AW Proxy?
For within(), args(), this() / target(), yes, AWProxy supports it.
You can think of it like a world in which proxies are blessed and proxy types are handled like the class for which they are a proxy of.
When using cflow, it requires that the cflow state triggering (cflow enter / exit) has been weaved in. We cannot weave in a cflow thru a proxy, but advices affecting the proxy will execute according to the cflow state.
Congrats guys, looks like there has been a hell of a lot of work gone into AW recently. Will be giving AW 2.0 a go as soon as I get the chance :)
Ooops, CVS is still not compillable:
[javac] /usr/java/src/aspectwerkz4/src/test/test/annotation/AnnotationCTest.java:13: cannot resolve symbol
[javac] symbol : class Around
[javac] location: package annotation
[javac] import org.codehaus.aspectwerkz.annotation.Around;
When CVS version will be compillable or RC2 binary available for testing?
Try with ant clean dist
Yawn... JBoss has had this for years.
As a matter of fact, they wrote the code that is now in the AW CVS. The letter is on it's way. Also please come to JBossWorld to learn about professionanist open source. We now control over 70% of the Fortune 500 companies. In 2005 we'll buy BEA. By 2006 the unified class loader will have hit a store near you batteries not included. In 2008 we plan to reduce to one third the log messages volume.
Set the controls for the heart of the sun.
Yawn... JBoss has had this for years.As a matter of fact, they wrote the code that is now in the AW CVS. The letter is on it's way. Also please come to JBossWorld to learn about professionanist open source. We now control over 70% of the Fortune 500 companies. In 2005 we'll buy BEA. By 2006 the unified class loader will have hit a store near you batteries not included. In 2008 we plan to reduce to one third the log messages volume.Set the controls for the heart of the sun.
All your AOP are belong to us.
I like AWProxy idea but at this moment AWProxy is 3 times less performant than the same AW advice applied 'as usual' and 6 times slower than CGLIBhttp://kgionline.com/articles/aop_1/aop_perf.jsp#results
I also recomment AW team to adopt 'Always Compillable CVS' policy because it is unfair to announce a feature and provide no binaries (RC2 chocks at runtime),and no compillable CVS (I had to delete src/test/test/AllTests.java to be able to build HEAD).