One of my favorite spring-boot feature is the ability to configure most things using the unix environment variables.
Now I'm struggling with ActiveMQ broker config.
To set the broker url I have to specify spring.activemq.broker-url.
Rewritten in envrionment terms this would be SPRING_ACTIVEMQ_BROKER-URL which is working from eclipse, but not possible to be defined as environment variable in any unix shell.
using env is due to other restrictions not an option
Is there something I missed or do I have to remap those "dashed" properties in an own #PropertiesConfiguration
Any hints ?
Take a look at the documentation on relaxed binding.
The key in your application.properties or application.yml file will be spring.activemq.broker-url and your env var will be SPRING_ACTIVEMQ_BROKER_URL.
Related
Currently spring boot seems to support only classpath based logging configuration.
It also ignores any configuration passed as vm argument as follows.
-Dlog4j.configurationFile=/opt/xyz/log4j2-prod.xml
How can we have different log4j2 configuration based on different environment, considering classpath for all environment remains same.
What about set the properties: logging.config=classpath:log4j2-dev-spring.xml in each application-{profile}.properties that you have. Can use like this too: logging.config=${ENV_VAR}
You should use the following param
-Dlogging.config='/path/to/log4j2.xml'
I have a tomcat server with several applications. Then, I gonna deploy spring boot application on tomcat. But before deploy I set an environment variable in my server. Because of This application should use the environment variable. So I wish not to restart my tomcat after set new environment variable in my server.
Have you any solution? Help me, please?
You cannot change environment variables from Java without resorting to dirty tricks.
You can, however, change the values of system properties. Consider using system properties instead of environment variables to adjust the behavior of your application.
Better yet, don't use globally-visible/mutatable configuration and instead configure components individually through some other mechanism, such as a configuration file.
So I found this sample project. In docker-compose.yml I notice that he is supplying a environment variable called REGISTRY_HOST, and that this is then used in various application.yml files in the project, here for instance.
What I am wondering is, how does this mapping work and is it Docker or Spring that performs the magic? For instance, he is binding registry.host and registry.port, but how exactly is this mapped? How come it is registry that is the prefix, and where does registry.host come from when it isn't in the compose file?
Basically what docker does is it just assigns the environment variable, nothing more. But on Spring side, it reads this variables and tries to assign to an application property. Which is explained in Externalized Configuration Please see the 24.7.2 Relaxed Binding part of the documentation.
Is it possible to access environment variable of different application.properties from a single place. Actually we are building this software where we have different application.properties for different projects like user-asset. So is it possible to have all environment variable at one external place. If yes, how will it be accessed?
You would have an application.properties file that defines variables that would never change in what every situation you have.
application.properties
server.error.whitelabel.enabled=true #Just an example
Then you could have a separate application.properties with a different name such as application-active.properties. This file would add onto the base application.properties file.
application-active.properties
example.enviroment.variable=${I_AM_AN_ENVIROMENT_VARIABLE}
Then you could have a different application.properties file that has the same property name, in this case example.enviroment.variable.
application-dev.properties
example.enviroment.variable=${I_AM_A_DIFFERENT_ENVIRONMENT_VARIABLE}
Then in your code, you would just need to grab the example.enviroment.variable property depending on the current profile and it would grab the correct environment variable.
To specify what application.properites look at using profiles in spring-boot.
If its an environment variable, then I think multiple applications can access the same variable.
But if its inside the application.properties file, then I think its not possible.
Not only that, if you really feel that one application needs to access the application.properties of another, then I believe this is not a right way to proceed.
Rather, you should externalize the configurations (maybe by using a config server like spring-cloud-config) and share the common properties between the applications.
I am wondering what is the best way to configure an WAS Liberty installation, allowing to to switch from a DEV environment configuration to an UAT(testing) environment configuration dynamically.
To elaborate, we have a similar setup with our glassfish servers, we simply configure system properties for both in the Glassfish console. For example
hostname.uat="some uat value"
hostname.dev="some dev value"
Dropping the ".uat" or ".dev" in the system property configuration in Glassfish makes that property active. In Glassfish, this can be done dynamically and while the application is running (no need to reboot).
Is there or can someone elaborate how I could achieve a similar setup in WAS Liberty?
Thank-you kindly
You can create a server.env file in two possible places:
${wlp.install.dir}/etc/server.env (properties are applied to all servers) or
${server.config.dir}/server.env (properties applied only to one server)
and specify any environment variables in that file.
For example:
# Specify properties and values
admin.email=dev.admin#domain.com
admin.email.uat=uat.admin#domain.com
To access these properties in an application environment (such as a Servlet) do the following:
System.getenv("admin.email"); // returns "dev.admin#domain.com"
Other useful properties can be specified in the server.env file as well such as JAVA_HOME, WLP_USER_DIR, WLP_OUTPUT_DIR, and WLP_DEBUG_ADDRESS.
For IBM's full doc on this, see: Customizing the Liberty Environment.
What we do is generate the Liberty server with Ansible, where the variables can be added to an ansible inventory based on environment.
So, our deployments essentially drop and recreate the Liberty server by using ansible templates and roles to stamp it out as needed.
Lastly, we make use of Hasicorp Vault (you can also use ansible-vault) for credentials or secrets at deploy time to fetch credentials. This is then injected into Ansible as JSON and used to stamp out the server.xml and other related configuration files.