You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Dennis Lundberg (JIRA)" <ji...@apache.org> on 2009/12/29 15:36:29 UTC

[jira] Updated: (LOGGING-53) [logging]Need for parent-child classloader relationship prevent JBoss startup

     [ https://issues.apache.org/jira/browse/LOGGING-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dennis Lundberg updated LOGGING-53:
-----------------------------------

    Fix Version/s: 1.1.0

> [logging]Need for parent-child classloader relationship prevent JBoss startup
> -----------------------------------------------------------------------------
>
>                 Key: LOGGING-53
>                 URL: https://issues.apache.org/jira/browse/LOGGING-53
>             Project: Commons Logging
>          Issue Type: Bug
>    Affects Versions: Nightly Builds
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Brian Stansberry
>             Fix For: 1.1.0
>
>         Attachments: LogFactoryImplJBoss.diff
>
>
> 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
> properly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.