"kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : | | You haven't answered why it is defined against the user classloader? | | See my point about classloader leaks. | | | | It is defined against the user classloader since as far as I can tell: | -We cannot use the system classloader. The proxies use interfaces from the aop classloader (org.jboss.aop.proxy.container.AspectManaged and org.jboss.aop.proxy.container.Delegate) which are not visible from the system classloader. | -We cannot use the aop classloader. The proxies might have interfaces introduced by the deployment, whose classloader might be in a child domain of the aop classloader's domain. Those interfaces would not be visible from the aop classloader. | | At the moment we are caching the generated proxies by deployment classloader. The classloader is the key into a WeakHashMap. If deploymentA wants to create a proxy for ArrayList with no interface introductions, we generate the proxy class using deploymentA's classloader. If deploymentB wants to create a similar proxy for ArrayList, we generate the proxy class using deploymentB's classloader. Subsequent attempts to get a plain ArrayList proxy from deploymentA's classloader will use deploymentA's cached class, and deploymentB will use deploymentB's cached class. | I guess I'm not understanding what you are doing. But what you described above doesn't match what you originally said. Above you have deploymentB using the proxy class from its classloader but earlier you want it to see deploymentA's class? If the proxy uses a deployment class then obviously it should be generated against that deployments classloader. Other deployments then become dependent upon that deployment and must be redeployed. I don't see why the class can use the deployment class's package in that case? But that doesn't sound like your original requirement which was to do "instrumenting JDK classes" by creating classes in the base package. anonymous wrote : | Doesn't your point about classloader leaks hold for any deployment? | Yes, that's why you need to be careful with it. e.g. ejb3 had a big memory leak while we were developing JBoss5 because it was defining remote/local proxies against the wrong classloader. If its as you say that deploymentB is using a class from deploymentA and that is explicit then it is possible to know the dependency and redeploy. Any other semantic will break the modularity and/or cause memory leaks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206545#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...