While scouting the documentation we found the following properties that we want to set.
max-source-rows-allowed
exception-on-max-source-rows
Found on the following page:
https://teiid.github.io/teiid-documents/16.0.x/content/admin/Other_Considerations.html
However, we have tried several ways to set these without avail. The properties are not listed on the following page.
https://github.com/teiid/teiid-spring-boot/blob/master/docs/Reference.adoc
How can we set these properties?
Teiid spring boot does not currently allow setting properties like these, which are normally set in the Teiid WildFly subsystem, in an elegant way. The only workaround is to wire in your own EmbeddedConfiguration with all the appropriate settings - as the TeiidAutoConfiguration logic won't make any additional changes to a supplied configuration.
You can also log an issue / supply a patch to have this properties set from the configuration file.
Related
It seems that Spring is not reading the customized keys for sanitizing the values.(it is only referring to default ones)
I have added below properties in application.properties file
endpoints.env.id=env
endpoints.env.sensitive=true
endpoints.env.enabled=true
endpoints.env.keys-to-sanitize=port
After starting the app and navigating to /env endpoint I am getting below response
"endpoints.env.keys-to-sanitize":{"value":"port","origin":"URL
[file:./application.properties]:40:32"},"endpoints.env.sensitive":{"value":"true","origin":"URL
[file:./application.properties]:41:25"},"endpoints.env.enabled":{"value":"true","origin":"URL
[file:./application.properties]:42:23"},"password":{"value":"******","origin":"URL
[file:./application.properties]:43:10"} ,
"management.port":{"value":"8081","origin":"URL [file:./application.properties]:36:17"}
Notice that port are still visible and the password is masked with ****.
Am I missing something. My requirement is to add few more keys to hide their values.
If you are using Spring Boot version 2 and above, the properties have changed.
You can follow the Actuator Migration Guide for more details.
I am setup to use logback with my SpringBoot application and everything is running fine and dandy.
I noticed a property called logging.path in the application.properties file which sets the value for ${LOG_PATH} in logback.xml. How does it do it?
I went through the SpringBoot logging documentation.
Any documentation I could find on property placeholder configurer
Yet I don't understand how logging.path could pass the value for ${LOG_PATH}. Though not a killer issue, I would like to know how this mapping is made.
The magic is spring will transfter logging.path into System propeties LOG_PATH.
Description from spring doc:
To help with the customization some other properties are transferred from the Spring Environment to System properties:
And it also says:
All the logging systems supported can consult System properties when parsing their configuration files. See the default configurations in spring-boot.jar for examples.
Details:
https://docs.spring.io/spring-boot/docs/1.5.6.RELEASE/reference/htmlsingle/#boot-features-custom-log-configuration
For more recent versions of Spring Boot, such as 2.5.x, the logging.file.path maps to LOG_PATH.
I currently have the following config setup in spring boot:
application.properties
app.database.host=${DB_HOST}
app.database.port=${DB_PORT}
app.database.name=${DB_NAME}
app.database.user=${DB_USER}
app.database.password=${DB_PASSWORD}
app.database.schema=${DB_SCHEMA:public}
spring.datasource.url=jdbc:postgresql://${app.database.host}:${app.database.port}/${app.database.name}
spring.datasource.username=${app.database.user}
spring.datasource.password=${app.database.password}
spring.datasource.driver-class-name=org.postgresql.Driver
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect
application-local-dev.properties:
app.database.host=${DB_HOST:localhost}
app.database.port=${DB_PORT:5432}
app.database.name=${DB_NAME:db_name}
app.database.user=${DB_USER:root}
app.database.password=${DB_PASSWORD:root}
app.database.schema=${DB_SCHEMA:public}
application-load-fixtures.properties:
spring.profiles.include=local-dev
spring.profiles.active=load-fixtures,local-dev
app.database.name=${DB_NAME:db_name}_fixtures
The idea here is that when starting the app in default mode, it will fail to boot when critical properties like database name are missing.
They should be passed via environment variables.
For development purposes, this is unnecessary overhead when setting up the project because we have a docker container with static credentials and I'd like to provide them as defaults. Therefore, I created a profile local-dev that will use default values to be able to connect to our docker database and still have the ability to override them via environment variables in case someone needs to.
Until here, everything works fine.
But now, we also have a profile that is used to load fixtures into the database (drop all tables, recreate and fill them with data).
For obvious reasons, I want to ensure that this cannot be done on an arbitrary database, so I created a profile load-fixtures that should inherit all properties from local-dev and override the database name. However, this approach seems to be wrong. I can see in the spring log that the profiles are loaded properly:
2017-11-16 13:32:11.508 INFO 23943 --- [ main] Main:
The following profiles are active: load-fixtures,local-dev
But it still uses the database name provided by the local-dev profile.
When I remove the line
app.database.name=${DB_NAME:db_name}
from the local-dev config file, it works.
However, what I want to avoid is having to add new properties to both, local-dev and load-fixtures, whenever we add a new configuration property to the project.
I understand that profile specific properties take precedence over non-profile specific ones. And also that non-default location properties take precedence over properties from the default locations. But here, both profiles (local-dev and load-fixtures) are in the same location, and they are also both profile specific.
What are proper ways to go about this problem?
Thanks in advance!
I recently came across quite the same problem and had to figure out which precedence Spring applies to several profile specific property files. Unfortunately this is not well documented and I did not find the location of the code that is responsible for that.
However after some tests and tries I'm pretty sure it works like this (or at least in a similar way):
Probably some kind of map is used to gather up all properties of all the different places and possibilites where you could define them like documented here. So for example a property my.value is defined in application.properties and so stored in the mentioned map. Then the same property is found as Java system property. Since this way of defining a property is higher in the PropertySource-order it will override the value found before in the map. Until here it is clear according to the documentation that the Java system property will win.
But as we come to two different sources on the same precedence level like two different profile specific property files the documentation is not a 100% clear in my opinion. However it says in 24.4:
If several profiles are specified, a last-wins strategy applies. For example, profiles specified by the spring.profiles.active property are added after those configured through the SpringApplication API and therefore take precedence.
Maybe it is just the example that is not optimal here or I just do not understand it correctly. But I guess the "last-wins" strategy also applies to all profiles defined for example in spring.profiles.active. That means if you run java -jar -Dspring.profiles.active=dev,fix application.jar, the properties in application-fix.properties will overwrite the values of properties having the same key in application-dev.properties.
So in your case considering the output of your application I guess you specified something like java -jar -Dspring.profiles.active=load-fixtures,local-dev application.jar. If I was correct, you would just have to change that into java -jar -Dspring.profiles.active=local-dev,load-fixtures application.jar.
I have a Spring Boot property source file containing a set of arbitrary properties. I would like to get all of those properties and add them to the environment.
I tried injecting the Environment into the class, and I am able to use that to get known properties. But I am not sure how to get all properties from there.'
If course I can use a traditional Properties.load() but is there a Spring way to do that?
Have you tried #PropertySource anotation?
I wouldn't recommend using PropertySource because you can't configure the precedence of the properties that you add. You may want that these properties can be overridden in some way, maybe? Or you may want that these properties take precedence over others. For this, I recommend you implement an EnvironmentPostProcessor.
There is a sample in this university session at Devoxx where we showcase how to read a file from the home directory and add it after command line properties. You could do pretty much the same thing and order them the way you want.
The sample app is available here if you want to give that a try.
If you put your properties into the "application.properties" (or any of the other places described here), the properties are automatically available in Spring's Environment.
One way to access the properties then is simply to #Autowire the Environment into the class where you want to access it.
I'm using Spring 2.5.6. I have a bean whose properties are being assign from a property file via a PropertyPlaceholderConfigurer. I'm wondering whether its possible to have the property of the bean updated when the property file is modified. There would be for example some periodic process which checks the last modified date of the property file, and if it has changed, reload the bean.
I'm wondering if there is already something that satisfies my requirements. If not, what would be the best approach to solving this problem?
Thanks for your help.
Might also look into useing Spring's PropertyOverrideConfigurer. Could re-read the properties and re-apply it in some polling/schedular bean.
It does depend on how the actual configured beans use these properties. They might, for example, indirectly cache them somewhere themself.
If you want dynamic properties at runtime, perhaps another way to do it is JMX.
One way to do this is to embed a groovy console in your application. Here's some instructions. They were very simple to do, btw - took me very little time even though I'm not that familiar with groovy.
Once you do that you can simply go into the console and change values inside the live application on the fly.
You might try to use a custom scope for the bean that recreates beans on changes of the properties file. See my more extensive answer here.
Spring Cloud Config has facilities to change configuration properties at runtime via the Spring Cloud Bus and using a Cloud Config Server. The configuration or .properties or .yml files are "externalized" from the Spring app and instead retrieved from a Spring Cloud Config Server that the app connects to on startup. That Cloud Config Server retrieves the appropriate configuration .properties or .yml files from a GIT repo (there are other storage solutions, but GIT is the most common). You can then change configuration at runtime by changing the contents of the GIT repo's configuration files--The Cloud Config Server broadcasts the changes to any Client Spring applications via the Spring Cloud Bus, and those applications' configuration is updated without needing a restart of the app. You can find a working simple example here: https://github.com/ldojo/spring-cloud-config-examples