Re: Cross ClassLoader instrumentation issue

On Wed, Nov 10, 2010 at 3:52 PM, Nemo Caviani <[email protected]> wrote:
> Hi all,
> I have a rather complicated problem that I am trying to deal with.
> I am doing binary rewriting within the context of Spring DM and the issue
> that I am dealing with is that several instances of an overwritten
> ClassLoader load different classes in the application. So, when I am doing
> binary rewriting some classes are not available for the class loader whose
> class byte code is being rewritten. This corrupts the overwritten bytecode
> for the instrumented class and when I check it with the CheckClassAdapter
> verifier, I receive exceptions similar to the following:
> org.objectweb.asm.tree.analysis.AnalyzerException: Error at instruction 392:
> java.lang.ClassNotFoundException: org.hibernate.HibernateException
> when checking the Class loader IDs for which the classes are being loaded, I
> see the following
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader 8993129 ::
> Auth.class
> org.apache.felix.framework.ModuleImpl$ModuleClassLoader 16865950
> :: org.hibernate.HibernateException
> "Auth.class" is loaded via a ModuleClassLoader instance whose hashcode
> is 8993129 whereas the instance loading
> "org.hibernate.HibernateException.class" has the hashcode 16865950
> (Basically 2 different instances)
> I wonder if there is any way to get the ClassAdapter to do late binding when
> resolving dependencies? or if not, could anyone think of any solution?

IMO, I can't see anything wrong in class loader.  It is common that
different class loaders load its own classes for some purpose, such as
security.  Please have a check that Auth and HibernateException are
loaded by different class loaders *without* your instrumentation.  If
yes, I don't think you did something wrong here.
The problem becomes "why CheckClassAdapter tries to access or resolve
HibernateException?"  They are loaded by different class loader, so it
is not surprise to get such error.
My experience on ASM is that all classes are treated as a stream of
byte code, and ASM modify this stream to achieve instrumentation,
regardless this class is loaded by which class loader.  ASM itself
should not trigger the class resolution/loading.  You can chain a
simple adapter rather than CheckClassAdapter, to see the error still
exists.  If error goes away, that means CheckClassAdapter triggered
class resolution, and then you can consider to write your own adapter.
 If error is still there, I have no idea how to fix it so far.

> One possibility that I have been thinking about is to exhaustively find all
> the classes  in the byte code of the class being overwritten and create some
> proxies or interfaces for them to resolve the dependencies but this is
> insanely expensive and fairly complicated. I very much appreciate inputs
> from you guys.
> thanks a lot,
> Nemo
>
> --
> You receive this message as a subscriber of the [email protected] mailing list.
> To unsubscribe: mailto:[email protected]
> For general help: mailto:[email protected]?subject=help
> OW2 mailing lists service home page: http://www.ow2.org/wws
>
>



-- 
Yao Qi <qiyaoltc AT gmail DOT com>
http://sites.google.com/site/duewayqi/

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws