3 Replies Latest reply on May 5, 2005 1:38 AM by bstansberry

    Reasons for Parent-first vs. Child-first classloading

    bstansberry May 4, 2005 2:47 AM

      There are a couple of related discussions going on on the Jakarta commons-dev mailing list where I'd like to invite the classloading gurus from the JBoss community to weigh in:

      http://marc.theaimsgroup.com/?t=111477819200003&r=1&w=2

      http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=111477251329301&w=2

      These discussions center on a proposal to change commons-logging to use a static binding approach; i.e. one wherein a user who wished to log using log4j would deploy a "commons-logging-log4j.jar" whose "discovery" mechanism would be statically bound to log4j. This approach would replace the existing implementation where JCL uses the thread context classloader to try to dynamically determine what logging library to use.

      The static binding approach is simpler and more reliable, but has the disadvantage of not allowing a contained deployment to override the logging configuration of its container if parent-first classloading is used.

      The following quote from Simon Kitching sums up the argument for using static binding:

      There simply *is* no requirement to be able to deploy the static adaptor lib via one classloader but deploy the actual logging library via another. This isn't something that anyone needs to do.

      (a) if child-first loading is in operation, then the static adaptor and
      the logging library can both be deployed via WEB-INF/lib.

      (b) if parent-first loading is in operation and no static adaptor is
      present in the parent, then the static adaptor and the logging library
      can both be deployed via WEB-INF/lib.

      (c) if parent-first loading is in operation, and a static adaptor +
      logging library are deployed via the parent, then the webapp has no
      control. If they want control, they should use child-first [see scenario
      (a)].


      Where it would be great to get some input from the JBoss folks is on the implications of the last statement above -- if a contained application wants to use a different logging library than its container, it should just use child-first classloading. Any thoughts on problems JCL users might experience from using child-first loading, particularly if the deployment in question isn't a webapp, but is an EJB jar or a SAR? Why is parent-first loading the default in JBoss, even for webapps?

      Sorry if this is off-topic; didn't see a user forum that really fit :)

      Best regards,
      Brian

      • 8866 Views
      • Tags:
        • 1. Re: Reasons for Parent-first vs. Child-first classloading
          starksm64
          starksm64 May 4, 2005 3:08 AM (in response to bstansberry)

          As of 4.0.2, the web container does use child first deployment as the default. However, it explicitly ignores loading classes from commons logging because the interaction of tomcat in jboss results in mbeans bound by the web container service that use commons logging in the scope of the tomcat sar class loader, and these mbeans are used as root mbeans for subsequent war deployments and allowing the war to override the commons logging classes results in type conflicts.

          jboss would have to rename its use of the commons logging package to break the interaction.

            • Actions
          • 2. Re: Reasons for Parent-first vs. Child-first classloading
            starksm64
            starksm64 May 4, 2005 3:16 AM (in response to bstansberry)

            Also, this discussion is somewhat silly because in general you have no control over the class loading structure in j2ee. Show me the spec other than the servlet spec that has any notion of class loader ordering.

              • Actions
            • 3. Re: Reasons for Parent-first vs. Child-first classloading
              bstansberry May 5, 2005 1:38 AM (in response to bstansberry)

              Thanks, Scott. Good to know about the commons-logging interaction problem; this means a static binding approach won't work in a webapp deployed on JBoss 4.0.2. There are other cases where it won't work properly, even in webapps with child-first classloading, so I expect dynamic discovery is here to stay.

              I'm curious where the type conflicts are coming from (i.e. why the container mbeans are interacting with the webapps loggers); I'll have to dig into that sometime.

              Show me the spec other than the servlet spec that has any notion of class loader ordering.


              None that I know of :) Actually, a couple weeks back I looked around (a little) expecting to find parent-first specified somewhere, but found nothing. I interpreted that as meaning containers had freedom to offer child-first classloading for all deployment types if they wanted. I'd thought JBoss allowed that, but now realize I'd confused the meaning of the Java2ParentDelegation flag in the deployment descriptors -- it controls whether a scoped loader will search in a parent repository for a class, not how classloading delegation works if the class is not in a repository.

                • Actions