JPA Server is running FHIR R5, but validation throws Java error due to R4 Java modules

[Ben Reddy]

We are setting up a new HAPI FHIR JPA server using one of the latest builds from the hapi-fhir-jpaserver-starter Github repo. Our old server was using v7.0.0. The new one we are setting up is v8.0.0.

Our old server used to run FHIR version R4B, and connects to a Postgres DB. We eventually upgraded the old server to use FHIR version R5. The new HAPI FHIR server is using R5, and it is connecting to the same Postgres DB as the old server. Additionally, our server is configured to use a custom FHIR IG.

When we run a bundle validation on the new server using certain input examples, we are getting a Java error from the server. The error from the server logs says the following:

 2025-05-07T12:20:37.926Z  WARN 1 --- [io-8080-exec-14] ca.uhn.fhir.jpa.term.TermReadSvcImpl     : ValueSet.url[http://hl7.org/fhir/us/spl/ValueSet/valueset-organizationSubmissionMessageTypes] is present in terminology tables but not ready for persistence-backed invocation of operation $validation-code. Will perform in-memory code validation. Current status: FAILED_TO_EXPAND | The ValueSet has been picked up by a scheduled task and pre-expansion has failed.

2025-05-07T12:20:37.953Z ERROR 1 --- [io-8080-exec-14] c.u.f.r.s.i.ExceptionHandlingInterceptor : Failure during REST processing

ca.uhn.fhir.rest.server.exceptions.InternalErrorException: HAPI-0389: Failed to call access method: ca.uhn.fhir.context.ConfigurationException: HAPI-1731: This context is for FHIR version "R5" but the class "org.hl7.fhir.r4.model.ValueSet" is for version "R4"
        at ca.uhn.fhir.rest.server.method.BaseMethodBinding.invokeServerMethod(BaseMethodBinding.java:272)
        at ca.uhn.fhir.rest.server.method.OperationMethodBinding.invokeServer(OperationMethodBinding.java:399)
        at ca.uhn.fhir.rest.server.method.BaseResourceReturningMethodBinding.doInvokeServer(BaseResourceReturningMethodBinding.java:146)
        at ca.uhn.fhir.rest.server.method.BaseResourceReturningMethodBinding.invokeServer(BaseResourceReturningMethodBinding.java:275)
        at ca.uhn.fhir.rest.server.method.OperationMethodBinding.invokeServer(OperationMethodBinding.java:356)
        at ca.uhn.fhir.rest.server.RestfulServer.handleRequest(RestfulServer.java:1201)
        at ca.uhn.fhir.rest.server.RestfulServer.doPost(RestfulServer.java:436)
        at ca.uhn.fhir.rest.server.RestfulServer.service(RestfulServer.java:1961)
        at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:195)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
        at org.springframework.web.filter.ServerHttpObservationFilter.doFilterInternal(ServerHttpObservationFilter.java:113)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
        at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:116)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:164)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:140)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
        at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:483)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344)
        at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:384)
        at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
        at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:905)
        at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1741)
        at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
        at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1190)
        at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
        at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)
        at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.reflect.InvocationTargetException: null
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:569)
        at ca.uhn.fhir.rest.server.method.BaseMethodBinding.invokeServerMethod(BaseMethodBinding.java:264)
        ... 37 common frames omitted

The response message from the server looks like this:
<OperationOutcome xmlns="http://hl7.org/fhir">

    <issue>

        <severity value="error"/>

        <code value="processing"/>

        <diagnostics value="HAPI-0389: Failed to call access method: ca.uhn.fhir.context.ConfigurationException: HAPI-1731: This context is for FHIR version &quot;R5&quot; but the class &quot;org.hl7.fhir.r4.model.ValueSet&quot; is for version &quot;R4&quot;"/>

    </issue>

</OperationOutcome>

 

The input example is an R5 bundle, and the server validation is throwing an error because it seems to be using an R4 Java module. However, our server has fhir_version set to R5 in the application.yaml file.

Does anyone know what is causing this issue? Is it possible that this is happening because the Postgres DB was originally set up with a HAPI FHIR server using R4B? 

[James Agnew]

Did you start the new instance with a fresh/empty database? If you connected your R5 server to the same database you were previously using to serve up R4B contents without wiping it, I suppose that could be an explanation.

If it's a fresh database then this is weird for sure. If you're able to provide a concise and minimal set of steps to reproduce this it might help to explain what is going on..

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/707516bb-dd78-4d62-a327-281d881ae7acn%40googlegroups.com.

[Ben Reddy]

The old HAPI FHIR server v7.0.0 originally used FHIR R4B, and connected to a fresh Postgres DB named “hapi”. Eventually, we upgraded the old HAPI FHIR server to use FHIR R5. We were connected to the same DB during this upgrade without cleaning it up. The server able to work after the upgrade without issue.

The new HAPI FHIR server v.8.0.0 initially used FHIR R5. It was connected to the “hapi” DB without cleaning it up.  However, it is giving the error result mentioned above.

