I think we have crossed wires :-)
"adrian(a)jboss.org" wrote : "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.
| | |
| | |
| |
| | 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?
| |
|
I'm not really sure what you mean here, but I'll try to answer what I think
you're asking :-)
We don't create a proxy class every time we go to the proxy factory. There is a cache
of generated classes which is used behind the scenes. When we want to CREATE a proxy class
we ask the factory for it. The first time it generates it using the deployment's
classloader and caches it. Subsequent attempts to CREATE the same proxy for the same
classloader return the cached copy for that classloader. In another classloader if we want
to CREATE a proxy for the same class we end up with a new generated proxy cached for that
classloader.
When we want to USE a proxy from a different classloader, we need to be able to load the
proxy class. Proxies have unique names (static counter maintained by proxy factory across
all loaders). In the example I gave deploymentA's proxy for ArrayList will be
AOPProxy$1, and deploymentB's proxy for ArrayList will be AOPProxy$2 (both in the
default package)
"adrian(a)jboss.org" wrote :
|
| 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't use the deployment class's package in that
case?
|
It uses the proxied class's package if the classname does not start with
"java" or "sun". For example:
-a proxy for java.util.ArrayList is AOPProxy$1 (currently in default package)
-a proxy for org.jboss.some.Thing is org.jboss.some.AOPProxy$2
"adrian(a)jboss.org" wrote :
| But that doesn't sound like your original requirement which was to do
"instrumenting
| JDK classes" by creating classes in the base package.
Only JDK classes should not be in the package of the proxied class, and we need to find
another home for these. Deployment classes are causing no problem.
In short, we always use the classloader of the deployment rather than the classloader of
the class we are proxying. This happens whether it is a system class (ArrayList) or
something else. There might be interface introductions etc. that need to be able to see
classes from the deployment classloader, so that is the easiest way.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206617#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...