Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Nightly Builds
-
None
-
Operating System: other
Platform: Other
-
35423
Description
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.