We attempted to make the new HAPI FHIR server connect to a new fresh DB called “hapi-auto”.  However, when we started the server, it said there was an issue loading the custom IG we have specified. The server logs say the following during start up:

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'hapiServletRegistration' defined in ca.uhn.fhir.jpa.starter.Application: Unsatisfied dependency expressed through method 'hapiServletRegistration' parameter 0: Error creating bean with name 'restfulServer' defined in class path resource [ca/uhn/fhir/jpa/starter/common/StarterJpaConfig.class]: Unsatisfied dependency expressed through method 'restfulServer' parameter 25: Error creating bean with name 'packageInstaller' defined in class path resource [ca/uhn/fhir/jpa/starter/common/StarterJpaConfig.class]: Failed to instantiate [ca.uhn.fhir.jpa.packages.IPackageInstallerSvc]: Factory method 'packageInstaller' threw exception with message: HAPI-1285: Could not load NPM package hl7.fhir.us.spl#0.2.6
        at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:795)
        at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:542)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1355)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1185)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:562)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:522)
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:337)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:335)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:205)
        at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:211)
        at org.springframework.boot.web.servlet.ServletContextInitializerBeans.getOrderedBeansOfType(ServletContextInitializerBeans.java:202)
        at org.springframework.boot.web.servlet.ServletContextInitializerBeans.addServletContextInitializerBeans(ServletContextInitializerBeans.java:97)
        at org.springframework.boot.web.servlet.ServletContextInitializerBeans.<init>(ServletContextInitializerBeans.java:86)
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.getServletContextInitializerBeans(ServletWebServerApplicationContext.java:266)
        at org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext.selfInitialize(ServletWebServerApplicationContext.java:240)
        at org.springframework.boot.web.embedded.tomcat.TomcatStarter.onStartup(TomcatStarter.java:52)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:4412)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1203)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1193)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
        at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:749)
        at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:772)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1203)
        at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1193)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
        at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
        at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:749)
        at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:203)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
        at org.apache.catalina.core.StandardService.startInternal(StandardService.java:415)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
        at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:870)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:164)
        at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
        at org.springframework.boot.web.embedded.tomcat.TomcatWebServer.initialize(TomcatWebServer.java:128)

We have tried modifying the implementation guide settings in application.yaml, but it gives the same results.  The current IG settings look like this in the file:

implementationguides:
      packages:
        url: file:src/main/resources/package/hl7.fhir.us.spl.tgz
        name: hl7.fhir.us.spl
        version: 0.2.6
        install_mode: STORE_AND_INSTALL

We have tried adding and removing install_mode, but it didn't make a difference.

Does the HAPI FHIR server need to be connected to Postgres DB specifically named “hapi”? Is there something we need to modify in application.yaml? Let me know if you need full details of the application.yaml file we are using.

[James Agnew]

The name of the DB definitely shouldn't matter, I'd be fairly confident that it's not the cause here.

At least going by your description, that sounds like a bug/regression.. Are you able to share the IG file you're trying to load? I guess just to confirm, is it an R5 IG?

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/435de426-9615-4505-b562-6e49a7c80de8n%40googlegroups.com.

[Ben Reddy]

Here is the download link to the IG we are using:
https://github.com/HL7/fhir-spl/raw/main/package/hl7.fhir.us.spl.tgz

This IG is using R5. 

Thanks,

Ben

[Ben Reddy]

We tried using version 7.6.0 of the JPA server with R5 and had it connect to the new Postgres DB. However, it is still having issue loading the custom IG. 

Connecting to the old DB (the one that originally connected to the old HAPI FHIR serve that used R4B originally and upgraded to R5) does not have issues with starting the server. However, doing that leads to the problem we had with the validation saying it is using R4 modules when we are having HAPI FHIR server use R5. 

[James Agnew]

I just gave that package a whirl, and the issue is with the paths in the tgz file. They have a prefix of "./", so when the package manager scans for a file called "package/package.json" it doesn't find it because the file is named "./package/package.json".

I extracted and rezipped the package, and it imports cleanly with that change. I'm going to file a ticket for us to emit a more helpful error message if we see this in the future.

Cheers,

James

On Wed, May 7, 2025 at 1:07 PM Ben Reddy <benreddy...@gmail.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/435de426-9615-4505-b562-6e49a7c80de8n%40googlegroups.com.

[Ben Reddy]

How did you test the IG package I provided? Did you start a JPA server with a clean DB? If so, which version of JPA server did you use?

How did you configure the implementation guide in application.yaml?

When I use the command "tar -tf" on the NPM package, I am able see the ./ prefix in the directories. What were the commands you used to extract and rezip the package without the ./ prefix? Is there a way to build the IG package so that it doesn't start with the ./ prefix?

Thanks,
Benjamin Reddy

[James Agnew]

I tested this inside a unit test in the HAPI JPA server so no starter config, but I don't think that should matter. I reproduced being unable to load it, and after fixing the broken package it imports cleanly.

