[jboss-dev-forums] [Design of AOP on JBoss (Aspects/JBoss)] - Re: ClassLoading Module usage

[adrian@jboss.org]

"kabir.khan at jboss.com" wrote : 
  | AFAICT we don't know this at the time the classloader is created? So basically we need to turn off blacklisting of all classloaders in jboss 5?

What stops you from knowing this?

In practice, for the "importAll" handling, any classloader that has no blacklist
means all subsequent classloaders can't have one either.
(Well actually they can have a local one, but no global one).

A better solution would be if we could "intercept" the defineClass()
and automatically flush the related blacklists. 
But unfortunately, the method is "final".

I'm not actually too adverse to this change (it isn't like it is a dangerous operation ;-), 
and we already have a mechanism
to bypass the classloading and access the cache on the RealClassLoader
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/trunk/jboss-classloading-spi/src/main/org/jboss/classloading/spi/RealClassLoader.java?revision=64506&view=markup
for the potential performance gain, so adding a flush{cache|blacklist} mechanism
to the RealClassLoader spi wouldn't be that big a change.

Why I don't like it, is that there can be a local blacklist and a global blacklist.
Turning off the blacklist after the classloader has been created and added to the
domain could leave the global one in an inconsistent state unless extra steps
are taken to flush it.

It seems to me that flushing the blacklists 
(whenever you define a class outside the normal classloading mechanism)
is better than turning it off altogether?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4096975#4096975

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4096975