Uploaded image for project: 'Commons Logging'
  1. Commons Logging
  2. LOGGING-53

[logging]Need for parent-child classloader relationship prevent JBoss startup


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Nightly Builds
    • Fix Version/s: 1.1.0
    • Labels:
    • Environment:

      Operating System: other
      Platform: Other

    • Bugzilla Id:


      The current version of LogFactoryImpl in svn requires that there be a
      parent-child relationship between the thread context classloader and the
      classloader that loaded LogFactoryImpl. The standard classloading architecture
      used in JBoss (see below) violates this constraint; as a result JBoss will not
      start if a version of JCL built from svn is used.

      The attached patch relaxes this constraint by attempting to load Log adapters
      starting with the thread context classloader if the two classloaders are not in
      a parent child relationship. The behavior change only applies if the user has
      not set the ALLOW_FLAWED_CONTEXT_PROPERTY to true.

      Background: The JBoss classloading architecture includes something called the
      UnifiedLoaderRepository. Basically, when JBoss classloaders are asked to load a
      class they first look to the ULR to see if the class has already been loaded.
      If it has, they return that class. If not, normal Java classloading occurs, but
      once the class is loaded, it is registered with the ULR.

      This setup allows classloaders to see classes loaded by "non-parent"
      classloaders, e.g. siblings, cousins etc. (BTW, ULRs can be scoped, allowing,
      for example, a J2EE EAR to isolate its classes from other deployed applications).

      JBoss loads JCL using a classloader that is not the parent of the classloaders
      used by a number of JBoss services and by deployed applications. So, if JCL
      forbids classloading relationships other than parent-child, JBoss will not start




            • Assignee:
              b_stansberry@hotmail.com Brian Stansberry
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created: