2 Replies Latest reply on Mar 16, 2009 8:33 AM by Ales Justin

    EAR CL isolation is broken

    Ales Justin Master

      WRT
      - https://jira.jboss.org/jira/browse/JBAS-6600
      current impl of EarClassLoaderDeployer looks pretty much broken.

      From 5_0 branch

       public void deploy(DeploymentUnit unit, JBossAppMetaData metaData) throws DeploymentException
       {
       ClassLoadingMetaData classLoadingMetaData = unit.getAttachment(ClassLoadingMetaData.class);
       if (classLoadingMetaData != null)
       return;
      
       LoaderRepositoryMetaData lrmd = metaData.getLoaderRepository();
       if (lrmd != null)
       {
       ClassLoadingMetaData clmd = LoaderRepositoryMetaDataHelper.create(unit, lrmd);
       // For isolated automatically create the classloader in a new domain
       if (clmd == null && isolated)
       {
       String domain = EARDeployment.getJMXName(metaData, unit) + ",extension=LoaderRepository";
       classLoadingMetaData = new ClassLoadingMetaData();
       classLoadingMetaData.setName(unit.getName());
       classLoadingMetaData.setDomain(domain);
       classLoadingMetaData.setExportAll(ExportAll.NON_EMPTY);
       classLoadingMetaData.setImportAll(true);
       classLoadingMetaData.setVersion(Version.DEFAULT_VERSION);
       classLoadingMetaData.setJ2seClassLoadingCompliance(false);
       }
       }
       }
      


      1) Why only do isolation if LRMD is present? (as Jaikiran noted)
      2) Even if isolation kicks in, it's never attached
      3) LoaderRepositoryMetaDataHelper and LoaderRepositoryConfigHelper have duplicated code

        • 1. Re: EAR CL isolation is broken
          Scott Stark Master

          I'd guess we just have not updated the locations where the old UCL LoaderRepositoryMetaData is used. I think we were producing this for each deployment before the update to the new peer class loading model. The LoaderRepositoryMetaData should just be dropped at this point and the old descriptors mapped onto the ClassLoadingMetaData.

          • 2. Re: EAR CL isolation is broken
            Ales Justin Master

            This is the fix:

             public void deploy(DeploymentUnit unit, JBossAppMetaData metaData) throws DeploymentException
             {
             ClassLoadingMetaData classLoadingMetaData = unit.getAttachment(ClassLoadingMetaData.class);
             if (classLoadingMetaData != null)
             return;
            
             LoaderRepositoryMetaData lrmd = metaData.getLoaderRepository();
             if (lrmd != null && LoaderRepositoryMetaDataHelper.create(unit, lrmd) != null)
             return;
            
             // For isolated automatically create the classloader in a new domain
             if (isolated)
             {
             String domain = EARDeployment.getJMXName(metaData, unit) + ",extension=LoaderRepository";
             classLoadingMetaData = new ClassLoadingMetaData();
             classLoadingMetaData.setName(unit.getName());
             classLoadingMetaData.setDomain(domain);
             classLoadingMetaData.setExportAll(ExportAll.NON_EMPTY);
             classLoadingMetaData.setImportAll(true);
             classLoadingMetaData.setVersion(Version.DEFAULT_VERSION);
             classLoadingMetaData.setJ2seClassLoadingCompliance(false);
             unit.addAttachment(ClassLoadingMetaData.class, classLoadingMetaData);
             }
             }
            


            btw, Adrian, what happened to Hack(Something)Deployer,
            that was responsible to transform the old -service.xml cl metadata to new CLMD?

            Do we really need to map the old descriptors to CLMD?
            I guess we can leave this via programmatic approach, as it is now.