如何在类SpringBoot框架中读取使用者项目类路径下的Properties文件？

Hey there, let's work through this problem! You've built a custom framework (integrating Spring + MyBatis, similar to Spring Boot) but your current @PropertySource setup only reads config files from the framework's own classpath, not from the application that uses your framework. Here's how to fix this:

Why the Original Code Fails #

The default behavior of @PropertySource uses the classloader that loaded your framework's AppConfig class (typically the classloader for your framework's JAR). This classloader can only access resources inside the framework JAR, not the application's classpath resources (which are managed by the application's classloader, e.g., ApplicationClassLoader or WebAppClassLoader).

Solution 1: Custom PropertySourceFactory (Clean & Annotation-Based) #

You can create a custom PropertySourceFactory that uses the thread context classloader (set to the application's classloader when the app starts up) to load the properties file.

1. Create the custom factory:

import org.springframework.core.env.PropertySource;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;
import org.springframework.core.io.support.EncodedResource;
import org.springframework.core.io.support.PropertySourceFactory;

public class AppClassPathPropertySourceFactory implements PropertySourceFactory {

    @Override
    public PropertySource<?> createPropertySource(String name, EncodedResource resource) throws IOException {
        // Use the application's classloader instead of the framework's
        ClassLoader appClassLoader = Thread.currentThread().getContextClassLoader();
        Resource appResource = new ClassPathResource(resource.getResource().getFilename(), appClassLoader);
        
        // Fallback to framework classloader if the resource isn't found in the app classpath (optional)
        if (!appResource.exists()) {
            appResource = resource.getResource();
        }
        
        return new ResourcePropertySource(name != null ? name : appResource.getFilename(), appResource);
    }
}

2. Update your framework's AppConfig to use this factory:

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.PropertySource;
import org.springframework.context.support.PropertySourcesPlaceholderConfigurer;
import org.springframework.beans.factory.annotation.Value;

@Configuration
// Specify your custom factory to load from the application's classpath
@PropertySource(
    value = "classpath:/application.properties",
    factory = AppClassPathPropertySourceFactory.class
)
public class AppConfig {
    @Value("${app.name}")
    public String name;

    @Bean
    public static PropertySourcesPlaceholderConfigurer placeholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }

    @Bean
    public PostService postService() {
        return new PostServiceImpl(name);
    }
}

Solution 2: Programmatic Property Source Registration (Flexible) #

If you need more control (like loading multiple files or handling dynamic paths), use a BeanFactoryPostProcessor to manually add the application's property source to the Spring environment.

1. Create the processor:

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.config.BeanFactoryPostProcessor;
import org.springframework.beans.factory.config.ConfigurableListableBeanFactory;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.core.env.ConfigurableEnvironment;
import org.springframework.core.env.PropertiesPropertySource;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.support.PropertiesLoaderUtils;

import java.io.IOException;
import java.util.Properties;

public class AppPropertySourceProcessor implements BeanFactoryPostProcessor {

    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        ConfigurableApplicationContext appContext = (ConfigurableApplicationContext) beanFactory.getBean(ApplicationContext.class);
        ConfigurableEnvironment environment = appContext.getEnvironment();
        
        // Get the application's classloader
        ClassLoader appClassLoader = Thread.currentThread().getContextClassLoader();
        
        try {
            // Load the application's properties file
            ClassPathResource resource = new ClassPathResource("application.properties", appClassLoader);
            if (resource.exists()) {
                Properties properties = PropertiesLoaderUtils.loadProperties(resource);
                // Add the properties to the environment (adjust position with addFirst/addLast as needed)
                environment.getPropertySources().addLast(new PropertiesPropertySource("appExternalProperties", properties));
            }
        } catch (IOException e) {
            throw new RuntimeException("Failed to load application.properties from the application classpath", e);
        }
    }
}

2. Register the processor in your framework's AppConfig:

@Configuration
public class AppConfig {
    @Value("${app.name}")
    public String name;

    @Bean
    public static PropertySourcesPlaceholderConfigurer placeholderConfigurer() {
        return new PropertySourcesPlaceholderConfigurer();
    }

    // Register the custom processor
    @Bean
    public static AppPropertySourceProcessor appPropertySourceProcessor() {
        return new AppPropertySourceProcessor();
    }

    @Bean
    public PostService postService() {
        return new PostServiceImpl(name);
    }
}

Key Takeaway #

The thread context classloader is your friend here—it's designed to let libraries access resources from the application that's using them. Both solutions leverage this to switch from the framework's classloader to the application's, ensuring you can read properties from the application's classpath.

内容的提问来源于stack exchange，提问作者Flyer