2 Replies Latest reply on Jun 16, 2008 6:16 AM by Adrian Brock

    JBAS-5268 - Mapping legacy web classloading rules

    Adrian Brock Master

      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.

        • 1. Re: JBAS-5268 - Mapping legacy web classloading rules
          Scott Stark Master

           

          "adrian@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@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.