We Keep Coding

How can I override configuration in logback-spring.xml with properties in Spring's own application.properties?

In my Spring Boot project, I initially set up the logging configuration in the application.properties, e.g.
logging.file=/foo/bar/app.log
logging.file.max-size=1M
logging.file.max-history=10
logging.file.level.root=DEBUG
logging.file.level.root.com.my.app=DEBUG
logging.file.level.org.springframework.boot.diagnostics=DEBUG
logging.file.level.org.springframework.security=DEBUG
Let's say I have other environment-specific properties files named following this pattern application-xxx.properties with xxx being the Spring profile name passed as argument when running the app (via -Dspring.profiles.active=xxx).
In these files, I can override the log levels, e.g. for an application-qa.properties
logging.file.level.root=INFO
logging.file.level.root.com.my.app=INFO
logging.file.level.org.springframework.boot.diagnostics=INFO
logging.file.level.org.springframework.security=INFO
I can also override these in the command line with the same mechanism as explained above (-D ).
Now, I'm asked to transfer all this configuration into a single logback-spring.xml. Using this new style of configuration, is there a way to still override each properties?
Found these resources while looking for an answer:
neither official Spring doc: https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.logging
nor this DZone article mention that: https://dzone.com/articles/configuring-logback-with-spring-boot
this article on CodeJava: https://www.codejava.net/frameworks/spring-boot/logback-rolling-files-example even says it works the other way round: The configuration in XML file will override the logging properties in the application.properties file. !!!

Java Microprofile change properties on already deployed app (Wildfly)

I have an ear artifact deployed on a wildfly server. On some beans I used the following configuration injection
#Inject
private Config config;
I want to change the properties specified on the "microprofile-config.properties" file on runtime. It is not necessary to change the file itself, I just want to change the properties. I think there might be a way using the console, but I cannot find if there is any.

If you take a look at the spec or even at articles like this, you will see that, by default, Microprofile config reads configuration values from the following 3 places in this order - i.e. from wherever it finds it first:
System.getProperties()
System.getenv()
The configuration file
So, you can override values in the configuration file in 2 ways:
Defining -D command line arguments to the VM (e.g. java -DXXX=yyy ...)
Defining system environment variables (e.g. export XXX=yyy in bash or set XXX=yyy in Windows)
Note that there are some rules for defining environment variables and matching them to actual configurations, e.g. for a configuration aaa.bbb.ccc you may need to set an environment variable as AAA_BBB_CCC. Read ch. 5.3.1 in the specs, and experiment a little.
You can always extend the configuration sources with your own custom ones (to read configuration from JNDI, DB, Zookeeper, whatever).

Multiple profiled properties configuration in Spring-boot 2

I have a spring-boot 2.1.3.RELEASE application with multiple properties files.
In my /src/main/resources I have my-app.properties and profiled my-app-local.properties.
Also, outside the project I have another profiled properties file /config/my-app-local.properties.
The point of this configuration is to have the following properties hierarchy:
/resources/my-app.properties
/resources/my-app-local.properties
/config/my-app-local.properties
So when I try to run the application with the following parameters:
--spring.profiles.active=local --spring.config.name=my-app --spring.config.location=config/my-app.properties
the application fails to start because it can't find any properties files.
However, this configuration and parameters worked perfectly on spring-boot 1.5.19.RELEASE. How can the same be achieved in spring-boot 2?

use spring.config.additional-location doc
When custom config locations are configured by using spring.config.location, they replace the default locations. For example, if spring.config.location is configured with the value classpath:/custom-config/,file:./custom-config/, the search order becomes the following:
file:./custom-config/
classpath:custom-config/
Alternatively, when custom config locations are configured by using spring.config.additional-location, they are used in addition to the default locations. Additional locations are searched before the default locations. For example, if additional locations of classpath:/custom-config/,file:./custom-config/ are configured, the search order becomes the following:
file:./custom-config/
classpath:custom-config/
file:./config/
file:./
classpath:/config/
classpath:/

Spring Boot refuses to pick up application test properties [duplicate]

