Generally, I specify Tomcat properties in the application.properties file of my Spring Boot application. Is there any way to change some of those properties (which can be changed) dynamically, in the runtime? May be, by hitting an endpoint?
If not, is there any other way to make them dynamic from within the application code (and not the properties file)?
There are some libraries that can be configured both from the application.properties and dynamically as well (using endpoints). Does Tomcat provide any such mechanism?
Yes, there is. You can configure and hit endpoints to reconfigure:
https://cloud.spring.io/spring-cloud-config/reference/html/
Related
How can I put into spring boot app properties logback-file.xml and logback-access.xml at the same time? And if I can, logs will write in one file, or in different?
See the available Spring Boot properties.
You will find generic logging.* ones as well as server.tomcat.accesslog.* OR server.jetty.accesslog.* depending on your embedded servlet container.
Core logs will be printed based on logback-spring.xml, and access-logs (logs written whenever someone accesses any of your API's) will be printed based on logback-access.xml.
In application.properties, use logging.* for core/server logs and server.(yourserver).accesslog.* for access logs.
I've been using an embedded neo4j server in my project so far.
Now I want to try out the new bolt protocol with a standalone server, however only for my deployed application. For convenience, I still want to use an embedded database when running from IDE (permanent) or when running tests (impermanent).
In order to support this, I've migrated from the java based configuration to the use of a ogm.properties file. Depending on the environment I run in, I want to use the file which configures the respective driver/database location.
I have placed a default configuration in the root of my resources folder. However I am not able to "override" this in other environment.
In order to do that I placed a different ogm.properties in the root folder of the deployed application. This doesn't seem to work. This the mechanism that I previously already used in order to have different application.properties and logback.xml configurations.
Is this not supported by neo4j-ogm? If not, how can one achieve this? It also isn't (trivially) possible with the java based configuration.
I am a bit confused, since this doesn't sound like such an unlikely requirement...
You can use Spring Profile for this to configure different properties for different environments and you can look here.
You can use application.properties (spring.profiles.active) to load a different profile or by using a runtime argument if you are using Spring boot with CommandLineRunner.
I am trying to have separate property files for prod and dev environment.
I have two property files application-prod.properties, application-dev.properties placed in classpath:/config
I added VM option -Dspring.profiles.active=dev
According to what I understand from the documentation and many other references on the web, on accessing Spring Environment as environment.getProperty("") the property in "application-dev.properties" should be loaded. However, I am getting null and as it seems the property files are not read by Spring.
I also tried defining both the files in #PropertySource. Doing this, the file defined second is picked up and the corresponding property is returned. Spring is not choosing the file based on the active profile.
Am I missing something?
I also came across a issue raised through some SO questions, but I am not sure if it refers to the same problem.
Right, so documentation you are pointing to is from Spring Boot project. That is not the same as Spring Framework. If you are not using Spring Boot, -Dspring.profiles.active=dev wouldn't work.
You have two options:
Introduce Spring Boot to your project ans turn on auto-configuration (#SpringBootApplication or #EnableAutoConfiguration).
Use plain Spring Framework features like PropertyPlaceholderConfigurer, but it doesn't give you same flexibility as Spring Boot features and you will need to create some boilerplate code to handle various envs.
I'd like to have a directory structure as so:
/Directory
- Application.jar
- application.properties
So that I can change properties without having to repackage and redeploy (and instead just restarting the jar). How can I accomplish this with spring annotations or configuration classes?
I'm not asking about making external resources available with my web application, I'm also looking to change the location from where spring loads the application.properties file.
You're mentioning jar, so you're using Spring Boot?
If so, external application.properties in the same directory (structure just like you described) will override application.properties packaged inside the jar file.
Then, if you have something like key=value in your application.properties, you can inject it in your code with #Value("${key}") String key.
Try it, it will just work :)
You may want to explore PropertyPlaceholderExplorer class in Spring. This class provides the facility to access the properties file external to your jar/war bundle. There is a short nice tutorial on this as well here.
If you start using Spring Boot (at some stage you for sure will). you get powerful configuration externalization features.
With Spring Boot your applications.properties are automatically loaded into Spring Boot context and you can use ${...} placeholders.
You can use even more modern feature #ConfigurationProperties to map you configuration to POJO. This POJO can even be validated by Java EE validation annotations (e.g. #NotNull)
I read #yorkw answer at this topic. He said:
The purpose of .properties file is to provide the capability of
configuring database connections at application runtime (for web
application, usually require restarting application container/server
after .properties file changes).
The question is if we can change properties on the fly without restarting container/server? Provide me an example please (I ask because in my demo it doesn't work, means value isn't changed).
I mean if we have some kind of admin tool than we can move all our configured settings to .properties files and change them via that admin tool.
Spring property files are designed to change the Spring Config of an application. The spring config is read when the spring container is initialised - this will form part of the application startup.
If a change is made to one of the spring config files (includes the *.properties files) the spring container would need to be reloaded to pick up the change.
Properties put into spring properties files should typically be properties that are tied to the life cycle of the application - i.e. the kind of properties that when changed require an application/spring container re-initialised - things like the database url/config etc.
So values that you want to change at runtime without requiring a restart of the application are not good candidates for placement in a spring properties file.