In both tagged version we can find an application.properties inside the package dataservices-server-app. This interferes with our own setup.
We would like to set default logging behaviour in our own library for our projects, but to do that we need to be able to include properties below the application.yml/properties order, so that we can decide from project to project if we use our default behaviour or not.
Because, the dataservices-server-app provides an application.properties file, this get listed directly below our own application.yml files, which we had to move to /config in order to make it override the application.properties.
Now, when we want to include properties via our library we would need to manually adjust the property loading order to get the interferring application.properties as low as possible - we don’t even need it.
Currently we are going to exclude dataservices-server-app and include anything inside dataservice-server-app to circumvent this file. Shading is also complicated and risky, and the existance of said file is also questionable, because there coudl’ve been a way to provide defaults via Beans or ConfgurationProptery annotated classes, which we could exclude.
One side effect currently is, that we get a logging file, if the name is specified even if we disable logging.file.enabled, because Spring Logging looks for a logging.file.name - which is specified in the application.properties, and the existance of a logback-xml - which we do not include through our library, because we set logging-file-enabled=false. But we cannot remove the property from the application.properties file of course.
Please remove the application.properties file from dataservices-server-app in your 2024 LTS version.
Hi @raiko-static-field , if you have multiple application.properties in you application, only one is chosen. There is a hierarchy of priorities - please see the Spring boor documentation. In your setup application.properties wins over yaml application properties .
I know but this does not fix the issue.
2025-12-17T11:15:31.249494880Z Property source contains: ConfigurationPropertySourcesPropertySource {name='configurationProperties'}
2025-12-17T11:15:31.249503044Z Property source contains: StubPropertySource {name='servletConfigInitParams'}
2025-12-17T11:15:31.249505176Z Property source contains: StubPropertySource {name='servletContextInitParams'}
2025-12-17T11:15:31.249506950Z Property source contains: PropertiesPropertySource {name='systemProperties'}
2025-12-17T11:15:31.249508602Z Property source contains: OriginAwareSystemEnvironmentPropertySource {name='systemEnvironment'}
2025-12-17T11:15:31.249510267Z Property source contains: RandomValuePropertySource {name='random'}
2025-12-17T11:15:31.249511906Z Property source contains: ApplicationInfoPropertySource {name='applicationInfo'}
2025-12-17T11:15:31.249513525Z Property source contains: CachedRandomPropertySource {name='cachedrandom'}
2025-12-17T11:15:31.249515222Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application-docker-development.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249517989Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application-development.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249527043Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249540066Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [application.properties]' via location 'optional:classpath:/''}
2025-12-17T11:15:31.249554078Z Property source contains: MapPropertySource {name='springCloudClientHostInfo'}
2025-12-17T11:15:31.249569920Z Property source contains: LogCorrelationPropertySource {name='logCorrelation'}
2025-12-17T11:15:31.249583464Z Property source contains: OriginTrackedMapPropertySource {name='logging-defaults'}
As visible, logging-defaults.yml comes from our library, as a lowest precedence (because intended default) and application.properties, coming from dataservices-server-app, is listed above it, because of its name. Thus it overwrites any property we try to control via our file.
To make our library default overwriting your library default is either rearranging property file order (which is very risky), excluding and including dependencies until we have it removed from classpath completely, or overwriting our intended default properties in all of our application.yml files. We could try shading which comes with other issues or we could alter the Spring Boot Config File Location property to exclude / files on classpath.
We need a better way to control these properties, so that we don’t end up with one of the mentioned solutions above.
Also, imagine any other library might do the same.
Placing an application.properties file on root level. Which wins? If they would be loaded both, which one would take higher precedence? As far as I can tell, this would be dependent on class loading order.
Additionally, because you use a *.properties file, any respective .yml file I place on the same spot in my application or any library will result in overriddes from the *.properties file because .properties take precedence over .yml → Externalized Configuration :: Spring Boot
It shouldn’t be there in the first place.
We need control over these properties, and default values which are irrelavant to our scenario, hard coded into a base file for any spring application, with few ways to handle, makes getting control over these harder than it should be.
if you place application.yaml there, it will be ignored in favor of application.properties on any level. If you would like to overwrite DS original defaults, you should place your properties to the /config/ directory.
We already do this, as previously mentioned.
I’m sorry I didn’t understood you properly. You mentioned logging-defaults.yml, but this shouldn’t interfere with anything in Data Services. There is no such a file. So what’s the exact problem? You have properties in confog/*.properties and it doesn’t apply?
We would like to set default logging behaviour in our own library for our projects, but to do that we need to be able to include properties below the application.yml/properties order, so that we can decide from project to project if we use our default behaviour or not.
Because, the dataservices-server-app provides an application.properties file, this get listed directly below our own application.yml files, which we had to move to /config in order to make it override the application.properties.
Now, when we want to include properties via our library we would need to manually adjust the property loading order to get the interferring application.properties as low as possible - we don’t even need it.
the referred order is
2025-12-17T11:15:31.249540066Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [application.properties]' via location 'optional:classpath:/''}
2025-12-17T11:15:31.249554078Z Property source contains: MapPropertySource {name='springCloudClientHostInfo'}
2025-12-17T11:15:31.249569920Z Property source contains: LogCorrelationPropertySource {name='logCorrelation'}
2025-12-17T11:15:31.249583464Z Property source contains: OriginTrackedMapPropertySource {name='logging-defaults'}
the exact property in question would be logging.file.name.
I cannot control this behaviour from my own lib, when using dataservices-server-app. I cannot use my logging-defaults.yml because of the loading order, because application.properties wins - as seen in the precedence order above and in the original post.
Maybe it helps if I describe the structure.
Our custom service includes the following maven dependencies via a pom.xml
<dependency>
<groupId>com.mgmtp.a12.dataservices</groupId>
<artifactId>dataservices-server-app</artifactId>
</dependency>
<dependency>
<groupId>custom.group</groupId>
<artifactId>custom-ib</artifactId>
</dependency>
Because it is a Spring Boot project application.yml/.properties - files are gathered from different spaces. We also use different application profiles, to handle different scenarios development and docker-development.
That is why we get the following 4 files
2025-12-17T11:15:31.249515222Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application-docker-development.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249517989Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application-development.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249527043Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [config/application.yml]' via location 'optional:classpath:/config/''}
2025-12-17T11:15:31.249540066Z Property source contains: OriginTrackedMapPropertySource {name='Config resource 'class path resource [application.properties]' via location 'optional:classpath:/''}
This is the output from inside a EnvironmentPostProcessor which lists the order of all sources.
Now we want to set the logging.file.name property. But because we have 20+ services we use a custom-lib, which includes different logic for logging and also sets the logging.file.name property via the inclusion of a logging-defaults.yml.
But because of the forementioned order the value from application.properties from dataservices-server-app will be picked first for logging.file name, because we add our logging-defaults.yml as lowest precedence. We do this, because we want to be able to override this property in our own application.yml and profile respective files.
We have few ways to circumvent this scenario.
- We exclude the application.properties from dataservices-server-app file via mvn dependency exclusions - possible, because of the content of the package - but extensive and hard to maintain
- We overwrite the interferring property in our application.yml - for each service, but that would defeat the purpose of our library.
- We rearrange the loading order from inside a new EnvironmentPostprocessor, for all affected service - that would be very risky.
So, what code exactly calls logging-defaults.yml? Because it’s nothing related to the Data Services application so it is not in collision with default properties. The application.properties from Data Services has lower priority than popertierties from the config directory, but regarding your logging-defaults.yml, it depends how do you load it.
Its added via an EnvironmentsPostProcessor
environment.getPropertySources().addLast(source);
Shouldn’t you call addFirst()? IMHO the first has the priority.
That would be even worse.
Then it isn’t just the default, it’ll overwrite any PropertySource which would provide the properties I add there, even application.yml, even environment variables as far as I can tell.
So, you must find the proper place in the list where to put it.
Well, it wouldn’t be a problem, if default properties of a library wouldn’t interfer in this specific way. But I get it, no change happening here.
We are trying to upgrade to 2025 and encountered this in process-engine-defaults.properties:
Actuator
Deprecated property is being used due to CIB 7 setting it.
management.endpoints.enabled-by-default=false
management.health.ldap.enabled=false
management.endpoints.web.exposure.exclude=*
We were wondering why all of our endpoints were gone.
Please provide a way to exclude this default behaviour.
Hi @raiko-static-field , please upgrade your properties. You can find more in Spring documentation.