Spring Boot не выбирает application.properties в среде пользовательского загрузчика классов

Изоляция загрузчика классов и методы загрузки ресурсов, которые не согласованы должным образом, часто являются причиной проблемы, когда Spring Boot не может загрузить файл application.properties в пользовательской среде загрузчика классов. Вы можете выявить и устранить проблему более успешно, если убедитесь, что используется правильный загрузчик классов, конкретно задаете расположение файла конфигурации и включаете ведение журнала отладки.

Это обновленный пример установки явного местоположения файла конфигурации для приложения Spring Boot:

public static void run(Class<?> plugin, String pluginName) {
final ClassLoader pluginClassLoader = plugin.getClassLoader();

// needed or else spring startup fails
Thread.currentThread().setContextClassLoader(pluginClassLoader);

final ResourceLoader loader = new DefaultResourceLoader(pluginClassLoader);
final SpringApplicationBuilder builder = new SpringApplicationBuilder();
final Class<?> pluginConfiguration = Class.forName(plugin.getPackageName() + ".PluginConfiguration");
final Class<?>[] sources = {pluginConfiguration, SpigotConfiguration.class, BungeecordConfiguration.class};

context = builder.sources(sources)
        .initializers(applicationContext -> {
            applicationContext.setClassLoader(pluginClassLoader);
        })
        .resourceLoader(loader)
        .properties("spring.config.location=classpath:/application.properties")
        .properties("plugin.name = " + pluginName)
        .properties("plugin.main = " + plugin.getName())
        .run();

}

Я нашел способ решить свою проблему.

Когда Spring сообщает Spring использовать «StandardEnvironment» во время сборки, Spring выбирает любой набор системных свойств перед запуском:

builder.initializers(applicationContext -> {
    applicationContext.setEnvironment(new StandardEnvironment());
})

Теперь я могу использовать предложение @mlecz (загрузка application.properties с объектом Properties и перебор каждой пары ключ-значение, а затем установка системного свойства для каждой пары).

Это обходной путь, а не та функциональность, на которую я надеялся, но она работает.

Вот отредактированный фрагмент кода для тех, у кого есть подобные проблемы с реализацией Spring в такой среде:

public static void run(Class<?> plugin, String pluginName) {
    final ClassLoader pluginClassLoader = plugin.getClassLoader();
    // needed or else spring startup fails
    Thread.currentThread().setContextClassLoader(pluginClassLoader);

    final ResourceLoader loader = new DefaultResourceLoader(pluginClassLoader);
    final SpringApplicationBuilder builder = new SpringApplicationBuilder();
    final Class<?> pluginConfiguration = Class.forName(plugin.getPackageName() + ".PluginConfiguration");
    final Class<?>[] sources = {pluginConfiguration, SpigotConfiguration.class, BungeecordConfiguration.class};

    System.setProperty("plugin.name", pluginName);
    System.setProperty("plugin.main", plugin.getName());

    try {
        final Properties properties = new Properties();

        properties.load(pluginClassLoader.getResourceAsStream("application.properties"));

        properties.forEach((key, value) -> {
            System.setProperty(key.toString(), value.toString());
        });
    } catch (Exception ignored) {}

    context = builder.sources(sources)
            .initializers(applicationContext -> {
                applicationContext.setClassLoader(pluginClassLoader);
                // this somehow enables spring to pickup the system properties    
                applicationContext.setEnvironment(new StandardEnvironment());
            })
            .resourceLoader(loader)
            .run();
}

Благодаря этой реализации я смог установить свой активный профиль с помощью «application.properties», который находится в КОРНЕВОМ каталоге моего встроенного JAR.