6 Replies Latest reply on Jan 28, 2008 8:11 AM by Adrian Brock

    Class loading debugging

    Scott Stark Master

      I'd like to get a better view of what has visibility to a class from the system/domain level. What I would like is:

      1. Be able to ask a policy, what policies have a resource/class
      2. Be able to ask the BaseClassLoaderSystem what domains have a resource/class
      3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.

        • 1. Re: Class loading debugging
          Adrian Brock Master

           

          "scott.stark@jboss.org" wrote:
          I'd like to get a better view of what has visibility to a class from the system/domain level. What I would like is:

          1. Be able to ask a policy, what policies have a resource/class


          You mean locally. That's two different questions depending on whether
          it exports those resources/classes.
          I also assume you mean a domain or the classloading system?

          There's a different question as to whether it can see it from one of its imports
          or the domain if it is importAll. But that's just the standard classloading api.


          2. Be able to ask the BaseClassLoaderSystem what domains have a resource/class


          That pretty much already exists, but it will only be exported classes and resources.
          The only part that is missing is the ability to list the domains so you can iterate over
          them and do loadClass/getResource.


          3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.


          There's no such thing in general. If the policy is a VFSClassLoaderPolicy
          then you can ask what its VFS roots are and you could ask what other policies
          it can see that are VFSClassLoaderPolicys or URLClassLoaders.
          But the new classloading system has been designed to be flexible.
          There's no direct dependency of URLs/VFS etc. Somebody can implement
          a policy how they want.

          • 2. Re: Class loading debugging
            Adrian Brock Master

            The one issue is that this is a management api.

            So we need a way to identify the policy. Currently each policy has a "name"
            but that's just for debugging purposes. In the deployment layer we
            use the top level deployment name.

            The domains do have a unique name.

            Assuming the name is enough, I can see it being fairly trivial to implement
            a management api like the following on the ClassLoaderSystem:

            Assume similar api for getResources()

            // Basic lists
            Collection<ClassLoaderDomain> listDomains();
            Collection<ClassLoaderPolicy> listPolicies();
            Collection<ClassLoaderPolicy> listPolicies(String domainName);
            
            // Your point 2 - class exported in a domain
            Class showClass(String domainName, String className);
            ClassLoaderPolicy findClassPolicy(String domainName, String className);
            
            // Your point 1 - class exported by a policy
            Class showExportedClass(String policyName, String className);
            // Class maybe private (not exported)
            Class showLocalClass(String policyName, String className);
            // Class located using normal rules
            Class findVisibleClass(String policyName, String className);
            ClassLoaderPolicy findVisibleClassPolicy(String policyName, String className);
            


            One issue with the showLocalClass and showExportedClass
            is that the policy may not actually use it, if it is in one of its imports
            the imports hide the class (like the uses constraint in OSGi).

            I also imagine we can show things like some package queries as well.
            Like listing who exports what package and what they are searched for
            exportAll.

            • 3. Re: Class loading debugging
              Scott Stark Master

               

              "adrian@jboss.org" wrote:

              You mean locally. That's two different questions depending on whether
              it exports those resources/classes.
              I also assume you mean a domain or the classloading system?

              There's a different question as to whether it can see it from one of its imports
              or the domain if it is importAll. But that's just the standard classloading api.

              It looks like ClassLoading is best point.

              "scott.stark@jboss.org" wrote:

              3. What are the classpath elements that are visible starting from a ClassLoader. Sort of a URLClassLoader.toURLs() view.


              "adrian@jboss.org" wrote:

              There's no such thing in general. If the policy is a VFSClassLoaderPolicy
              then you can ask what its VFS roots are and you could ask what other policies
              it can see that are VFSClassLoaderPolicys or URLClassLoaders.
              But the new classloading system has been designed to be flexible.
              There's no direct dependency of URLs/VFS etc. Somebody can implement
              a policy how they want.

              It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible.


              • 4. Re: Class loading debugging
                Scott Stark Master

                Another thing I would like to get is a directed graph of the domains/policies for a package. An example question to be able to answer is what applications are using what versions of an xml parser implementation.

                • 5. Re: Class loading debugging
                  Adrian Brock Master

                   

                  "scott.stark@jboss.org" wrote:
                  Another thing I would like to get is a directed graph of the domains/policies for a package. An example question to be able to answer is what applications are using what versions of an xml parser implementation.


                  That information is already availble on the deployment if you are using
                  explicit imorts, but it's an implementation detail.
                  deployment unit -> deployment controller context - > dependeny info -> getDependsOnMe

                  For the deployments that don't use explicit imports (i.e. importAll) you'd need
                  to work out if that classloader is the first providing that package in each domain
                  and assume that all classloaders using "importAll" in that domain are "using" the
                  xml parser.

                  • 6. Re: Class loading debugging
                    Adrian Brock Master

                     

                    "scott.stark@jboss.org" wrote:

                    "adrian@jboss.org" wrote:

                    There's no such thing in general. If the policy is a VFSClassLoaderPolicy
                    then you can ask what its VFS roots are and you could ask what other policies
                    it can see that are VFSClassLoaderPolicys or URLClassLoaders.
                    But the new classloading system has been designed to be flexible.
                    There's no direct dependency of URLs/VFS etc. Somebody can implement
                    a policy how they want.

                    It should not explicitly be URL[], just String[]. In general there needs to be some notion of a classpath. It might be an sql query, who knows, but some generic view should be possible.


                    We can ask each ClassLoaderPolicy to implement a getURLs() for management
                    purposes. For deployment generated classloaders its really just the same as
                    getClassPath() on the deployment unit. But that doesn't mean that something
                    should use those URLs as a classpath.

                    Parts of the filesystem the url represents could be filtered out
                    e.g.
                    1) your excluded packages example
                    2) the OSGi uses constraint where a deployment may contain jms.jar
                    but declare it as "uses". i.e. it will actually use our jms classes
                    3) for importAll, a previously deployed classloader may mask some classes
                    if they appear in two classloaders (only the first gets used)
                    etc.