You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Adam T Anderson <at...@us.ibm.com> on 2017/05/10 16:07:00 UTC
CXFAuthenticator questions
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
Re: CXFAuthenticator questions
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi Adam,
if it helps java 9 defineClass is accessible through Unsafe
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2017-05-10 18:07 GMT+02:00 Adam T Anderson <at...@us.ibm.com>:
>
>
> 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
>
Re: CXFAuthenticator questions
Posted by Adam T Anderson <at...@us.ibm.com>.
Dan,
Do you have any thought on how we could work around this when the
--add-opens option is removed?
Thanks,
Adam Anderson
From: Daniel Kulp <dk...@apache.org>
To: dev@cxf.apache.org
Date: 05/10/2017 02:45 PM
Subject: Re: CXFAuthenticator questions
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 <at...@us.ibm.com>
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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: CXFAuthenticator questions
Posted by Daniel Kulp <dk...@apache.org>.
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 <at...@us.ibm.com> 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
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com