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

    EAR CL isolation is broken

    alesj
    alesj Mar 12, 2009 5:55 AM

      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

      • 501 Views
      • Tags:
        • 1. Re: EAR CL isolation is broken
          starksm64
          starksm64 Mar 12, 2009 2:27 PM (in response to alesj)

          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.

            • Actions
          • 2. Re: EAR CL isolation is broken
            alesj
            alesj Mar 16, 2009 8:33 AM (in response to alesj)

            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.

              • Actions