Application Server 3  4  5 and 6
  1. Application Server 3 4 5 and 6
  2. JBAS-1691

Switch to UseJBossWebLoader=false as the default web container configuration

    Details

    • Affects:
      Compatibility/Configuration
    • Similar Issues:
      Show 9 results 

      Description

      The reason for the default setting of the jbossweb-tomcat55.sar/META-INF/jboss-service.xml UseJBossWebLoader attribute to true was to allow the use of aop in web envrionments. This is not a prevelent usecase, and with jdk5 instrumentation does not require a jboss specific class loader. Combine this with the fact that users tend to treat wars as dumping grounds for jar files regardless if they are needed and two common problems show up:

      1. There are classes that cannot be overriden from a scoped war and so the war class loader needs to be able to ignore attempts to override classes like commons logging. This is most easily done with a custom tomcat class loader.

      2. jsp page class names are not sufficiently unique to allow for multiple wars with the same jsp file names to coexist in a flat class loading space. You'll see random errors like one index.jsp servlet class from another war being used with the result being anything from the wrong content to exceptions due to the wrong execution context.

        Issue Links

          Activity

          Hide
          Scott Stark
          added a comment -

          The default servlet class loading model with war first order is now the default. In addition, there is a FilteredPackages attribute that specifies package names that should not be loaded without delegating to the parent class loader before trying the web app class loader.

          The complete default class loader attributes from the jbossweb-tomcat55.sar/META-INF/jboss-service.xml are:

          <!-- Get the flag indicating if the normal Java2 parent first class
          loading model should be used over the servlet 2.3 web container first
          model.
          -->
          <attribute name="Java2ClassLoadingCompliance">false</attribute>
          <!-- A flag indicating if the JBoss Loader should be used. This loader
          uses a unified class loader as the class loader rather than the tomcat
          specific class loader.
          The default is false to ensure that wars have isolated class loading
          for duplicate jars and jsp files.
          -->
          <attribute name="UseJBossWebLoader">false</attribute>
          <!-- The list of package names that should not be loaded without
          delegating to the parent class loader before trying the web app
          class loader. The packages listed here are those tha are used by
          the web container implementation and cannot be overriden.
          This only applies when UseJBossWebLoader=false.
          -->
          <attribute name="FilteredPackages">org.apache.commons.logging</attribute>

          Show
          Scott Stark
          added a comment - The default servlet class loading model with war first order is now the default. In addition, there is a FilteredPackages attribute that specifies package names that should not be loaded without delegating to the parent class loader before trying the web app class loader. The complete default class loader attributes from the jbossweb-tomcat55.sar/META-INF/jboss-service.xml are: <!-- Get the flag indicating if the normal Java2 parent first class loading model should be used over the servlet 2.3 web container first model. --> <attribute name="Java2ClassLoadingCompliance">false</attribute> <!-- A flag indicating if the JBoss Loader should be used. This loader uses a unified class loader as the class loader rather than the tomcat specific class loader. The default is false to ensure that wars have isolated class loading for duplicate jars and jsp files. --> <attribute name="UseJBossWebLoader">false</attribute> <!-- The list of package names that should not be loaded without delegating to the parent class loader before trying the web app class loader. The packages listed here are those tha are used by the web container implementation and cannot be overriden. This only applies when UseJBossWebLoader=false. --> <attribute name="FilteredPackages">org.apache.commons.logging</attribute>
          Hide
          Adrian Brock
          added a comment -

          This is your basic deploy the classes in two different classloaders
          and then do pass by reference problem, which worked fine
          until we decided to switch to Servlet spec classloading (JBAS-1691)
          in 4.0.2 rather than the JBoss flat classloading model.

          e.g. add the following code to your servlet:
          Object objRef = initial.lookup("gogis/tutorial/slsb/servlet/HelloWorld");
          +out.println(HelloWorldHome.class.getClassLoader());
          +out.println(objRef.getClass().getInterfaces()[0].getClassLoader());

          The other fix is to enable call by value semantics:
          http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration

          P.S. It is a good idea to provide an example than actually works out-of-the-box. If we have to fix your example to even compile it
          (e.g. where is your classpath in build.xml?),
          it is likely to be ignored/rejected

          Show
          Adrian Brock
          added a comment - This is your basic deploy the classes in two different classloaders and then do pass by reference problem, which worked fine until we decided to switch to Servlet spec classloading ( JBAS-1691 ) in 4.0.2 rather than the JBoss flat classloading model. e.g. add the following code to your servlet: Object objRef = initial.lookup("gogis/tutorial/slsb/servlet/HelloWorld"); +out.println(HelloWorldHome.class.getClassLoader()); +out.println(objRef.getClass().getInterfaces() [0] .getClassLoader()); The other fix is to enable call by value semantics: http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration P.S. It is a good idea to provide an example than actually works out-of-the-box. If we have to fix your example to even compile it (e.g. where is your classpath in build.xml?), it is likely to be ignored/rejected
          Hide
          Adrian Brock
          added a comment -

          To revert to pre-4.0.2 config use:
          <attribute name="Java2ClassLoadingCompliance">true</attribute>
          <attribute name="UseJBossWebLoader">true</attribute>

          Show
          Adrian Brock
          added a comment - To revert to pre-4.0.2 config use: <attribute name="Java2ClassLoadingCompliance">true</attribute> <attribute name="UseJBossWebLoader">true</attribute>
          Hide
          Dimitris Andreadis
          added a comment -

          Closing resolved issues.

          Show
          Dimitris Andreadis
          added a comment - Closing resolved issues.

            People

            • Assignee:
              Scott Stark
              Reporter:
              Scott Stark
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: