I have inherited a java Spring Boot project and I'm new to most java configurations. When I run this application in debug mode the first argument passed to my application as args[0] is --spring.output.ansi.enabled=always. I have searched my project files but cannot see where this might be configured to turn off, that is I do not want it passed in as an argument. I am using the Spring STS 3.9.1 IDE.
In the Spring STS IDE the Debug Configuration has an option ANSI console output which was checked. Unchecking stopped the argument being passed.
Under Debug Configuration, uncheck the field highlighted in Red.
All previous answers are correct. Nevertheless, here another alternative to configure Ansi output, even though it does not answer the original question (remember, args[0] had a value): the environment variable SPRING_OUTPUT_ANSI_ENABLED=always could be set, either in the STS/Eclipse run/debug configuration (tab Environment), or otherwise for your account, or globally on your machine.
By the way, any Spring Boot configuration property can be configured via environment variables:
either in a SPRING_APPLICATION_JSON environment variable,
or with Binding from Environment Variables
You can put any Spring Boot configuration properties into your application.properties (see here).
Or you can use any of the other mechanisms to externalize your configuration properties (see here).
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'
According to https://quarkus.io/guides/opentracing-guide all Jeager configuration is via JVM args (-DJAEGER_ENDPOINT...) but I'd like to use either application.properties or microprofile-config.properties to configure tracing. I've tried the following but the only config that seems to be picked up by Quarkus is the service-name all other properties are ignored.
quarkus.jaeger.service-name=my-service <-this one is working
quarkus.jaeger.endpoint=http://localhost:14268/api/traces <- seems to be ignored
quarkus.jaeger.reporter-log-spans=true
quarkus.jaeger.sampler.type=const
quarkus.jaeger.sampler.parameter=1
So, question is if it is possible to configure via config-files or this is not currently supported?
While doing mvnDebug quarkus:dev (without jvm.args) and placing a breakpoint here, I see that you all your params are being passed except quarkus.jaeger.sampler.parameter which is wrong.
It should be quarkus.jaeger.sampler.param
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.
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.
Having something like
security.user.password = plainTextPassword
inside Spring Boot’s application.properties is obviously an anti-pattern as it prevents the code from being pushed to a public SCM. In my non-Spring Boot projects I use
security.user.password = ${myPasswordFromMavenSettingsXML}
and put a corresponding <properties/> reference inside my pom.xml.
Using Maven’s resource filter plugin the passwords are replaced at build time so the application have access to actual plain text passwords after it has been build and deployed.
For some reason Maven’s resource filter plugin does not work in this case. Is there a way to not commit plain text passwords to an SCM and let Spring Boot to insert them at build time?
Spring boot has multiple mechanisms to provided externalized configuration. Some examples are command line arguments, environment variables and also application properties outside of your packaged JAR.
What I usually do:
Locally we configured several environment variables. Most (if not all) IDE's allow you to configure environment variables from within the run configuration.
For example if you don't want to expose the spring.datasource.password property you could set an environment variable called SPRING_DATASOURCE_PASSWORD.
When we deploy on another environment, we usually choose to add another application.properties or application.yml file within the same folder as the application JAR/WAR, since Spring boot picks that up as well.
Another solution is to use Spring cloud since it has a config service which can be used as a microservice to provide configuration. The configuration can be versioned using SCM as well, but you can put it on a separate system that is not connected to your source code.