You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Mattias Jiderhamn (JIRA)" <ji...@apache.org> on 2013/12/06 22:19:36 UTC

[jira] [Created] (CXF-5442) CXFAuthenticator causes classloader leaks

Mattias Jiderhamn created CXF-5442:
--------------------------------------

             Summary: CXFAuthenticator causes classloader leaks
                 Key: CXF-5442
                 URL: https://issues.apache.org/jira/browse/CXF-5442
             Project: CXF
          Issue Type: Bug
          Components: Transports
    Affects Versions: 2.6.10
            Reporter: Mattias Jiderhamn


org.apache.cxf.transport.http.CXFAuthenticator will cause classloader leaks.

When CXFAuthenticator.addAuthenticator() is called, org.apache.cxf.transport.http.ReferencingAuthenticator is instantiated in a custom "dummy" URLClassLoader, and then wraps any pre-existing default Authenticator + weak references the CXFAuthenticator.

In theory, this means that the classloader loading the CXFAuthenticator can be garbage collected, and then ReferencingAuthenticator.auth is cleared since CXFAuthenticator.instance is not strongly reachable from GC root.

I won't say my conclusions are final, but this is how I think it happens: When the dummy URLClassLoader is instantiated, it inherits the AccessControlContext that references the current classloader, which is the one that loaded CXFAuthenticator and thus there is a path to GC root (see screenshot) and the web app classloader is never garbage collected.



--
This message was sent by Atlassian JIRA
(v6.1#6144)