More on this: I have verified that I'm linked to JDK11, but the Maven build still fails so clearly Maven has a different way to find the JDK. See screenshot of what my Eclipse looks like. Also, I noticed that when I build (before modifications), I always get a test failure on AbstractSchemaValidationTubeTest so I am forced to remove that file. Maybe this is an indication that my process for building is wrong, because it clearly is.
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$
>
_______________________________________________
metro-dev mailing list
metro-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/metro-dev
