Description
I have written a capability java class replacement that will use a whitelist to limit the capability statement to a list of whitelisted resources, however i keep hitting the same issues.
both methods of activating your custom code (@bean registration via component scan AND direct loading via custom-provider-classes) are somehow preventing the DataSource bean (created by Spring Boot's default auto-configuration) from being available when HAPI's StarterJpaConfig needs it.
This points away from a simple conflict between the two registration methods and suggests a more fundamental issue, likely related to initialization timing or classpath visibility/conflicts within the Tomcat WAR deployment environment.
It seems highly likely that the act of loading any custom HAPI component (whether a Provider via custom-provider-classes or a Bean via component-scan that depends on HAPI classes like RestfulServer) is causing Spring/HAPI to try and initialize the full JPA persistence stack before the default DataSource bean has been fully created and registered by DataSourceAutoConfiguration.
even if i define the datasources in my code it still fails:
Parameter 0 of method entityManagerFactory in ca.uhn.fhir.jpa.starter.common.StarterJpaConfig required a bean of type 'javax.sql.DataSource' that could not be found.
Summary:
When attempting to integrate a custom Java class extending ca.uhn.fhir.rest.server.provider.ServerCapabilityStatementProvider into a HAPI FHIR JPA server (v8.0.0, WAR deployment on Tomcat 10.1), the server fails to start due to an UnsatisfiedDependencyException for javax.sql.DataSource. This occurs when the custom provider is activated, either through Spring @bean registration (via @configuration and component scanning) or through HAPI FHIR's hapi.fhir.custom-provider-classes property.
The server only starts successfully if:
Spring Boot's default DataSourceAutoConfiguration is allowed to run (i.e., it's not excluded in application.yaml).
The custom ServerCapabilityStatementProvider is not activated by any mechanism.
This suggests that the introduction of the custom HAPI provider, regardless of its registration method, triggers an early initialization of the JPA persistence stack. This occurs before the DataSource bean (whether it's supposed to be provided by HAPI's internal configuration or by Spring Boot's default auto-configuration) is fully created and available in the application context. Consequently, the ca.uhn.fhir.jpa.starter.common.StarterJpaConfig class cannot obtain the required DataSource to create the entityManagerFactory, leading to the startup failure.
The issue appears to be a conflict in the bean/component initialization lifecycle or classpath visibility when custom HAPI providers are added to a WAR-deployed HAPI FHIR JPA server on Tomcat. Explicitly defining a @primary DataSource bean via Spring @configuration also did not resolve the issue when the custom provider bean was simultaneously active.
link to github:
https://github.com/Sudo-JHare/Hapi-Whitelist