Infinispan client cannot find `SaslServerFactory` in native mode

Testing the latest Camel Quarkus Infinispan SNAPSHOT with the latest Quarkus Infinispan SNAPSHOT reveals an error in native mode. Seems that Infinispan itests in Quarkus do not use authentication, so maybe this has gone unnoticed since the upgrade to GraalVM 21.2.0.

The client configuration used in the Camel Infinispan itest is here.

I guess there’s a typo in the IllegalStateException message, ‘now’ instead of ‘not’, which makes things kinda confusing.

2021-08-03 09:29:57,789 WARN  [io.net.cha.ChannelInitializer] (HotRod-client-async-pool-1-4) Failed to initialize a channel. Closing: [id: 0xa7565909]: java.lang.IllegalStateException: SaslClientFactory implementation now found
	at org.infinispan.client.hotrod.impl.transport.netty.ChannelInitializer.getSaslClientFactory(ChannelInitializer.java:203)
	at org.infinispan.client.hotrod.impl.transport.netty.ChannelInitializer.initAuthentication(ChannelInitializer.java:162)
	at org.infinispan.client.hotrod.impl.transport.netty.ChannelInitializer.initChannel(ChannelInitializer.java:80)
	at io.netty.channel.ChannelInitializer.initChannel(ChannelInitializer.java:129)
	at io.netty.channel.ChannelInitializer.handlerAdded(ChannelInitializer.java:112)
	at io.netty.channel.AbstractChannelHandlerContext.callHandlerAdded(AbstractChannelHandlerContext.java:938)
	at io.netty.channel.DefaultChannelPipeline.callHandlerAdded0(DefaultChannelPipeline.java:609)
	at io.netty.channel.DefaultChannelPipeline.access$100(DefaultChannelPipeline.java:46)
	at io.netty.channel.DefaultChannelPipeline$PendingHandlerAddedTask.execute(DefaultChannelPipeline.java:1463)
	at io.netty.channel.DefaultChannelPipeline.callHandlerAddedForAllHandlers(DefaultChannelPipeline.java:1115)
	at io.netty.channel.DefaultChannelPipeline.invokeHandlerAddedIfNeeded(DefaultChannelPipeline.java:650)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.register0(AbstractChannel.java:514)
	at io.netty.channel.AbstractChannel$AbstractUnsafe.access$200(AbstractChannel.java:429)
	at io.netty.channel.AbstractChannel$AbstractUnsafe$1.run(AbstractChannel.java:486)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.lang.Thread.run(Thread.java:829)
	at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:567)
	at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:192)

[zakkak]

FWIW I have a SASL issue in a different extension and fixed it by producing NativeImageSecurityProviderBuildItem for com.sun.security.sasl.Provider.

Curious as to why this worked prior to GraalVM 21.2.0 without any special config? Maybe the change is due to this oracle/graal@10cc640#diff-b74986643ea0d26f6a08173f26b9330b4b26d3f4369a7a524b7bc2c36092d56f?

Correct.

Not sure if I’m misunderstanding the docs, but it seems to hint that the providers built into the JDK should have been automatically registered.

I have created https://github.com/oracle/graal/issues/3664 to track this. Thanks for bringing it up @jamesnetherton !

[geoand]

@zakkak ^