4 Replies Latest reply on Jan 30, 2008 10:53 AM by Adrian Brock

    Domain interaction when there is scoping

    Scott Stark Master

      The last problem I'm seeing with pulling the war deployer class loader creation into the WarClassLoaderDeployer is a failure for a war in a scoped sar to see classes from the sar. The sar has a separate ClassLoaderDomain resulting from a scoped sar LoaderRepositoryConfig being mapped by the HackClassloaderMetaDataDeployer. I'm not seeing any interaction between the sar ClassLoaderDomain and the default ClassLoaderDomain that the war class loader is associated with.

      I guess the war class loader needs to be using the same ClassLoaderDomain as the sar. The problem is, its not available in the DeploymentUnit. Only the ClassLoader and ClassloaderMetaData is. Although the domain name is in the ClassloaderMetaData, I don't have access to the ClassLoaderSystem to lookup the domain without setting it. I do happen to have access to this because the WarClassLoaderDeployer needs it for other reasons, but we need to make it easier for subdeployments to build class loader in the correct domain.

        • 1. Re: Domain interaction when there is scoping
          Adrian Brock Master

           

          "scott.stark@jboss.org" wrote:

          but we need to make it easier for subdeployments to build class loader in the correct domain.


          That's what I said above. Instead of trying to hack something for the war classloader
          use case, let's try to do this generically in the structure metadata
          such that any subdeployment can say its classpath isn't to be added to the
          root classloader of the deployment, instead a new
          subdeployment classloader is built "on top of" the deployment classloader.

          This is going to have to be modelled in the "Classloading" anyway since
          you can image the case where you have two wars that
          explictly import different versions of log4j for example in the same ear.
          i.e. the log4j classes don't come from the WEB-INF/lib they are imported from
          a repository based on version constraints.

          • 2. Re: Domain interaction when there is scoping
            Scott Stark Master

            So is this something you will do? I was not expecting this for beta4.

            • 3. Re: Domain interaction when there is scoping
              Scott Stark Master

              For now I have updated the HackClassloaderMetaDataDeployer to create a ClassLoaderMetaData for child deployments with the domain copied from the top-level ClassLoaderMetaData.

              • 4. Re: Domain interaction when there is scoping
                Adrian Brock Master

                 

                "scott.stark@jboss.org" wrote:
                So is this something you will do? I was not expecting this for beta4.


                No it won't be in beta4. Its needs an OSGi style repository first. :-)

                The deployments that are pulled from the repository and use real imports
                will need to go into a seperate domain (the domain isn't really used
                except to determine the parent classloading context - importAll = false)
                otherwise they will be picked up by the importAll processing for other deployments.

                e.g. in the example above, you don't want two different versions of log4j
                in the DEFAULT_DOMAIN.