[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Multiple ClassFileTransformers/Translators

[adrian@jboss.org]

"alesj" wrote : WRT: https://jira.jboss.org/jira/browse/JBSPRING-1
  | 

"It does not work" is not a bug report. What's wrong with it?

If you want to send me private e-mails asking me to look at stuff,
at least give me something to look at. :-)

Either way, I'll usually just ignore this kind of "twaddle" until the author puts some work into the question to make it answerable.

anonymous wrote : 
  | I've created custom JBoss5 LTW: http://anonsvn.jboss.org/repos/jbossas/projects/spring-int/trunk/weaving/src/main/java/org/jboss/instrument/classloading/JBoss5ClassLoader.java
  | 
  | But my actual question is really:
  | * why do we use custom Translator instead of ClassFileTransformer
  | ** perhaps the usage of Translator::unregisterClassLoader
  | 

You should use an agent.

The Transformer is only there for backwards compatibility with AOP from before the agent api was available.

Something that is almost certainly no longer relevant except for some old tests in the testsuite.

The only difference between the Transformer and the ClassFileTransformer
is that one is inside ClassLoader.defineClass() - i.e. all classloaders
while the other is only invoked from our ClassLoader.


  | 
  |             // Load the bytecode
  |             byte[] byteCode = ClassLoaderUtils.loadByteCode(name, is);
  |             
  |             // Let the policy do things before we define the class
  |             BaseClassLoaderPolicy basePolicy = policy;
  |             ProtectionDomain protectionDomain = basePolicy.getProtectionDomain(name, resourcePath);
  |             try
  |             {
  | 
  | TRANSFORMER HERE
  | 
  |                byte[] transformed = policy.transform(name, byteCode, protectionDomain);
  |                if (transformed != null)
  |                   byteCode = transformed;
  |             }
  |             catch (Throwable t)
  |             {
  |                throw new RuntimeException("Unexpected error transforming class " + name, t);
  |             }
  |             
  |             // Create the package if necessary
  |             URL codeSourceURL = null;
  |             if (protectionDomain != null)
  |             {
  |                CodeSource codeSource = protectionDomain.getCodeSource();
  |                if (codeSource != null)
  |                   codeSourceURL = codeSource.getLocation();
  |             }
  |             definePackage(name, codeSourceURL);
  |             
  |             // Finally we can define the class
  |             Class<?> result;
  | 
  | AGENT INSTRUMENTATION HERE
  | 
  |             if (protectionDomain != null)
  |                result = defineClass(name, byteCode, 0, byteCode.length, protectionDomain);
  |             else
  |                result = defineClass(name, byteCode, 0, byteCode.length);
  | 

anonymous wrote : 
  | * why do we have just one translator and not a list of them
  | * why Translator per ClassLoaderSystem and not (also) per BaseClassLoaderPolicy
  | 
  | Afaics the SpringLTW example will set the transformer to the whole ClassLoaderSystem,
  | where it would actually only make sense to have it on apps CL policy.
  | 

If you want to add classloader specific ClassFileTransformers to the 
BaseClassLoaderPolicy api that's ok with me.

I think a better integration point would be to have a Spring aop deployer like
our aop deployer to analyse (and in your case modify) the classloader
based on metadata?

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

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