FHIRClient.getWebTarget(String baseURL) throws NPE

[csandersdev]

Describe the bug
Using the following code, the client generates a NullPointerException.

public class ClientTest {
	@Test
	public void testGetWebTargetBaseUrl() throws Exception {
		String baseURL = "http://hapi.fhir.org/baseR4";
		
		Properties properties = new Properties();
		properties.put(FHIRClient.PROPNAME_BASE_URL, baseURL);
		FHIRClient client = FHIRClientFactory.getClient( properties );
		client.getWebTarget( baseURL + "/Patient?_page=2" ).request("application/json").get();
	}
}

Environment
4.8.2

To Reproduce
Steps to reproduce the behavior:

1. Execute the code as shown above.

Expected behavior
The code executes normally, passing all configurations specified in the initial properties collection to the URL specified in the getWebTarget(String) method (e.g. basic authentication, tenant header, keystore, truststore, etc.).

Additional context
I came across this while trying to write code that will follow the links in the Bundle resource returned from search query. As a workaround, I've so far been about to use getWebTarget().path(fullUrl) and that seems to work.

[prb112]

getClient is our typical entrrypoint. I'll add a check for this code path.

[JohnTimm]

@csandersdev please attach the stacktrace if you have it handy.

[csandersdev]

@prb112 getClient is only available on the impl class and is protected. I think it would be useful to expose outward if folks are ok with that.

@JohnTimm The NPE is because it is trying to use keystore properties that are null in my configuration. The getWebTarget() method without params uses getClient() which checks for nulls. The getWebTarget(String) and getWebTargetUsingBasicAuth(String,String,String) methods don't use getClient() and are not null-safe.

java.lang.NullPointerException
	at javax.ws.rs.client.ClientBuilder.keyStore(ClientBuilder.java:185)
	at com.ibm.fhir.client.impl.FHIRClientImpl.getWebTarget(FHIRClientImpl.java:820)
	at com.ibm.fhir.cql.engine.rest.ClientTest.testGetWebTargetBaseUrl(ClientTest.java:20)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:542)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:770)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:464)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)

[lmsurpre]

@CoreySandersOH this is now in main and slated for 4.8.3. Mind helping to confirm that these changes adequately address the issue?

[csandersdev]

LGTM