I have a spring boot application that I can package in a war that I want to deploy to different environments. To automate this deployment it'd be easier to have the configuration file externalized.
Currently everything works fine with a application.properties file in src/main/resources. Then I use ´mvn install´ to build a war deployable to tomcat.
But I would like to use a .yml file that does not need to be present on mvn install but that would be read from during deployment of the war and is in the same or a directory relative to my war.
24. externalized configuration shows where spring boot will look for files and 72.3 Change the location of external properties of an application gives more detail on how to configure this but I just do not understand how to translate this to my code.
My application class looks like this:
package be.ugent.lca;
Updated below
Do I need to add a #PropertySource to this file? How would I refer to a certain relative path?
I feel like it's probably documented in there as most spring boot documentation but I just don't understand how they mean me to do this.
EDIT
Not sure if this should be a separate issue but I think it's still related.
Upon setting the os variable the error of yaml file not found went away. Yet I still get the same error again as when I had no application .properties or .yml file.
Application now looks like this:
#Configuration
**#PropertySource("file:${application_home}/application.yml")**
#ComponentScan({"be.ugent.lca","be.ugent.sherpa.configuration"})
#EnableAutoConfiguration
#EnableSpringDataWebSupport
public class Application extends SpringBootServletInitializer{
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
The application_home OS variable
$ echo $application_home
C:\Masterproef\clones\la15-lca-web\rest-service\target
My application.yml file(part it complains about):
sherpa:
package:
base: be.ugent.lca
Error upon java -jar *.war
All variations upon:
Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder 'sherpa.package.base' in string value "${sherpa.package.base}"
at org.springframework.util.PropertyPlaceholderHelper.parseStringValue(PropertyPlaceholderHelper.java:174)
at org.springframework.util.PropertyPlaceholderHelper.replacePlaceholders(PropertyPlaceholderHelper.java:126)
at org.springframework.core.env.AbstractPropertyResolver.doResolvePlaceholders(AbstractPropertyResolver.java:204)
at org.springframework.core.env.AbstractPropertyResolver.resolveRequiredPlaceholders(AbstractPropertyResolver.java:178)
at org.springframework.context.support.PropertySourcesPlaceholderConfigurer$2.resolveStringValue(PropertySourcesPlaceholderConfigurer.java:172)
at org.springframework.beans.factory.support.AbstractBeanFactory.resolveEmbeddedValue(AbstractBeanFactory.java:808)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:1027)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:1014)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:545)
... 142 more

Using external properties files
The answer lies in the Spring Boot Docs, I'll try to break it down for you.
First of all, no you should not use #PropertySource when working with Yaml configuration, as mentioned here under the Yaml shortcomings :
YAML files can’t be loaded via the #PropertySource annotation. So in the case that you need to load values that way, you need to use a properties file.
So, how to load propery files? That is explained here Application Property Files
One is loaded for you: application.yml , place it in one of the directories as mentioned in the link above. This is great for your general configuration.
Now for your environment specific configuration (and stuff like passwords) you want to use external property files, how to do that is also explained in that section :
If you don’t like application.properties as the configuration file name you can switch to another by specifying a spring.config.name environment property. You can also refer to an explicit location using the spring.config.location environment property (comma-separated list of directory locations, or file paths).
So you use the spring.config.location environment property.
Imagine you have an external config file: application-external.yml in the conf/ dir under your home directory, just add it like this:
-Dspring.config.location=file:${home}/conf/application-external.yml as a startup parameter of your JVM.
If you have multiple files, just seperate them with a comma. Note that you can easily use external properties like this to overwrite properties, not just add them.
I would advice to test this by getting your application to work with just your internal application.yml file , and then overwrite a (test) property in your external properties file and log the value of it somewhere.
Bind Yaml properties to objects
When working with Yaml properties I usually load them with #ConfigurationProperties, which is great when working with for example lists or a more complex property structure. (Which is why you should use Yaml properties, for straightforward properties you are maybe better of using regular property files). Read this for more information: Type-Safe Configuration properties
Extra: loading these properties in IntelliJ, Maven and JUnit tests
Sometimes you want to load these properties in your maven builds or when performing tests. Or just for local development with your IDE
If you use IntelliJ for development you can easily add this by adding it to your Tomcat Run Configuration : "Run" -> "Edit Configurations" , select your run configuration under "Tomcat Server" , check the Server tab and add it under "VM Options".
To use external configuration files in your Maven build : configure the maven surefire plugin like this in your pom.xml:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>-Dspring.config.location=file:${home}/conf/application-external.yml</argLine>
</configuration>
</plugin>
When running JUnit tests in IntelliJ:
Run → Edit Configurations
Defaults → JUnit
add VM Options -> -ea -Dspring.config.location=file:${home}/conf/application-external.yml

Yes, you need to use #PropertySource as shown below.
The important point here is that you need to provide the application_home property (or choose any other name) as OS environment variable or System property or you can pass as a command line argument while launching Spring boot. This property tells where the configuration file (.properties or .yaml) is exactly located (example: /usr/local/my_project/ etc..)
#Configuration
#PropertySource("file:${application_home}config.properties")//or specify yaml file
#ComponentScan({"be.ugent.lca","be.ugent.sherpa.configuration"})
#EnableAutoConfiguration
#EnableSpringDataWebSupport
public class Application extends SpringBootServletInitializer{
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}

