Spring Cloud Config: client doesn't attempt to connect to the config server - spring-boot

I'm trying to create a simple Spring Cloud Config server/client setup and am loosely following the documentation:
https://cloud.spring.io/spring-cloud-config/reference/html/
I've so far implemented a server that seems to work correctly, i.e. return the correct property values when I call the corresponding endpoint:
GET http://localhost:8888/config-client/development
{
"name": "config-client",
"profiles": [
"development"
],
"label": null,
"version": null,
"state": null,
"propertySources": [
{
"name": "classpath:/config/config-client-development.properties",
"source": {
"user.role": "Developer"
}
}
]
}
I'm, however, not having any luck with getting the client to connect to the server. I have done the following:
Added the spring-cloud-starter-config dependency:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
Added a bootstrap.properties file:
spring.application.name=config-client
spring.profiles.active=development
spring.cloud.config.uri=http://localhost:8888
But I'm still getting a
java.lang.IllegalArgumentException: Could not resolve placeholder 'user.role' in value "${user.role}"
when trying to run the client application.
There is nothing in the application log that even looks like the client is attempting to communicate with the configuration server.
Link to a minimal GitHub repository that reproduces the issue:
https://github.com/Bragolgirith/spring-cloud-minimal
Steps to reproduce:
Build and run the config-service application
Build and run the config-client application
Any idea what I'm doing wrong?

