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
Related
In quarkus the config is stored inside an application.properties file.
You can have multiple application-{profile}.properties files. {profile} is the name of the profile you want it to be.
When started with java -jar <pathToJar> -Dquarkus.profile=PROFILE_ONE the file application-PROFILEONE.properties is used. During startup of the app you can read that quarkus is using the PROFILE_ONE profile.
When started with java -jar <pathToJar> -Dsmallrye.config.profile=PROFILE_ONE the file application-PROFILEONE.properties is used. During startup of the app you can read that quarkus is using the PROD profile.
What exactly is the difference between both? Is it better to use smallrye.config.profile so that quarkus is still using the PROD profile? Is the PROD profile faster?
Thanks!
That is actually a bug. Internally, both use the same profile, but the log is reporting a different one when you use smallrye.config.profile, because it is only checking for quarkus.profile and then it defaults to prod (later in the code the actual profile is checked and used the correct one).
The message needs to be fixed. I'll look into it.
I have a Spring boot Gradle project and I want to get it's OpenAPI spec YAML file.
As I understand the official swagger-core does not support Spring boot projects, thus I found springdoc-openapi (https://github.com/springdoc/springdoc-openapi-gradle-plugin).
It seems that in order to get the YAML/JSON files, when running the generateOpenApiDocs task, the springdoc library sets up a server with some endpoints (/v3/api-docs) to download the files.
I'm using the default configuration, and for some reason I keep getting the following error:
Execution failed for task 'generateOpenApiDocs'.
Unable to connect to http://localhost:8080/v3/api-docs waited for 30 seconds
It seems that for some reason it does not set up the server. How can I fix it?
Is it possible to skip the server part? Can I configure springdoc to simply generate files on build?
If you are deploying REST APIs with spring-boot, you are relying on a servlet container.
The necessry metadata for the OpenAPI spec are only available by spring framework on runtime, which explains the choice of generation at runtime.
You can define any embeded servlet container, during your integration tests to generate the OpenAPI Spec.
This is how I resolved the issue
Specify the path
In your properties file enter:
springdoc:
api-docs:
path: /{your path}
Configure the plugin
In your build.gradle file enter:
openApi {
apiDocsUrl.set("http://localhost:{your port}/your path)
}
This happens because sometimes embedded server took sometime to start and it has 30 sec default setting. Please add the below properties in your openAPI block and it will work fine for you. Please see the below sample:
openApi {
apiDocsUrl.set("http://localhost:9090/v3/api-docs.yaml")
outputDir.set(file("Your Directory path"))
outputFileName.set("openapi.yaml")
forkProperties.set("-Dserver.port=9090")
waitTimeInSeconds.set(60)
}
You need to add the dependency below, an updated version may exist depending on when you're seeing this - intellij would tell you and help upgrade:
implementation('org.springdoc:springdoc-openapi-ui:1.6.11')
Then add the line below to your application.properties file:
springdoc.api-docs.path=/api-docs
Perhaps also get rid of the plugin, it's not necessary as long as you have the above dependency. I got rid of mine and things work fine.
After the dependency is resolved, run the app normally with intellij run buttons or the commandline.
With the app running, visit http://localhost:8080/swagger-ui/index.html - assuming your app is running on port 8080. If not, use the right port accordingly.
Also, you can check out https://github.com/springdoc/springdoc-openapi-gradle-plugin/issues/10 and https://github.com/springdoc/springdoc-openapi-gradle-plugin/issues/10#issuecomment-594010078 - those were helpful when I faced the same issue, showed me part of what to do.
In Quarkus, We have properties file inside project itself called application.properties.
Is there any Quarkus way to define external properties file in my use case like i am developing a mail sender and i want to add recipients in future.
Is it possible to give application.properties outside at local and inject it at runtime?
You can add a configuration file in your application working directory under config/application.properties : https://quarkus.io/guides/config#overriding-properties-at-runtime
There is ongoing discussion to have more runtime configuration capabilities here: https://github.com/quarkusio/quarkus/issues/1218
You can achieve this by keeping .properties (or .yaml) in Spring Cloud Config Server.
It's really easy to set it up. It's is well documented in following link (official documentation):
Quarkus - Reading properties from Spring Cloud Config Server
As loïc says, you can follow the convention and create a config/application.properties. You can also use the property quarkus.config.locations to specify additional config locations. It can be defined at runtime like below
java -Dquarkus.config.locations=app-config/config.properties -jar my-app.jar
I have a setup where I am using the following:
Spring Boot 1.5.13 with Spring Cloud Version Edgware.S3
I have Spring Cloud Config Server and my Spring Boot apps are its clients
Each app carries a bootstrap.yml with the config server uri and some other properties.
Running containers on a Docker Swarm
I am currently passing Swarm secrets to the clients via a custom script which reads the files put into /run/secrets/ and creating a /config/bootstrap.properties file. It ends up looking like this:
spring.cloud.config.username=user
spring.cloud.config.password=password
My Docker image's default command is then this:
java -Djava.security.egd=file:/dev/./urandom -jar /${appName}.jar --spring.cloud.bootstrap.location=file:/config/bootstrap.properties"
Great. This is working without a problem. The app, seemingly, reads:
The external bootstrap.properties to read in the config server's credentials
The classpath bootstrap.yml to read in the rest of the config client props
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
Now. I'm moving the apps to Spring Boot 2.0.3 with Finchley.RELEASE and well, this breaks.
What is happening now is:
The external bootstrap.properties is read in to get the config server's credentials
The classpath bootstrap.yml is SKIPPED entirely (UNEXPECTED!)
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
The problem is that the properties that were set in the internal bootstrap.yml are now missing for the app so it blows up on start. I've been able to reproduce it outside the container environment by doing the same thing; point the app to an external bootstrap.properties. If I copy over the bootstrap.yml properties into the bootstrap.properties, then it works just fine. Also, if I don't provide an external properties file, then the internal bootstrap.yml kicks in without a problem. So it's either one or the other!
I'v also tried modifying the bootstrap location to include the default locations but no luck:
-- spring.cloud.bootstrap.location=file:/config/bootstrap.properties,classpath:,classpath:/config,file:,file:config/
Any ideas where to look next? Maybe there is a new spring.cloud.config property I'm missing? Or can anyone confirm which behavior is the correct behavior? Assuming they fixed a potential loophole in Finchley then I can just put this to rest and look for another solution. If it's 'broken' in Finchley, I guess an issue report is in order?
Well, some more digging showed that it looks like this is the new behavior:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide
The behavior of the spring.config.location configuration has been fixed; it previously added a location to the list of default ones, now it replaces the default locations. If you were relying on the way it was handled previously, you should now use spring.config.additional-location instead.
It didn't look to be Spring Cloud specific but I had nothing to lose.
Changing my java command to use this new property did the trick:
--spring.config.additional-location=file:/config/bootstrap.properties
Thanks.
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).