I've run into a similar behavior with 5.1.0 with the following code. The following code is used in some integration tests against a vault docker container in dev mode, so no SSL configuration.
VaultConfig config = new VaultConfig()
.address(http://127.0.0.1:56342")
.token("kxbfgiertgibadsf");
yields this exception
com.bettercloud.vault.VaultException: java.lang.NullPointerException
at com.bettercloud.vault.api.Logical.read(Logical.java:120)
at com.bettercloud.vault.api.Logical.list(Logical.java:316)
at com.bettercloud.vault.api.Logical.list(Logical.java:309)
at com.github.jcustenborder.kafka.connect.vault.VaultClusterHealthCheck.lambda$isClusterHealthy$0(VaultClusterHealthCheck.java:34)
at com.palantir.docker.compose.connection.waiting.SuccessOrFailure.onResultOf(SuccessOrFailure.java:27)
at com.github.jcustenborder.kafka.connect.vault.VaultClusterHealthCheck.isClusterHealthy(VaultClusterHealthCheck.java:22)
at com.palantir.docker.compose.connection.waiting.ClusterWait.lambda$weHaveSuccess$23(ClusterWait.java:57)
at com.jayway.awaitility.core.CallableCondition$ConditionEvaluationWrapper.call(CallableCondition.java:99)
at com.jayway.awaitility.core.CallableCondition$ConditionEvaluationWrapper.call(CallableCondition.java:85)
at com.jayway.awaitility.core.ConditionAwaiter$1.run(ConditionAwaiter.java:54)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:832)
Caused by: java.lang.NullPointerException: null
at com.bettercloud.vault.api.Logical.read(Logical.java:92)
... 15 common frames omitted
Changing the code to this works.
SslConfig sslConfig = new SslConfig()
.verify(false);
VaultConfig config = new VaultConfig()
.sslConfig(sslConfig)
.address(http://127.0.0.1:56342")
.token("kxbfgiertgibadsf");
The read() method seems to make the assumption that a SslConfig will be supplied. This seems to be covered by the examples but it might be nice to throw an exception that is more clear earlier.
I've run into a similar behavior with 5.1.0 with the following code. The following code is used in some integration tests against a vault docker container in dev mode, so no SSL configuration.
yields this exception
Changing the code to this works.
The read() method seems to make the assumption that a SslConfig will be supplied. This seems to be covered by the examples but it might be nice to throw an exception that is more clear earlier.