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.
Dan > On May 10, 2017, at 12:07 PM, Adam T Anderson <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
