[jboss-dev-forums] [Design of JBoss/Tomcat Integration] - Re: JBAS-5268 - Mapping legacy web classloading rules

[scott.stark@jboss.org]

"adrian at jboss.org" wrote : 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.
  | 
That is correct.

"adrian at jboss.org" wrote : 
  | 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.
Yes, I agree with this.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4157986#4157986

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4157986