[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [metro-dev] Help with fork modification to metro-jax-ws
|
to be clear JDK 11 is required to build 2.3.3+ and master; I'm not sure
about older jaxws-ri versions
On 9/11/20 11:35 AM, Lukas Jungmann wrote:
Hi,
On 9/11/20 1:30 AM, Nancy Bosecker wrote:
Hi all-
I’m working on a project that has recently been migrated to Java 11,
and uses jaxws-rt-2.3.2 for SOAP communication.
With Java 8, we had a workaround for the JDK bug here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6626700
The default Authenticator (global) was caching credentials, and we
used this code to clear it per the workaround:
AuthCacheValue.setAuthCache(new AuthCacheImpl());
This is no longer a viable option with Java 11, as the setAuthCache()
API is no longer visible or available.
JDK 9+ has added a method to java.net.HttpURLConnection,
setAuthenticator, which we believe will allow us to use our custom
Authenticator instead of the default. [
https://bugs.openjdk.java.net/browse/JDK-4303463]
We’re using jaxws-rt, and we see that there is no way for us to access
the HttpURLConnection from outside the library, so I am looking at
forking and modifying your library code.
Why are you not considering submitting a PR to get this fixed in the
main code base so you don't have to maintain your own fork?
Specifically, adding code to
HttpClientTransport::createHttpConnection like this:
Authenticator auth =
(Authenticator)context.invocationProperties.get(BindingProviderProperties.CUSTOM_AUTHENTICATOR);
if (auth != null) {
httpConnection.setAuthenticator(auth);
}
where CUSTOM_AUTHENICATOR points to our Authenticator implementation.
Why not adding simple boolean property which would control the cache and
jdk specific version of the code doing actual cleanup - reflection for
JDK8 and authenticator approach for JDK 9+?
If you check master, you see that jaxws-rt as well as jaxws-tools are
multi-release jars, this way it is possible to use new APIs on new JDKs
while still staying compatible with older ones.
And now to my many questions:
1)Does this seem like a sound approach, or have any of you encountered
this issue and solved it in a different way?
2)I’ve used Git/Eclipse to download the source code and build with
Maven. But, I run into compatibility issues because the
setAuthenticator() method is JDK9+ and it looks like the
base.java.level of the parent .pom is 8, so the compilation fails with
unknown symbol. I tried to up base to jdk 9, but then the code fails
to compile with other compatibility errors. Is there a way to achieve
my goal of adding this code?
instead of version 2.3.2, you should use 2.3.3 and base what you need to
do on top of that if you need 'javax.' namespace, otherwise master is
the way to go. For building the latter version, JDK 11 is required; for
the former, I do not remember details but JDK 11 (probably sth like
11.0.2) would be my first try.
For the change like this, it should not matter whether the patch is made
for master or 2.3.3 (2) as the diff should be almost the same.
thanks,
--lukas
3)If 1 and/or 2 are viable options, what are the licensing
ramifications of using a modified version of the library? We’ve never
done this before, so that is unclear to us.
Thanks for any input/advice,
Nancy Bosecker
_______________________________________________
metro-dev mailing list
metro-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/metro-dev__;!!GqivPVa7Brio!Ild50D_aTDpn6sSVTIJChOGTHMkFCuCKtOXty3_QEhe6AT6kEj67CdMXrNDpPNK-YLk$
_______________________________________________
metro-dev mailing list
metro-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/metro-dev__;!!GqivPVa7Brio!JD9fiE-VvIbirhndn3vUDPvNe2UD1du4ij4IhwV1bZQndc4sVQDSioLGMM-FkTeZkHI$
