(I posted a the same question on WowzaMedia forums, so I'll just copy the most of it)
I'm having problems using @AspectJ Spring annotations inside a Java Flash Media server called Wowza.
This is a rather weird problem, so I'll be long in the explanation to make sure you get me right.
When I launch the application as a standalone java app, I can see this in the logs:
As you can see, the classloader in use by AspectJ's weaver is AppClassLoader. If I create something in my program with new operator, the ClassLoader is also AppClassLoader. Same classloader means that the objects are advised (as expected) and therefore I'm happy.
[AppClassLoader@130c19b] info AspectJ Weaver Version 1.6.2 built on Saturday Oct 4, 2008 at 05:47:07 GMT
[AppClassLoader@130c19b] info register classloader sun.misc.Launcher$AppClassLoader@130c19b
Now here's where everything goes south:
This is the same output as above, but running the application from within Wowza. By "running from within Wowza" I mean that I start the server by calling its bootstrap and my code is called due to a custom-made module that I configured there. Think servlets here; I configure a context, make a couple of classes and configure some files, the app-server launches, fires up my context and off my code goes happily executing.
[URLClassLoader@10385c1] info AspectJ Weaver Version 1.6.2 built on Saturday Oct 4, 2008 at 05:47:07 GMT
[URLClassLoader@10385c1] info register classloader java.net.URLClassLoader@10385c1
Now this classloader thing wouldn't be much of a big deal, if it wasn't for the fact that everything I create using new still comes from AppClassLoader and not from URLClassLoader.
Since LTW can only be applied on classes from the same ClassLoader, you can see where this is headed - absolutely no @AspectJ AOP whatsoever.
Playing around with the code, I found out I can still use AOP if I restrict myself to using Spring's AOP (applied only to Spring managed objects) but this doesn't fit my purposes as I have lots of background stuff that Spring doesn't control and I need to apply AOP to those objects as well. Interesting fact is that Spring's unadvised beans come from AppClassLoader, while Spring's advised beans come from URLClassLoader.
Here's an example:
And the results, standalone and within Wowza (in that order):
StuffInterface advisedBean = (StuffInterface) context.getBean("bean");
OtherStuff unadvisedBean = (OtherStuff) context.getBean("unadvisedBean");
> Standalone mode
Now, I have no idea where is the root of this problem. I've searched Spring's source code and URLClassLoader is nowhere to be found. I doubt this is Wowza's problem either, but the weird thing is that it only happens inside Wowza - which I now know for a fact has its own classloader, but like I said before, objects created using new still come from AppClassLoader, only woven stuff comes from URLClassLoader.
> Within Wowza
Any hints on this? I'm about to try a different approach: launching the application server from within my code instead of expecting my code to be launched by the app server. But that feels so ass-backwards... :\