To fix it, I just issued the following commands:

mkdir tmp;

cd tmp;

tar xvf ~/path/to/package.tgz;

tar zcvf ~/path/to/package.tgz *;

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/831e3021-e9ef-4527-91cb-f087a7e4f48en%40googlegroups.com.

[Ben Reddy]

We followed the instructions to fix the IG package and restarted the HAPI FHIR server. The server was able to start up without issue, and it connected to the new DB. The IG was loaded into the DB.

However, we are still having the same issue as before with the validation. When I run the validation API on an R5 Organization bundle, I still get the same error saying that the server is using R4 java modules. The error logs from the server are below:

---

 2025-05-08T17:17:52.775Z  WARN 1 --- [nio-8080-exec-3] ca.uhn.fhir.jpa.term.TermReadSvcImpl     : ValueSet.url[http://hl7.org/fhir/us/spl/ValueSet/valueset-organizationSubmissionMessageTypes] is present in terminology tables but not ready for persistence-backed invocation of operation $validation-code. Will perform in-memory code validation. Current status: FAILED_TO_EXPAND | The ValueSet has been picked up by a scheduled task and pre-expansion has failed.

2025-05-08T17:17:52.828Z ERROR 1 --- [nio-8080-exec-3] c.u.f.r.s.i.ExceptionHandlingInterceptor : Failure during REST processing

Caused by: ca.uhn.fhir.context.ConfigurationException: HAPI-1731: This context is for FHIR version "R5" but the class "org.hl7.fhir.r4.model.ValueSet" is for version "R4"

---

The application.yaml file is configured to use FHIR version R5, and the IG is for R5. We also tried configuring the IG settings in application.yaml to use install_mode: STORE_AND_INSTALL, but it didn't fix it.

Do you know what are the next steps to take in order to resolve this issue? Let me know if you need more information about the server we're running.

Thanks,
Benjamin Reddy

[Ben Reddy]

We tried upgrading the HAPI FHIR server to use 8.0.0-2 release, but we encountered the same issue.

If you need to test the validation API on your end, I have attached an xml example of the bundle I am trying to validate.

[James Agnew]

I just tried it and I see the same error. Trying to figure out why.

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/26535c71-2b50-4145-82b7-fcf529583d1en%40googlegroups.com.

[Ben Reddy]

Hello James,

Do you have any updates about the cause of the validation issue in the HAPI FHIR server?

Thanks,

Benjamin Reddy

[James Agnew]

This appears to be a bug in JpaPersistedResourceValidationSupport.

Working on a fix, should hit 8.4.0-SNAPSHOT builds within the next week or so.

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/bcb8d15b-d6cb-42cd-a818-10fb20cb9bd3n%40googlegroups.com.

[Ben Reddy]

Thanks James. Let me know when the build with this bug fix is released.

[Ben Reddy]

Hello James,

I noticed that you said the fix would be for the 8.4.0-SNAPSHOT build. However, the latest hapi-fhir-jpaserver-starter build is v8.0.0-2, which is what we are using for our project. Will this bug fix be part of the next hapi-fhir-jpaserver-starter project build? 

Thanks,

Benjamin Reddy

[James Agnew]

Ah yeah I guess I should explain that: 

The current HAPI GA release is 8.0.0. We do an even-odd minor version strategy where the evens are GA releases and the odds are development builds. So the next HAPI FHIR release will be 8.2.0, which should ship next week. We've already passed the code freeze date though for 8.2.0, so this fix will appear in the next GA release, which will be 8.4.0 and will ship in August.

This is the PR to fix the version issue: https://github.com/hapifhir/hapi-fhir/pull/6968

This is the PR to fix the parsing on the invalid NPM package: https://github.com/hapifhir/org.hl7.fhir.core/pull/1992

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/9d1f9744-5d63-4e36-b4bb-b7aa9bb18c43n%40googlegroups.com.

[Ben Reddy]

Just to be sure I understand, does this mean the next release of HAPI FHIR JPA starter server will be version 8.2.0, but it won't have the fixes for my issues mentioned above? If so, is there any way to pull those fixes to my project's JPA starter server earlier, or do I have to wait for the JPA starter server 8.4.0 in August to actually see those fixes?

Thanks,

Benjamin Reddy

[James Agnew]

Yup, that's correct.

You could try upgrading your starter to point to the latest HAPI FHIR 8.3.x-SNAPSHOT once we merge the fix into HAPI master, release JPA starter 8.2.0, and publish a new snapshot build after the fix has merged. We're early enough in the release cycle that this would probably work without much fuss. I wouldn't recommend bringing such a thing to production, but certainly as a way of testing the fix that should work.

(Or if you have a support contract, you could certainly request a backport hotfix)

Cheers,

James

To view this discussion visit https://groups.google.com/d/msgid/hapi-fhir/fd0bc8b6-f4ac-4998-b6f3-9d13a3afe018n%40googlegroups.com.