"You are damn right, JBoss AOP is working only for JBoss and the standalone pack is only good at hello world example.
It should have been stated clearer by JBoss team: demo purpose only. I see no mention of future plan explaining JBoss standalone AOP roadmap, and I don't think JBoss has an advantage to maintain such a thing except for educational purpose.
Read a complete study on the JBoss standalone AOP on my stuff - sorry for the add. I just want the thing to be clearer: JBoss AOP standalone is only for demo purpose.
Firstly, thank you Alex for your detailed tests and analysis. You found some bugs (the stupid Javassist stack trace) thanks.
Now, let's start addressing the issues you had.
1. JBoss AOP was originally implemented to support the middleware aspects for JBoss 4. I have not done enough testing and playing yet in the standalone space as you can already see. Apologies....We DO PLAN to have a usable standalone version.
2. The stack trace is easily fixable.
3. The reason that certain classloader scenarios don't work is that JBoss AOP must control the classloader, even if it is a child classloader. What I should do really is document how to do this. Apologies again. So much for release early, release often, but the feedback has been really good so far.
4. The reason why AspectWerks does not have to have control over the ClassLoader is that it uses JMangler. JMangler uses the Java Debugger Interface, AFAICT, to provide hooks into loadtime class transformations for any class hierarchy. From what I have determined, they replace the default implementation of java.lang.ClassLoader using JDI interfaces for hot-swapping classes at runtime. So basically AspectWerks runs your java applications in the Debug mode of the JVM. Not sure what kind of affect this has on the system. But I plan on doing some performance measurements against AspectWerks and AspectJ to see. Somebody measured DR1 against AspectJ and the performance numbers were surprisingly similar. I'll do AspectWerks too.