Docker Configuration Issue: File Loading Fails in Containerized Environment

[jsbankole]

Issue Summary

The EOS application fails to start in Docker environments because it cannot locate the mapping configuration files. This prevents the application from initializing properly.

Environment

• Application: EOS v0.0.1-SNAPSHOT
• Java: 19.0.2
• Spring Boot: 3.2.3
• Container: Docker (eclipse-temurin:19-jre base image)
• Database: PostgreSQL 14

Reproduction Steps

1. Build the Docker image using the provided Dockerfile
2. Start the container using docker-compose or direct docker run command
3. Observe application logs showing error during startup

Error Messages

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'conversionAutoConfiguration' defined in URL [jar:nested:/app/app.jar/!BOOT-INF/classes/!/org/bih/eos/config/ConversionAutoConfiguration.class]: Error loading converter configs from mapping_config/, where any configs provided?

Technical Analysis

Root Cause

1. The ConversionAutoConfiguration class has hardcoded paths for configuration files:

private final String mdDataConfigs = "mapping_conf/medical_data"; private final String personDataConfigs = "mapping_conf/person_data";

2. The FileLoader class uses a direct classpath resource loading approach that fails in Docker:

public static List loadFiles(String resourceFolder, String exceptionMessage) { ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); String osName = System.getProperty("os.name"); if(osName.toLowerCase().contains("windows")){ return load(Objects.requireNonNull(classLoader.getResource(resourceFolder)).getPath().substring(1), exceptionMessage); }else{ return load(Objects.requireNonNull(classLoader.getResource(resourceFolder)).getPath(), exceptionMessage); } }

Impact

The application cannot initialize in Docker environments.

Proposed Solution Approach

We recommend implementing a more robust resource loading mechanism using Spring's ResourcePatternResolver. This approach would:

1. Replace the current direct ClassLoader resource access with Spring's resource handling
2. Add fallback mechanisms to try multiple resource locations
3. Improve error handling with more descriptive messages

This solution would make the application more resilient in containerized environments while maintaining compatibility with development environments.

A pull request with the implementation will be submitted separately.