Default ordering of AbstractTopLevelClassLoaderDeployer vs A

[starksm64]

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.

[adrian.brock]

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?

[starksm64]

Yes, its the unit ClassLoaderFactory that is the issue.