OK, mistery solved.
It seems a new Spring Cloud version was released a week ago (https://spring.io/blog/2020/10/07/spring-cloud-2020-0-0-m4-aka-ilford-is-available) that has a new way to activate the bootstrap process - now it doesn't happen by default, but requires adding an additional dependency:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
Although this new version is now the default you get when using the
Spring Initializr, the documentation is still not updated to reflect the changes - they are only briefly mentioned in the release notes.
As an alternative to using the abovementioned spring-cloud-starter-bootstrap dependency and a bootstrap.properties file, it seems the following is now also possible (and even preferred):
application.properties
spring.application.name=config-client
spring.profiles.active=development
spring.config.import=configserver:http://localhost:8888

Related

certmanager implementation in the fabric8

I read an article https://developers.redhat.com/articles/2021/07/16/whats-new-fabric8-kubernetes-client-version-550#new_features_in_fabric8_kubernetes_client_5_5_0, it mentioned in 5.5 release it adds "Certification management", however, seem I could not find any source codes related to it in fabric8 repo.
when I run a simple code like this
try (CertManagerClient certManagerClient = new DefaultCertManagerClient()) {
CertificateRequest certificateRequest = new CertificateRequestBuilder()
.withNewMetadata().withName("barry_coding_test").endMetadata()
.withNewSpec()
.withRequest(request)
.withIsCA(false)
.addToUsages("signing", "digital signature", "server auth")
.withDuration(Duration.parse("2160h"))
.withIssuerRef(new ObjectReferenceBuilder()
.withName("barry-dlc-cert-issuer")
.withKind("Issuer")
.withGroup("cert-manager.io")
.build())
.endSpec()
.build();
certManagerClient.v1().certificateRequests().inNamespace("barry").create(certificateRequest);
} catch (Exception e) {
e.printStackTrace();
}
It throws error
Exception in thread "main" java.lang.NoSuchMethodError: io/fabric8/kubernetes/client/dsl/base/HasMetadataOperation.<init>(Lio/fabric8/kubernetes/client/dsl/base/OperationContext;)V (loaded from file:/Users/zhBarry#ca.ibm.com/osprey/mvnexample/java-app/dlc-management-service/libs/kubernetes-client-5.8.0.jar by jdk.internal.loader.ClassLoaders$AppClassLoader#40575da4) called from class io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl (loaded from file:/Users/zhBarry#ca.ibm.com/osprey/mvnexample/java-app/dlc-management-service/libs/certmanager-client-5.5.0.jar by jdk.internal.loader.ClassLoaders$AppClassLoader#40575da4).
at io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl.<init>(CertificateRequestOperationsImpl.java:32)
at io.fabric8.certmanager.client.api.v1.internal.CertificateRequestOperationsImpl.<init>(CertificateRequestOperationsImpl.java:28)
at io.fabric8.certmanager.client.V1APIGroupClient.certificateRequests(V1APIGroupClient.java:51)
at com.ibm.si.osprey.App.main(App.java:67)
I could not find source code CertificateRequestOperationsImpl.java at all in the repo.
Any ideas for it? Where can I certmanager implementation in the fabric8 repo?
You wouldn't find CertManager related features in kubernetes-client jar itself. All Fabric8 Kubernetes Client Extensions are available via their own individual jars. For CertManager, you need to add this dependency:
Maven:
<dependency>
<groupId>io.fabric8</groupId>
<artifactId>certmanager-client</artifactId>
<version>5.9.0</version>
</dependency>
Gradle:
implementation 'io.fabric8:certmanager-client:5.9.0'
There is an example placed in https://github.com/fabric8io/kubernetes-client/tree/master/extensions/certmanager/examples/src/main/java/io/fabric8/certmanager/examples/v1 . Maybe this section needs improvement; you're welcome to contribute some more examples if you have some time :-) .
I've tested your sample on a demo project with certmanager-client dependency with certmanager installed on minikube. You can find demo project here: https://github.com/rohankanojia-forks/cert-manager-java-extension-demo

spring-boot 2.5.5 property "spring.config.import" not defined?

after upgrade spring-boot:2.3.11.RELEASE to spring-boot:2.5.5 and spring-cloud:Hoxton.SR11 to spring-cloud:2020.0.4, spring-boot:run is failing with:
***************************
APPLICATION FAILED TO START
***************************
Description:
No spring.config.import property has been defined
Action:
Add a spring.config.import=configserver: property to your configuration.
If configuration is not required add spring.config.import=optional:configserver: instead.
To disable this check, set spring.cloud.config.enabled=false or
spring.cloud.config.import-check.enabled=false.
Advices are pretty clear so I added
spring.cloud.config.enabled=false
spring.cloud.config.import-check.enabled=false
spring.config.import=optional:configserver:
to both application.properties and bootstrap.properties files
In application.properties I had to comment out line spring.config.import=optional:configserver: otherwise it failed with java.lang.IllegalStateException: Unable to load config data from 'optional:configserver:' ......... Caused by: java.lang.IllegalStateException: File extension is not known to any PropertySourceLoader
As I didn't need to comment it out in bootstrap.properties, values are ignored completely there probably
However application itself failed the same way as without any new properties added.
Any ideas what is the problem? What is correct format for spring.config.import=... ?
EDIT:
after adding dependency
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-bootstrap</artifactId>
</dependency>
it doesn't ignore properties in bootstrap.properties anymore so I had to comment out "spring.config.import=optional:configserver:" there as well. However application still failing with "No spring.config.import property has been defined"
In Spring Cloud 2020 you dont need bootstrap.properties anymore, importing spring-cloud-starter-bootstrap enable only a legacy way to use it.
Just remove it...
You need to add
spring.config.import=optional:configserver:http://your.config.server.com
into your application.properties. Howerver I not sure what you try to achieve, because of your
spring.cloud.config.enabled=false
More Info

com.bedatadriven.jackson.datatype.jts.JtsModule not working with springboot 2.2.4

I am trying to serialize/deserialize org.locationtech.jts.geom.Geometry(version 1.16.0) using com.bedatadriven.jackson.datatype.jts.JtsModule. It comes packaged with:
<dependency>
<groupId>com.graphhopper.external</groupId>
<artifactId>jackson-datatype-jts</artifactId>
<version>1.0-2.7</version>
</dependency>
I have registered it using spring configuration mechanism:
#Bean
public JtsModule jtsModule()
{
return new JtsModule();
}
But somehow com.bedatadriven.jackson.datatype.jts.serialization.GeometryDeserializer is not invoked.
Is there something else needed to be done?
GeometryDeserializer / GeometrySerializer worked for com.vividsolutions.jts.geom.Geometry
An issue is open about it here
You can create your custom serializer and deserializer for org.locationtech.jts.geom.Geometry using same code available.
Example for point
There is a PR for Upgrade to Locationtech jts but not merged yet

Springdoc: got 404 when open swagger-ui.html

I got latest Spring Boot app and springdoc.swagger-ui on board.
<dependency>
<groupId>io.swagger</groupId>
<artifactId>swagger-annotations</artifactId>
<version>1.6.1</version>
</dependency>
<dependency>
<groupId>org.springdoc</groupId>
<artifactId>springdoc-openapi-ui</artifactId>
<version>1.2.32</version>
</dependency>
My application.properties contains springdoc.swagger-ui.path=/swagger-ui-openapi.html
When I run application via Intellij IDEA http://localhost:8080/swagger-ui-openapi.html brings me to http://localhost:8080/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config
and Swagger UI page loads successfully.
But if I start the app via command line: "java -jar my-app.jar", I got 404 in browser and Error in logs 'Circular view path [error]' when trying to reach http://localhost:8080/swagger-ui-openapi.html
and it redirrects me to http://localhost:8080/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config
javax.servlet.ServletException: Circular view path [error]: would dispatch back to the current handler URL [/error] again. Check your ViewResolver setup! (Hint: This may be the result of an unspecified view, due to default view name generation.)
However http://localhost:8080/v3/api-docs is reachable and schema is available at this address.
How can I fix this?
What worked in my case when your application is running behind a proxy, a load-balancer or in the cloud.
In your Spring Boot application make sure your application handles this header: X-Forwarded-For.
There are two ways to achieve this:
In your properties file add:
server.use-forward-headers=true
If this is not enough, Spring Framework provides a ForwardedHeaderFilter. You can register it as a Servlet Filter in your application by setting server.forward-headers-strategy is set to FRAMEWORK.
Since Spring Boot 2.2, this is the new property to handle reverse proxy headers:
In your properties file add
server.forward-headers-strategy=framework
And you can add the following bean to your application:
#Bean
ForwardedHeaderFilter forwardedHeaderFilter() {
return new ForwardedHeaderFilter();
}
If you already have static content on your root, and you don’t want it to be overridden by springdoc-openapi-ui configuration, you can just define a custom configuration of the swagger-ui, in order not to override the configuration of your files from in your context-root:
For example use in your properties file:
springdoc.swagger-ui.path= /swagger-ui/api-docs.html
ref:
https://springdoc.org/
For this problem, my conclusion is:
(1) Starting it in IDEA is fine
(2) Repackaging the jar with spring-boot-maven-plugin and starting it with 'java -jar' is fine as well.
(3) if I tried to starting with such as 'java -classpath ".:.conf" DemoApplication', it does not work.
So, for packaging, i use the spring-boot-maven-plugin.
You don't need swagger-annotations v1.6.1 dependency for springdoc-openapi;
By default, with springdoc you need no additonal settings of any ViewResolver.
You can have a look at some sample code:
https://github.com/springdoc/springdoc-openapi-demos

how to add a feature in Nitrogen opendaylight?

I am trying to add some feature to my open daylight project (e.g. l2switch, dlux, rest,...).
I used to edit the features.xml and the pom.xml for add there features in Carbon release. I am currently using Nitrogen release, when adding these dependencies in my features pom.xml file, I am still unable to detect the features when I login to my karaf (using feature:install/list).
<dependency>
<groupId>org.opendaylight.netconf</groupId>
<artifactId>features-restconf</artifactId>
<classifier>features</classifier>
<version>${restconf.version}</version>
<type>xml</type>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.opendaylight.dluxapps</groupId>
<artifactId>features-dluxapps</artifactId>
<classifier>features</classifier>
<version>${dluxapps.version}</version>
<type>xml</type>
<scope>runtime</scope>
</dependency>
am I missing something else? when I try to add repositories,as I previously did in carbon-release. The feature.xml it automatically re-generated and all my editing is removed.
I am using Nitrogen release by defining and -DarchetypeVersion=1.4.0 when generating my maven artifact.
See the upstream configuration management tooling for running-code examples being used constantly in downstreams like OPNFV.
# Configuration of Karaf features to install
file { 'org.apache.karaf.features.cfg':
ensure => file,
path => '/opt/opendaylight/etc/org.apache.karaf.features.cfg',
# Set user:group owners
owner => 'odl',
group => 'odl',
}
$features_csv = join($opendaylight::features, ',')
file_line { 'featuresBoot':
path => '/opt/opendaylight/etc/org.apache.karaf.features.cfg',
line => "featuresBoot=${features_csv}",
match => '^featuresBoot=.*$',
}
puppet-opendaylight, manifests/config.pp, stable/nitrogen
So basically you shouldn't be editing the XML directly, you should edit the configuration that generates the XML. I'm surprised that worked in Carbon.
I recommend directly using upstream configuration management tooling, like puppet-opendaylight or ansible-opendaylight, vs trying to figure out the configuration knobs yourself, duplicating effort. If you're doing a more complex deployment, look at the OPNFV installer scenarios (that build on these ODL tools) vs trying to solve that very hard problem yourself.

Resources