I'm trying to figure out how the old configuration worked in terms of precedence
of all the different flags for parent first or scoped classloading.
It complicated by having two flags for java2ClassLoadingCompliance in jboss-web.xml
one on the class-loading element and another on the loader repository.
We still aren't doing it properly for the legacy configurations.
As far as I can tell, the attribute on the class-loading element controls behaviour
at the tomcat classloader level in 4.2.x, but the flag on the loader repository config
controls the entire hierarchical loader repository.
The final value will be overridden by each depending on what you are trying to achieve.
So I think the rules are supposed to be (below true means delegate to parent first).
a) class-loading attribute = true + no loader repository config => true
b) class-loading attribute = false + no loader repository config => false
c) class-loading attribute = true + loader repository config = true => true
d) class-loading attribute = false + loader repository config = true => false
e) class-loading attribute = true + loader repository config = false => true (1)
f) class-loading attribute = false + loader repository config = false => false
NOTE (1) is for the edge case where some other classloader is in the web-app's
loader repository. Since the loader repository has a scoped definition,
classes in that other classloader would be prefered before the default classloading
domain.
I think we doing everything correct, except case (d).
i.e. the loader repository config saying delegate to the parent first is overridding
the class-loading attribute saying do scoped classloading.
This is because JBossWebAppParsingDeployer is not looking at the
class-loading attribute when setting up the LoaderRepositoryConfig.
But this code needs moving the WarClassLoaderDeployer anyway
with it constructing the new ClassLoadingMetaData directly.
