EAR CL isolation is broken

[alesj]

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

[starksm64]

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.

[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.