Historically, the ScopedClassPool is there to extract out the known behaviour at the time (early 2006 IIRC) of how the UnifiedClassLoaders (AS 4) worked. It used to all live in AOPClassPool, but since JBoss Retro also needed to do loadtime weaving stuff the common code was moved to ScopedClassPool. 1) The comment means that we should use the classloader associated with the pool rather than the default thread context classloader that would get passed in when somebody calls ClassPool.toClass(). 2) get0() is an internal implementation detail in the pools, so getLocally() is there to expose the functionality. Also, it ensures that we just search the pool itself, since at weaving time we know the exact classloader (passed in by the agent). 3) If I do a search for who is calling ClassPool.get() I get loads of callers, so we are using that in AOP. Also, when you load up a CtClass, get a CtField or a CtMethod parameter type I think javassist will call get() internally to obtain that. So as mentioned in 2 when weaving a class we use the pool for the classloader used to load the CtClass since we know it must come from there, but later in the weaving process we end up in get0() when fetching in the superclass, fields, methods, parameters etc. 4) Probably just to get the extra logging. javassist ScopedClassPool could be fixed I guess, but it does not use log4j so there is not really any way to add logging there. 6) I don't think it is a memory leak, since the CtClasses need to be cached, and in AS we create/drop the pools when the classloaders are deployed/undeployed. It might be redundant as you say though. 5&7) I agree with you here, but a bunch of stuff in the API is using the ScopedClassPool(Factory/Repository) stuff. I was in two minds at the time whether to get rid of it, but was worried about breaking backwards compatibility. But yes, for the new delegating classpools a lot of the stuff (the searching across classpools) in ScopedClassPool is redundant. However, the repository is still used when registering and unregistering classloaders. Also, in AS 4 we do not use the new delegating classpools, but the old ones returned by org.jboss.aop.asintegration.jboss4.JBossClassPoolFactory and org.jboss.aop.asintegration.jboss5.JBoss5ClassPoolFactory. 8) ClassPool.get() is being used, see 2& 3. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4239057#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...