1 Reply Latest reply on Jul 8, 2013 5:25 AM by Andrew Dinn

    Support for multiple class loaders

    Sergio Bossa Newbie

      Hi,

       

      I'm using Byteman on an application built with multiple class loaders: everything works fine, except custom helpers: this is because they are loaded using the target class loader, a custom one in my case, while their parent class is loaded by the original app class loader (the same that loads all other byteman classes).

       

      I think all Byteman classes should be loaded by the same class loader in the end, even custom helpers, so I'm attaching a patch to the Compiler class to change this behavior.

       

      Feedback is welcome.

      Cheers,

       

      Sergio B.

        • 1. Re: Support for multiple class loaders
          Andrew Dinn Master

          Hi Sergio,

          Sergio Bossa wrote:

           

          I think all Byteman classes should be loaded by the same class loader in the end, even custom helpers, so I'm attaching a patch to the Compiler class to change this behavior.

           

          Hmm, nIce try, but that is not going to work:

           

          Let's assume your rule is injected into class C loaded by application loader L. Now, the rule's classloader will be either the system loader S or, if you have placed the Byteman jar in the bootstrap path, the boot loader B. Imagine your rule refers to local variable $myLocal of type C1 also defined in L. The type checker tries to type check $myLocal by looking up a type with name C1. It can only try to resolve this class via either S or B. But C1 only exists in L so the lookup will fail.

           

          Sp, all your patch will do is exchange one type of class loader hell for another.

           

          There is a workable solution to this problem which I have thought about but not had time to implement. It involves using a dedicated class loader for the rule which loads its class base via i) the trigger method classloader (ensuring any classes mentioned in the trigger context are in scope) and ii) any other loaders you wish to import into the type check context (for example, ensuring that your helper classes or container classes such as Transaction are in scope). Imports would need to be explicitly included either in the body of your rule or preceding a set of rules in the enclosing rule script.

           

          This solution will require quite a lot of changes to Byteman, most obviously supporting the IMPORT syntax in rules/scripts. I believe it can be made to work with both normal JVM loaders and with module systems like OSGi annd JBoss Modules and (coming to the JVM very soon) Jigsaw loaders. Makign itwork with module systems latter will almost certainly require loading a module-specific plug-in when the agent is started. The plug-in wil lbe delegated to in order to handle IMPORT requests and come up with the rleevant loader to use during type checking.

           

          I am sure this is going to require quite a lot of work. I am hoping that I can get a student (probably masters level) to take this on as a final year project. Of course, if you are interested and can afford to spend a few months workign on this I would be happy to talk through what would be needed for a complete solution.

           

          regards,

           

           

          Andrew Dinn