After updating the version of spring-cloud the value are not decrypted server side. It worked fine in the previous versions, and I did not find anything regarding this issue in the Edgeware release notes.
Am I missing something? Is there an undocumented change with this version?
My issue is related to this: https://github.com/spring-cloud/spring-cloud-config/issues/684
Basically - if I understand this correctly - in Edgeware decryption of environment variables (this is the key I think) works only in bootstrap.yml and not in application.yml
Related
I am checking the Quarkus guide for the flyway extension.
The default schema configuration is not listed and is not supported. I added in my application.properties
quarkus.flyway.default-schema=some_schema
quarkus.flyway.defaultSchema=some_schema
and tested, but it's not recognised. Is there a workaround or should an issue be created?
I have opened https://github.com/quarkusio/quarkus/pull/22957 to address this concern.
If all goes well, this will make it into version 2.7.0.Final.
got defaulted to
quarkus.flyway.default-schema=some_schema
just in case anyone is seeing this now
I am upgrading my application from SpringBoot 1.5 to 2.3, the old application had the following yml file
config:
pic_code:
"Test/Try": "ABC"
"Trial": "DRF"
After upgrading, YAML key with '/' is not being read properly and gives null.
I have tried to change the key as below
"[Test/Try]"
'[Test/Try]'
"Test'/Try"
but nothing worked.
Any suggestions will be very much helpful
It works with '[Test/Try]' as per the link shared above Spring Boot YAML configuration with URL in key no longer loads correctly with version 2
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.
Trying to get a older version of Spring Boot running on Pivotal Web Services.
It needs to connect to a Eureka server. I have stood up a new Eureka server in the same space the Client App is running on in PWS.
As I don't have the code for the Client application (can't modify the application property/yml files), I need to configure the Client's Eureka client to connect to the new Eureka server using Environmental Variables.
Here is what I have tried:
In the Cloud Foundries 'manifest.yml' I currently have:
---
applications:
- name: <Client application name>
...
other non related settings
...
env:
EUREKA_INSTANCE_HOSTNAME: https://<pws route of eureka server>
This is not picked up.
It looks like that property is picked up like that:
https://jar-download.com/artifacts/org.springframework.cloud/spring-cloud-netflix-eureka-client/1.1.0.RELEASE/source-code/org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.java
I have tried a few variable names:
eureka.instance.hostname
EUREKA_CLIENT_SERVICEURL_DEFAULTZONE
eureka.client.serviceUrl.defaultZone
I also tried setting a SPRING_APPLICATION_JSON to contain these combinations in the same way in the manifest.yml.
None of them seem to get picked up.
Is there a different way that this can be done? Again, I don't have access to the code, only the Jar.
So its not pretty, but I was able to modify the application.properties files in the Jars using VIM to contain this setting:
eureka.client.serviceUrl.defaultZone=<pws route>/eureka/
Just made the Jar write-able, added that setting, saved and then cf push'd it up. Works. Not sure why the ENV did not work, but its not worth fixing. Everything in this Jar is ancient (Spring Cloud version 1.0). Its all going to get re-written anyway, just need the legacy version running somewhere stable while that work happens.
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.