2 Replies Latest reply on Jan 24, 2008 8:14 PM by Scott Stark

    Default ordering of AbstractTopLevelClassLoaderDeployer vs A

    Scott Stark Master

      I had to specify the ordering of the WarClassLoaderDeployer to come ahead of the VFSTopLevelClassLoaderSystemDeployer in order for it to have a chance to set the unit class loader. Maybe there should only be one class loader deployer driven by the metadata and class loader factory. We are not generating ClassLoaderMetaData currently as noted elsewhere.

        • 1. Re: Default ordering of AbstractTopLevelClassLoaderDeployer
          Adrian Brock Master

          I don't understand what problem you are trying to solve?

          Are you talking about the bit that overrides the ClassLoaderFactory
          or something else?

          In practice, we should be able to use the new ClassLoader for web-apps.

          What's missing is a generic way to say that a subdeployment (e.g. a war in an ear)
          wants its own classloader (based on the top level classloader)
          so the classes in its "classpath" are not visible to other parts of the deployment.

          This should be a choice in the StructureMetaData that is used
          to build the DeploymentContext.

          We can then have a "SubDeploymentClassloaderDeployer" that overrides
          the specific unit classloader with the classloader described above.

          I imagine this is related to what Ales is seeing with Seam, in that the
          the classpath of the war is being built into both the top level and WAR classloader?

          • 2. Re: Default ordering of AbstractTopLevelClassLoaderDeployer
            Scott Stark Master

            Yes, its the unit ClassLoaderFactory that is the issue.