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

Hi - thanks for your reply. See comments below.

On Fri, Sep 11, 2020 at 2:36 AM Lukas Jungmann <lukas.jungmann@xxxxxxxxxx> 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?


We need to use our custom Authenticator, which requires us to define it within the library, That doesn't seem like a modification that would make sense generally. We are going to add this to 
BindingProviderProperties:

public static final String CUSTOM_AUTHENTICATOR =
    "<path to our authenticator>";
 

  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.


I don't know how to do the different implementations for different JDKs.I can't figure out how to build successfully with JDK 11.

It's unclear to me how this works with multi-release versions. When I fork from .git, I took your advice and grabbed the 2.3.3 beta version, opened in Eclipse, and modified the code. But, I am getting the same build error I saw with 2.3.2:

[ERROR] /C:.../metro-jax-ws/jaxws-ri/runtime/rt/src/main/java/com/sun/xml/ws/transport/http/client/HttpClientTransport.java:[275,27] cannot find symbol
  symbol:   method setAuthenticator(java.net.Authenticator)
  location: variable httpConnection of type java.net.HttpURLConnection

I have added the java.net.Authenticator import. How do I specify to build with Java 11 using Maven? How can I see what version it's using now?

Thanks,
Nancy

Back to the top