Unable to determine StAX implementation?

[Reynald Jhonson]

Hi everyone,

I am currently learning to use the HAPI FHIR. I am trying to create a client that can fetch data from FHIR Server. 

I've downloaded the hapi-fhirstarters-client-skeleton and try to run it on my Visual Studio Code. I also have installed Maven and Java Project Manager in it.

The first time i run it (TestApplication.java), it ran without any problem. It can fetch the data from the server. 

But the next day and until now, whenever i try to run it, it will return error. Here is the error message:

2022-10-21 12:56:30.209 [main] INFO  ca.uhn.fhir.util.VersionUtil [VersionUtil.java:84] HAPI FHIR version 6.0.0 - Rev d569f49179
2022-10-21 12:56:30.213 [main] INFO  ca.uhn.fhir.context.FhirContext [FhirContext.java:208] Creating new FHIR context for FHIR version [R4]
2022-10-21 12:56:30.368 [main] INFO  ca.uhn.fhir.util.XmlUtil [DependencyLogImpl.java:79] Unable to determine StAX implementation: java.xml/META-INF/MANIFEST.MF not found
Exception in thread "main" ca.uhn.fhir.rest.client.exceptions.FhirClientConnectionException: HAPI-1357: Failed to retrieve the server metadata statement during client initialization. URL used was https://hapi.fhir.org/baseR4/metadata
        at ca.uhn.fhir.rest.client.impl.RestfulClientFactory.validateServerBase(RestfulClientFactory.java:323)
        at ca.uhn.fhir.rest.client.impl.RestfulClientFactory.validateServerBaseIfConfiguredToDoSo(RestfulClientFactory.java:274)
        at ca.uhn.fhir.rest.client.impl.BaseClient.invokeClient(BaseClient.java:252)
        at ca.uhn.fhir.rest.client.impl.GenericClient.doReadOrVRead(GenericClient.java:244)
        at ca.uhn.fhir.rest.client.impl.GenericClient$ReadInternal.execute(GenericClient.java:1685)
        at test.TestApplication.main(TestApplication.java:21)
Caused by: ca.uhn.fhir.rest.client.exceptions.FhirClientConnectionException: HAPI-1361: Failed to parse response from server when performing GET to URL https://hapi.fhir.org/baseR4/metadata - java.net.SocketTimeoutException: Read timed out
        at ca.uhn.fhir.rest.client.impl.BaseClient.invokeClient(BaseClient.java:425)
        at ca.uhn.fhir.rest.client.impl.GenericClient$BaseClientExecutable.invoke(GenericClient.java:541)
        at ca.uhn.fhir.rest.client.impl.GenericClient$FetchConformanceInternal.execute(GenericClient.java:833)
        at ca.uhn.fhir.rest.client.impl.RestfulClientFactory.validateServerBase(RestfulClientFactory.java:311)
        ... 5 more
Caused by: java.net.SocketTimeoutException: Read timed out
        at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:283)
        at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:309)
        at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:350)
        at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:803)
        at java.base/java.net.Socket$SocketInputStream.read(Socket.java:966)
        at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:478)
        at java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:472)
        at java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
        at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1460)
        at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1064)
        at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
        at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
        at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:280)
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
        at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
        at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
        at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
        at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:157)
        at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
        at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
        at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
        at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)
        at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
        at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
        at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
        at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:56)
        at ca.uhn.fhir.rest.client.apache.ApacheHttpRequest.execute(ApacheHttpRequest.java:70)
        at ca.uhn.fhir.rest.client.impl.BaseClient.invokeClient(BaseClient.java:328)
        ... 8 more

Can anyone help me? I believe that the problem lays on the fact that it can't found the META-INF? And if indeed so, how could i fix it?

Many thanks!

Rey

[ABHISHEK PRATAP SINGH]

Yo got the answer yet?

[Norbert Strobel]

Same for me, and also looking for an answer why there is a "ca.uhn.fhir.util.XmlUtil - Unable to determine StAX implementation: java.xml/META-INF/MANIFEST.MF not found" server response. Any answer/advise is highly appreciated!

[Brad Solomon]

Can't claim that I understand why, but this log warning disappeared for us when we added the following to pom.xml under the <build> section:

      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
      </plugin>

However, in our case, our packaging is <packaging>jar</packaging>, so not sure if this applies for WAR packaging.