Реализуйте приоритет источника свойств в клиенте Spring Cloud Config Server

Question

Мне нужно реализовать клиентский код в Java для использования сервера конфигурации Spring Cloud.Клиентская сторона не является ни весенним приложением, ни веб-службой.

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

application.properties (lowest)
specificApp.properties
application-dev.properties
specificApp-dev.properties (highest)

Однако, когда я вызываю службу с http://localhost:8888/specifcApp/dev,, источники свойств возвращаются в противоположном направлении.порядок из вышеперечисленного:

0: specificApp-dev.properties
1: application-dev.properties
2: specificApp.properties
3: application.properties

Я не уверен, но я полагаю, что намерение состоит в том, что возвращаемый порядок указывает приоритет от самого низкого до самого высокого (последний выигрывает).Если это так, то это означает, что application.properties имеет приоритет над остальными.Это противоположно тому, что я ожидал.

Мне еще предстоит найти пружинную документацию, которая бы полностью охватывала все это в одном месте.Вокруг разбросана запутанная информация.Но в этом документе говорится: «... специфичные для профиля файлы всегда [переопределяют] неспецифичные, независимо от того, находятся ли специфичные для профиля файлы внутри или за пределами вашего упакованного jar.

Каковы действительные правила приоритета и каков порядок источников свойств в ответе?

Вторая часть вопроса состоит в том, как я могу перебирать источники свойств configService в ЛЮБОМorder?

Я нашел пример кода ниже. Однако проблема в том, что CompositePropertySource.getPropertySources () возвращает коллекцию. Другими словами, нет способа получить упорядоченный список из CompositePropertySource. (Источникихранится внутри в CompositePropertySource в наборе.)

        final CompositePropertySource compositePropertySource 
            = (CompositePropertySource)environment.getPropertySources().get("configService");

        if (compositePropertySource != null && compositePropertySource.getPropertySources() != null) {

            // compositePropertySource.getPropertySources() is not ordered!
            for (final Object mapPropertySourceObject : compositePropertySource.getPropertySources()) {
                final MapPropertySource propertySource = (MapPropertySource)mapPropertySourceObject;

                if (propertySource != null) {
                    p.putAll(propertySource.getSource());
                    LOG.info("fetched remote properties");
                }
            }
        }

Подводя итог:

1. Каким должно быть правило приоритета?
2. Что такое порядокв ответе сервера Json raw указываются источники свойств?
3. Как получить доступ к фактическому порядку источников свойств, которыесоздать источник составного свойства configService?

Я использую Spring Boot 1.5.14.RELEASE и Spring Cloud Edgware.SR4.

Редактировать : я вижутеперь, когда набор свойств CompositePropertySource имеет тип LinkedHashSet, у него есть порядок.И CompositePropertySource.getPropertyNames (), ясно, что свойства из источников свойств позже в списке будут переопределять те, что ранее в списке.Если это так, то application.properties имеет приоритет над конфигурациями приложения или профиля.Я не понимаю, как это может быть ожидаемым поведением.Это означает, что ни одно свойство не может быть переопределено, в действительности.

Edit # 2 : я проверяю это с помощью репозитория Git.Все четыре файла находятся в одной папке в репо.

Редактировать # 3 : я понял, что некоторые свойства влияют на это.Когда я отправлял это, я должен был указать, что запускаю клиент с параметрами JVM: -Dspring.profiles.active = dev -Dspring.profiles.default = dev и -Dspring.cloud.config.profile = dev.Я также попробовал это только с -Dspring.cloud.config.profile = dev.

Обновление : я ближе к решению.

Я попробовал следующее:

1. Переименуйте application.properties в application-default.properties.
2. Переименуйте specificApp.properties в specificApp-default.properties.
3. Затем я запустил с -Dspring.profiles.active = dev, по умолчанию.У меня не было свойства -Dspring.profiles.default и -Dspring.cloud.config.profile.

В этом случае они были возвращены в следующем порядке:

specificApp-default.properties
application-default.properties
specificApp-dev.properties
application-dev.properties

Это все еще не то, что я ожидал.Это означает, что общие свойства приложения будут переопределять (т.е. иметь приоритет над) специфичные для приложения свойства.Я ожидал бы следующий заказ, но я все ближе к решению, я думаю:

application-default.properties
specificApp-default.properties
application-dev.properties
specificApp-dev.properties

или даже этот заказ:

application-default.properties
application-dev.properties
specificApp-default.properties
specificApp-dev.properties