6 Replies Latest reply on Feb 9, 2004 3:10 PM by bill.burke

    Classloader Domain scoping

    bill.burke

      Was thinking about how to scope advice bindings. Currently if you have two versions of the same class loaded by different classloaders, JBoss AOP will apply the same advice bindings to both of those different versions. It would be extremely useful to be able to scope how advice bindings are resolved on a per component/classloader basis.

      My thinking is a new interface

      public interface ClassLoaderDomain
      {
       public String getDomainName();
      }
      


      Customer ClassLoaders would implement this interface so that jboss-aop.xml could reference them from with XML.

      [aop domain="SomeClassLoaderIdentifier"]
       ... bindings...
      [/aop]
      

      Then you could scope advice bindings per ClassLoader. YOu need the interface because there is no way of identifying a ClassLoader outside of the VM. Inside you can only identify via an address comparison.

      For running within JBoss, the domain would pertain to a LoaderRepository ObjectName and a UnifiedClassLoader would implement the ClassLoaderDomain interface.

      Actually, come to think of it, you would need the ability to define multiple domains:

      [aop domains="MyEarsClassLoader,SystemClassLoader"]
      [/aop]
      


      Bill

        • 1. Re: Classloader Domain scoping
          starksm64

          The ClassLoaderDomain cannot be a contract required at the ClassLoader imiplementation level as this is too restrictive on the ClassLoader choice. This should be a contract coming in at the LoaderRepository, and could be supported by adding the class loader domain as a property in the JMX object name of the LoaderRepository. A domain is also likely to have multiple ClassLoaders associated with it.

          • 2. Re: Classloader Domain scoping
            rythos

            So for some versions of the class being loaded the advice applies, and for others it doesn't? I don't have much "real world" experience, can you give an example where such a thing would be useful?

            • 3. Re: Classloader Domain scoping
              bill.burke

               


              he ClassLoaderDomain cannot be a contract required at the ClassLoader imiplementation level as this is too restrictive on the ClassLoader choice. This should be a contract coming in at the LoaderRepository, and could be supported by adding the class loader domain as a property in the JMX object name of the LoaderRepository. A domain is also likely to have multiple ClassLoaders associated with it.


              I don't think I stated clearly what I was saying.

              ClassLoaderDomain.getDomainName() would return a string representation of the LoadRepository the CLassLoader belonged too. So in AOP XML you would reference the LoadRepository's ObjectName, not some arbitrary ClassLoaderDomain name. Do you think it is ok to require ClassLoaders to implement this interface now?

              If not, then here's another reason. In JBoss AOP, advice bindings are triggered when a static variable within the Class is initialized:
              POJO {
              static ClassAdvisor advisor = AspectManager().instance().getAdvisor(POJO.class);
              }

              The lookup of the advisor triggers advice bindings. I would need some way of going from Class to ClassLoader to the Domain the ClassLoader belongs to. I also need this mechanism to work inside and outside of JBoss.

              Bill

              • 4. Re: Classloader Domain scoping
                bill.burke

                 

                "rythos" wrote:
                So for some versions of the class being loaded the advice applies, and for others it doesn't? I don't have much "real world" experience, can you give an example where such a thing would be useful?


                Sure, happens often in J2EE applications. You either have multiple applications being deployed to the same application server, or you have different separate groups (one offshore, one local) developing different components of a large application. They may use different versions of thirdparty libraries (i.e. xerces, Axis, Xalan etc....) J2EE application servers support having multiple versions of the same class as they define specfic classloader hierarchies.

                Bill

                • 5. Re: Classloader Domain scoping
                  starksm64

                  Its too big a requirement to need the ClassLoader to implement a proprietrary interface. Simply have something like this:

                  public interface ClassLoaderDomainMgr
                  {
                   public ClassLoaderDomainMgr getClassLoaderDomainMgr();
                   public String getDomainName(Class c);
                   public String getDomainName(ClassLoader cl);
                  }
                  



                  • 6. Re: Classloader Domain scoping
                    bill.burke

                    Yeah, you're right Scott on the simpler interface. Sorry.... And thanks.

                    Bill