Skip to main content

[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$


Back to the top