Infinispan client cannot find SaslServerFactory in native mode

[jamesnetherton]

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)

[quarkus-bot]

/cc @karesti, @wburns

[karesti]

@jamesnetherton taking a look today

[geoand]

For this Service Loader stuff to work in native mode, one would generate ServiceProviderBuildItem from the appropriate Quarkus build step

[jamesnetherton]

For this Service Loader stuff to work in native mode, one would generate ServiceProviderBuildItem from the appropriate Quarkus build step

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? 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.

[geoand]

@zakkak ^

[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 oracle/graal#3664 to track this. Thanks for bringing it up @jamesnetherton !

[gsmet]

I think for now the best solution is to add the security provider ourselves. I created #19336 .