There is a very simple way to achieve this.
Inside your original application.properties file you can just specify the following line:
spring.config.import=file:Directory_To_The_File/Property_Name.properties
It will automatically sync all the properties from the external property file.
Now lets say that you have a situation where you need to get properties from multiple property files. In that case, you can mention the same line in the external property file which in turn will take the remaining properties from the second property file and so on.
Consider the following example.
application.properties:
spring.config.import=file:Resources/Custom1.properties
Custom1.properties:
server.port=8090
.
.
.
spring.config.import=file:Resources/Custom2.properties

One of the easiest way to use externalized property file using system environment variable is, in application.properties file you can use following syntax:
spring.datasource.url = ${OPENSHIFT_MYSQL_DB_HOST}:${OPENSHIFT_MYSQL_DB_PORT}/"nameofDB"
spring.datasource.username = ${OPENSHIFT_MYSQL_DB_USERNAME}
spring.datasource.password = ${OPENSHIFT_MYSQL_DB_PORT}
Now, declare above used environment variables,
export OPENSHIFT_MYSQL_DB_HOST="jdbc:mysql://localhost"
export OPENSHIFT_MYSQL_DB_PORT="3306"
export OPENSHIFT_MYSQL_DB_USERNAME="root"
export OPENSHIFT_MYSQL_DB_PASSWORD="123asd"
This way you can use different value for same variable in different environments.

Use below code in your boot class:
#PropertySource({"classpath:omnicell-health.properties"})
use below code in your controller:
#Autowired
private Environment env;

Spring properties file set null to property

Currently I have a few property files in my src/main/resources folder:
- application.properties
- application-dev.properties
- application-test.properties
Now, when I specify a profile, it loads both that profile's specific file and the general application.properties, overwriting everything with the former.
However, when my application is deployed in production, no profile is passed, so application.properties must be my production file.
That's fine because I can overwrite everything in the profile specific ones. There is one problem, however; on production, I now need to set:
spring.datasource.jndi-name=jdbc/appname
When I add that to application.properties, every profile also inherits that, and then, when I run dev server or a test, it gives me this error:
Caused by: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial
Because I indeed don't use this JNDI stuff on my own environments; I use the following properties:
spring.datasource.url=jdbc:url
spring.datasource.username=user
spring.datasource.password=pass
My problem is: I cannot overwrite this property for my life. If I add any of these on the env specific files, it will be ignored and the error persists:
spring.datasource.jndi-name= # empty string, does nothing
spring.datasource.jndi-name=<null> # read somewhere it meant null, doesn't work
spring.datasource.jndi-name=${inexistentProp} # I though it might return null, but gives an error
So, what can I do? I think of several solutions:
A way to set a property value as proper null or undefined in a spring property file (since empty doesn't do the trick)
A way to change the commonly inherited property file to something else (I tried #PropertySource, but it only add more options, always falling back to application.properties eventually)
Disable JNDI altogether via properties file, despite the former property (I tried spring.jndi.ignore=true as per here, but to no avail)
But either I don't know how or they don't work.

Spring Boot documentation, 24.4 Profile-specific Properties:
In addition to application.properties files, profile-specific properties can also be defined by using the following naming convention: application-{profile}.properties. The Environment has a set of default profiles (by default, [default]) that are used if no active profiles are set. In other words, if no profiles are explicitly activated, then properties from application-default.properties are loaded.
25.1 Adding Active Profiles:
The spring.profiles.include property can be used to unconditionally add active profiles.
So, create a application-default.properties file with the following property:
spring.profiles.include=prod
Now move the spring.datasource.jndi-name=jdbc/appname property from the application.properties file to the application-prod.properties file.
When you run code with a specific profile, the prod profile will not be used, and spring.datasource.jndi-name will be undefined.
When you run code in production, where no profile is specified, the prod profile is included by default, and spring.datasource.jndi-name will be defined.
You can of course just put the production properties in the application-default.properties itself, but the above approach makes it more clear what you're doing.
It also makes it easier if you end up with multiple profiles. E.g. you have prod vs dev vs test. But what if you have independent set of profiles such as foo vs bar, and that default production environment should be prod,foo? Allowing alternate production environment to use prod,bar, and each can be tested separately (test,foo and test,bar).
By using the default profile to only include other profiles, without otherwise define any properties, you can now manually mix and match profiles, as needed.