|
50 | 50 | * care to override profile-based collections and maps. |
51 | 51 | * |
52 | 52 | * We can't use the same functionality of loading yaml files that spring-boot does : |
53 | | - * {@link org.springframework.boot.env.YamlPropertySourceLoader} and thus OriginTrackedYamlLoader, |
54 | | - * because spring-boot loads every single yaml document (all in a file) into a separate PropertySource. |
55 | | - * So each yaml document ends up in a separate PropertySource. We, on the other hand, have to load all yaml documents |
56 | | - * into a single Properties file, that ends up being a single PropertySource. |
57 | | - * This happens because we first have to read configmaps / secrets |
58 | | - * and only at that point do we know if a yaml contains more than one document. |
| 53 | + * {@link org.springframework.boot.env.YamlPropertySourceLoader} and thus |
| 54 | + * OriginTrackedYamlLoader, because spring-boot loads every single yaml document (all in a |
| 55 | + * file) into a separate PropertySource. So each yaml document ends up in a separate |
| 56 | + * PropertySource. We, on the other hand, have to load all yaml documents into a single |
| 57 | + * Properties file, that ends up being a single PropertySource. This happens because we |
| 58 | + * first have to read configmaps / secrets and only at that point do we know if a yaml |
| 59 | + * contains more than one document. |
59 | 60 | * |
60 | | - * As such, we mimic the same things that spring-boot achieves by creating our own yaml reader, that is neavily based |
61 | | - * on the YamlPropertiesFactoryBean. |
| 61 | + * As such, we mimic the same things that spring-boot achieves by creating our own yaml |
| 62 | + * reader, that is neavily based on the YamlPropertiesFactoryBean. |
62 | 63 | * |
63 | 64 | * This is how it does things: |
64 | 65 | * |
65 | 66 | * <ul> |
66 | | - * <li>read all the documents in a yaml file</li> |
67 | | - * <li>flatten all properties besides collection and maps, |
68 | | - * YamlPropertiesFactoryBean does not do that and starts flattening everything</li> |
69 | | - * <li>take only those that match the document matchers</li> |
70 | | - * <li>split them in two : those that have profile activation and those that don't</li> |
71 | | - * <li>override properties in the non-profile based yamls with the ones from profile based ones. |
72 | | - * This achieves the same result as a plain spring-boot app, where profile based properties have a higher |
73 | | - * precedence.</li> |
74 | | - * <li>once the overriding happened, we do another flattening, this time including collection and maps</li> |
| 67 | + * <li>read all the documents in a yaml file</li> |
| 68 | + * <li>flatten all properties besides collection and maps, YamlPropertiesFactoryBean does |
| 69 | + * not do that and starts flattening everything</li> |
| 70 | + * <li>take only those that match the document matchers</li> |
| 71 | + * <li>split them in two : those that have profile activation and those that don't</li> |
| 72 | + * <li>override properties in the non-profile based yamls with the ones from profile based |
| 73 | + * ones. This achieves the same result as a plain spring-boot app, where profile based |
| 74 | + * properties have a higher precedence.</li> |
| 75 | + * <li>once the overriding happened, we do another flattening, this time including |
| 76 | + * collection and maps</li> |
75 | 77 | * </ul> |
76 | 78 | * |
77 | 79 | * @author wind57 |
78 | 80 | */ |
79 | 81 | final class ProfileActivationAwareYamlPropertiesFactoryBean { |
80 | 82 |
|
81 | | - private static final LogAccessor LOG = new LogAccessor(LogFactory.getLog(ProfileActivationAwareYamlPropertiesFactoryBean.class)); |
| 83 | + private static final LogAccessor LOG = new LogAccessor( |
| 84 | + LogFactory.getLog(ProfileActivationAwareYamlPropertiesFactoryBean.class)); |
82 | 85 |
|
83 | 86 | private List<DocumentMatcher> documentMatchers = Collections.emptyList(); |
84 | 87 |
|
|
0 commit comments