JBossDeveloper

The proxy CL approach is just creating a new simple classloader (could just be a URLClassLoader for example) for every source class' classloader (that is of course reused for other classes in the same classloader as the source class). These proxy classloaders would be associated with the lifespan of AOP, and anything using the proxies. So, for example, if AOP is undeployed, all generated proxies can and should be collected. If you start generating classes in a system classloader (or in the case of juliens recommendation the ext class loader), then these proxies will only go away when the JVM restarts.

I was doing a similar thing a few years ago (generating proxies that needed to be associated with a (possible) isolated deployment. I ran into an issue with the old jboss repository class loader, and its use of black lists. For awhile I detected them and flushed the bls using its api. I also later on had a problem with another thirdparty CL (can't remember which lib did this) that also ignored classes generated from defineClass. The solution I ended up using was the approach I describe above (although I did not use/need a registry since I generated classes only once, and at the start of a deployment).

I found the forum post where I discussed the issue with Scott, and he had mentioned that the end-goal was for aop to use a special repository for generated classes. To be honest, I haven't reviewed the new JBoss Classloader architecture yet, so not sure where things are right now:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986381

Unfortunately using the classloader of the class is not always an option. The proxies rely on some interfaces from aop, which can not be found on bootstrap classloader level.

Brian,

Can you try the snapshot I have attached to http://jira.jboss.com/jira/browse/JBAOP-572