I have a third party library, that is being configured with the important-config.yaml file.
prop1: value1
prop2: value2(need to override)
prop3: value3
To refer to it I have the next line in application.properties:
important-config=classpath:important-config.yaml
There is a property in yaml-file that depends on environment where app is running. So I need to override this property on startup. How can I do that?
I can see three suitable variants to solve it:
Override properties directly in application.properties. I think that priority of is is higher that included congig (at least you could try to override property after you place important-config).
You can override selected properties using command line directly java -jar app.jar --prop2="value2"
Or override via system properties java -Dprop2="value2"-jar app.jar
Full informaiton you can find here http://www.baeldung.com/properties-with-spring
Absolute all properties are stored in Spring Environment object. You should pay attention on full variable name, because depending on other setting your prop2 could be store in xxx.yyy.prop2.
Related
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).
I want to enable Spring Context Indexer on a project but I am having issues with Swagger3 (check here and here).
I understand the limitations and would like to enable it, at least, at the DEV profile where we do not need Swagger running.
My goal is to disable indexing on PROD environment. From docs:
you can fallback to a regular classpath arrangement (as though no index was present at all) by setting spring.index.ignore to true, either as a system property or in a spring.properties file at the root of the classpath.
My first approach (without success) was setting an env var (Windows 10) with the following:
SPRING_APPLICATION_JSON={"spring":{"index":{"ignore":true}}}
If I create a spring.properties file and set the value accordingly it works. But I can't figure how to use different properties for each profile, I imagined it was something like the application.properties file but I was wrong.
How can I achieve that?
EDIT:
Just to be clear, this config (spring.index.ignore) will just work if inside a spring.properties file, not an application.properties one. (Just double-checked before this edit)
Actually I have one application-prod.properties and one application-dev.properties.
I don't know the difference between spring.properties and application.properties but the first one doesn't seem to work with multiple profiles as the later.
Edit 2:
Just went through org.springframework.context.index.CandidateComponentsIndexLoader and it uses SpringProperties.getFlag(IGNORE_INDEX) to read the value.
SpringProperties class is clear about the file it uses:
Reads a spring.properties file from the root of the Spring library classpath, and also allows for programmatically setting properties through setProperty. When checking a property, local entries are being checked first, then falling back to JVM-level system properties through a System.getProperty check.
I think I will need to pass a property to Java runner during initialization. Will research a little bit more about it.
you can use different application.properties file as follow:
add the following files to the resource folder:
application.properties
spring.profiles.active=dev #place profile name you want to use
application-dev.properties
#dev properties
...
You can create many application-env.properties you may wish
application-env.properties
#env properties
...
Spring Boot supports profile-specific properties files. You have to name these files with the following format: application-{profile}.properties. You can activate a profile via JVM system parameter: -Dspring.profiles.active=dev. You can read more about this subject here: https://www.baeldung.com/spring-profiles
When defining a property in application.properties such as
deployment=dev
spring.profiles.active=${deployment}
Spring is unable to resolve the deployment property correctly.
Main : The following profiles are active: ${deployment}
Instead, I have to specify a default in each instance of the variable, such as
deployment=dev
spring.profiles.active=${deployment:dev}
However, when I override the property through one of the various ways (environment variable, system property, etc), the set value is correctly resolved everywhere. Is there a way to define a default in the application.properties file?
Here is what you can do:
create an application.properties file that contains the default settings.
Then create an applicaiton-ENV.properties file that contains any addition or overloaded values for the ENV (in your example the ENV would be dev)
Then at runtime set the environment variable spring.profiles.active=dev
java .... -Dspring.profiles.active=dev YourSpring.jar
This will cause spring boot to run with the profile you want, and will read in the default, and the additional -dev file.
This allows you to set up multiple different application properties for unlimited number of environements. If you set no spring.profiles.active environment variable, it will run simply loading the default application.properties file.
${GROUP_ID:123456}
You can indicate what default to be given as part of the property in the above way:
I would like to override the library properties that I've written in project that is using it. I'm using this Spring guide on creating library: https://spring.io/guides/gs/multi-module/
I would like to know how to override for example my.properties file in the project that uses my library.
Is it even possible?
Do not add application.properties files to a library. It could cause a myriad of problems. If you want to set a default property do it like this:
#ConfigurationProperties("foo")
public class FooConfig {
private int bar = 999;
// getter / setter
}
Every application should configure the library values for itself in its own application.properties file.
Seems you cannot. Since Spring itself also cannot
In the sample above we have configured the service.message for the test using the default attribute of the #SpringBootTest annotation. It is not advisable to put application.properties in a library because there might be a clash at runtime in the application that uses it (only one application.properties is ever loaded from the classpath). You could put application.properties in the test classpath, but not include it in the jar, for instance by placing it in src/test/resources.
Spring Boot property order precedence is described here:
https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html
From the link:
Spring Boot uses a very particular PropertySource order that is designed to allow sensible overriding of values. Properties are considered in the following order:
The order is 1-17 then. For example, 4 on the list (command-line arguments) overrides 15 on the list (your application.properties file) and so on.
Depends on how the library property file specifies properties. If the properties are looked up from environment/system first, then you can override in your code. If hard-coded, then not.
For example:
prop=${ENV_VAR:abc}
You can set ENV_VAR environment variable, or env-var system variable in your code to override the value of prop. If you don’t, the default value abc will be used.
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.