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
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4147976#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...