Use InetAddressResolverProvider and add tests
#1353
Conversation
| * <p>If set, it will be used to look up the {@link java.net.InetAddress} for each host, via | ||
| * {@link InetAddressResolver#lookupByName(String)}. Otherwise, {@link java.net.InetAddress#getAllByName(String)} will be used. |
There was a problem hiding this comment.
This was incorrect, as "Otherwise, ..." did not take into account InetAddressResolverProvider. Builder#inetAddressResolver explains the behavior in full, so I added @see Builder#inetAddressResolver(InetAddressResolver).
| com.mongodb.UnixServerAddress,\ | ||
| com.mongodb.internal.connection.SnappyCompressor,\ | ||
| com.mongodb.internal.connection.ClientMetadataHelper,\ | ||
| com.mongodb.internal.connection.ServerAddressHelper |
There was a problem hiding this comment.
I checked by looking at the reports generated by native-image that these \ line breaks work fine.
| { | ||
| "resources":{ | ||
| "includes":[{ | ||
| "pattern":"\\QMETA-INF/services/com.mongodb.spi.dns.InetAddressResolverProvider\\E" |
There was a problem hiding this comment.
Weirdly, everything works even without this entry, but, if I collect reachability metadata, then this entry is added there.
There was a problem hiding this comment.
That's strange. Did you find that for any other reachability metatada? Can you suggest a hypothesis for what might be going on?
There was a problem hiding this comment.
Did you find that for any other reachability metatada?
I haven't checked everything, nor do I understand how some of the automatically collected resources are used, but removing the shared library resources, or the logback-test.xml resource do have an effect: the former caused runtime errors, the latter results in log entries disappearing.
Can you suggest a hypothesis for what might be going on?
I suspect, it's all about undocumented behavior that is intended to make things easier. I found the following:
- Automatically register classes in META-INF/services for reflection. oracle/graal#563 (comment)
- https://javadoc.io/doc/org.graalvm.nativeimage/svm/20.3.10/com/oracle/svm/hosted/ServiceLoaderFeature.html
Of the two experimental options mentioned in the PR comment linked above, only -H:-UseServiceLoaderFeature is recognized, and it breaks ServiceLoader completely:
- if we don't have the
META-INF/services/com.mongodb.spi.dns.InetAddressResolverProviderresource entry,ServiceLoadersilently fails to locateCustomInetAddressResolverProviderandCustomInetAddressResolverProvider.assertUsed()fails - if we do have the
META-INF/services/com.mongodb.spi.dns.InetAddressResolverProviderresource entry, theServiceLoaderfails withjava.util.ServiceConfigurationError: com.mongodb.spi.dns.InetAddressResolverProvider: Provider com.mongodb.internal.graalvm.CustomInetAddressResolverProvider not foundeven if I re-collect the reachability metadata (it does not find anything new, but it should have registeredCustomInetAddressResolverProviderfor reflection viareflect-config.json).
P.S. Before I found the above, I did and wrote the following:
I had a uneducated guess that maybe the entry is not needed because the
META-INF/services/com.mongodb.spi.dns.InetAddressResolverProviderresource is in the same project as the one I am building, and if the resource were in a pre-built JAR that I depend on, then the resource entry would have been required.Since you asked, I tested that guess: created a new Gradle module with the resource and
CustomInetAddressResolverProvider, removed those from:graalvm-native-image-app, and added theconfiguration:'archives'dependency on the new module to:graalvm-native-image-app. The result is: the entry aboutMETA-INF/services/com.mongodb.spi.dns.InetAddressResolverProviderinresource-config.jsonis still not needed. Note that when there is no entry, the resource is actually not mentioned in theregisterResourcemessages emitted bynative-imagewhen it builds, yetCustomInetAddressResolverProvideris still successfully located viaServiceLoader.I don't have any other hypotheses. The behavior is really weird.
| // informing us on the kind of initialization for each Java class | ||
| buildArgs.add('-H:+PrintClassInitialization') | ||
| // see class initialization and other reports in `graalvm/build/native/nativeCompile/reports` | ||
| buildArgs.add('--diagnostics-mode') |
There was a problem hiding this comment.
--diagnostics-mode includes the functionality of -H:+PrintClassInitialization, and more. So we better use --diagnostics-mode.
driver-core/src/main/resources/META-INF/native-image/org.mongodb/bson/native-image.properties
Show resolved
Hide resolved
|
|
||
| import java.util.ArrayList; | ||
|
|
||
| final class DnsSpi { |
There was a problem hiding this comment.
Since we also have com.mongodb.spi.dns.DnsClientProvider, consider renaming this to InetAddressResolverSpi.
There was a problem hiding this comment.
My plan is to use a custom DnsClientProvider in DnsSpi as part of JAVA-5219, and assert it is used similarly to what I've done in the current PR. Which is why the current class name seems appropriate to me. What do you think?
| { | ||
| "resources":{ | ||
| "includes":[{ | ||
| "pattern":"\\QMETA-INF/services/com.mongodb.spi.dns.InetAddressResolverProvider\\E" |
There was a problem hiding this comment.
That's strange. Did you find that for any other reachability metatada? Can you suggest a hypothesis for what might be going on?
JAVA-5390