cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: CXFAuthenticator questions
Date Wed, 10 May 2017 19:45:13 GMT
The main reason for all the convoluted class loader stuff in this case is to make sure the
static reference  doesn’t reference any class or anything from the CXF class loaders so
that a web app can properly be un-deployed in tomcat or similar.   If we create our own class
loader, then that class loader would maintain a reference to the CXF jars and prevent them
from being collected and such.   


> On May 10, 2017, at 12:07 PM, Adam T Anderson <> wrote:
> Hello everyone,
> I'm looking into jigsaw support for CXF and I found that CXF already seems
> to be java 9 ready using the --add-opens options. I would like to clean
> this up since those options will be going away eventually.
> Looking at the CXFAuthenticator I see that we are using reflection to load
> the ReferencingAuthenticator via a dummy URLClassLoader to access the
> SystemClassLoader and using reflection to call ClassLoader.defineClass()
> and also setting the private final field URLClassLoader.acc to null when we
> are done. With jigsaw we are not allowed to use reflection in this way.
> According to the Java 9 documentation we should be creating our own
> classloader to load ReferencingAuthenticator and overriding
> ClassLoader.findClass() to call ClassLoader.defineClass().
> However, when I make these changes, CXFAuthenticatorCleanupTest tests fail.
> I'm at a point where I would need to make changes to
> ReferencingAuthenticator as well but I don't fully understand how it works
> or why it needs to use reflection.
> Are there secondary effects of using reflection to load the
> ReferencingAuthenticator that I don't understand?
> Thanks,
> Adam Anderson

Daniel Kulp -
Talend Community Coder -

View raw message