Spring Cloud Connectors for Spring Cloud Services on PCF
Home Page: http://docs.pivotal.io/spring-cloud-services
License: Apache License 2.0
Spring Cloud Connectors for Spring Cloud Services in a Pivotal Cloud Foundry environment
Config Server
Circuit Breaker (Netflix Hystrix)
Service Registry (Netflix Eureka)
Spring Cloud Services Connector is Open Source software released under the Apache 2.0 license.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
There are two parts to this issue:
PropertyMaskingContextInitializer fails to find a PropertySource with the name "bootstrapProperties" of type CompositePropertySource
PropertyMaskingContextInitializer is adding a PropertySource with the name "management.endpoint.env.keys-to-sanitize" of type PropertiesPropertySource at the highest precedence.The end result is that the /env actuator endpoint is not fully masked / sanitized and I'm stuck because I am unable to override the management.endpoint.env.keys-to-sanitize property in application.yml or by any other means since it will always be at a lower precedence than what the PropertyMaskingContextInitializer provides.
This should pull in Spring Cloud Connectors 2.0.4.
required by https://github.com/pivotal-cf/spring-cloud-service-broker/issues/576
requires pivotal-cf/spring-cloud-services-starters#53
As explained in the its reference documentation, Spring Boot provides a spring-boot-autoconfigure-processor.
This should be added as an optional dependency to the module that contains the AutoConfiguration classes (and contains the spring.factories file declaring them).
Once configured, this annotation processor will generate metadata at compile time and will help Spring Boot process those auto-configurations without loading the actual classes in some cases.
The spring-cloud-services-spring-connector declares 4 auto-configurations but doesn't use this annotation processor. Could you add it to the build?
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-autoconfigure-processor</artifactId>
<optional>true</optional>
</dependency>Once added, this should generate a spring-autoconfigure-metadata.properties file in the target/classes/META-INF folder.
Because SC Gateway is based on Spring WebFlux, but our connectors depend on Spring Security for OAuth (S2OAuth), which depends on Spring MVC, it has been found that SCS client apps are not compatible with Spring Cloud Gateway and, more specifically, Spring WebFlux.
Given that the Spring Framework is promoting reactive programming heavily and given that Spring Cloud Gateway is replacing Spring Cloud Netflix Zuul as the gateway of choice, it is likely that SCS customers will want to use WebFlux (either for API purposes or using WebClient instead of RestTemplate...or both). Therefore, we should aim to support WebFlux as an option in SCS client applications.
Note, the incompatibility appears to come from our reliance on S2OAuth for security between clients and the services. And since S2OAuth does not support WebFlux, we may should consider moving toward Spring Security 5's client-side OAuth support, working with the Spring Security team to ensure that our needs are met for client-side applications. Also note that this is largely a starters/connectors issue and there is no anticipated impact to the broker or backing apps.
The ServiceInfoPropertySourceAdapter.java 'silently' disables the RabbitAutoConfiguration since SCS 1.5+
I created a sample project: https://github.com/pavax/cloudfoundry-sample
deploy it and go to the /management/env Actuator Endpoint (username: root / password: secret)
you'll find
springCloudServicesRabbitAutoconfigExcluder: {
spring.autoconfigure.exclude: "org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration"
},
Is this really intended? IMHO: It is kinda "harsh" to disable a AutoConfigiration completely. Since in many project we depend on the classes provided by Spring Boots' AutoConfigurations. In this particular case several beans are expecting a RabbitTemplate and even more everything done and exposed in the RabbitAnnotationDrivenConfiguration such as the SimpleRabbitListenerContainerFactory.
Funny Fact: No exception is beeing raised if you app is simply trying to listen to Rabbit Messages since the RabbitListener are not triggered at all (due to the missing @EnableRabbit annotation that is exposed for you in the RabbitAutoConfiguration -> RabbitAnnotationDrivenConfiguration. Kinda nasty to find these kind of bugs :)
@RabbitListener(queues = "my-queue")
public void processMyMessage(Message message) {
}
Note:
This Bug was already mentioned here: pivotal-cf/spring-cloud-services-starters#15 but since it's root-cause has nothing to do with the 'spring-cloud-services-starters' I thought I give it a try and create it this repository.
From customer:
"a security scan ... [contained] error report which indicates that versions [of SCS connectors] 2.1.4 contains an older/problematic Spring version. Is there some later version of SCS [connectors] that I can use to avoid this?"
This is stopping the deployment of their apps into production PCF foundations until it is resolved. Are we able to update the dependency that includes CVE-2018-1270?
Hi,
I face two issues related to deploying microservices to cloud foundry with Spring Cloud Services enabled.
First, it appears that if I deploy an app with CF route path, if would simply fail to register. I deploy an app like this:
cf push -p target/date-services-1.0.jar --hostname env5-date-services --route-path /v1 -f manifest.yml date-services-v1
The manifest looks like this:
applications:
- name: date-services-v1
memory: 1024M
instances: 1
timeout: 180
env:
JBP_CONFIG_OPEN_JDK_MEMORY_CALCULATOR: "[memory_sizes: {metaspace: 180m}, memory_heuristics: {metaspace: 25}]"
services:
- rabbitmq
- config-server
- discovery
- circuit-breaker
- mysql
The application gets registered by Eureka, but it cannot be found. If I open the link from the Eureka dashboard, it is translated as something like:
http://site.com/v1:80/info
http://site.com/v1:80/date
This URL is simply inaccessible. Other apps try to call the date-services microservice and fail with "404 not found". If I remove the route path - from the deployment - everything is great.
The other problem is with blue-green deployments.
If I deploy the same jar to a new app name, like date-services-GREEN, again I am failing in Eureka:
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT 2017-03-23 07:21:16.225 ERROR [date-services-sa-v1,,,] 20 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_date-services-SA-V1/pcfdev01-date-services-sa-v1-GREEN.apps.cf.site.com:84e48618-3b11-46e4-7b3e-f638788786ea - was unable to send heartbeat!���
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient.register(DiscoveryClient.java:815)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT 2017-03-23 07:21:16.225 WARN [date-services-sa-v1,,,] 20 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_date-services-SA-V1/pcfdev01-date-services-sa-v1-GREEN.apps.cf.site.com:84e48618-3b11-46e4-7b3e-f638788786ea - registration failed Cannot execute request on any known server���
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:111)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.register(EurekaHttpClientDecorator.java:56)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:837)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1396)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.FutureTask.run(FutureTask.java:266)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$1.execute(EurekaHttpClientDecorator.java:59)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.lang.Thread.run(Thread.java:745)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:111)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.register(EurekaHttpClientDecorator.java:56)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.register(EurekaHttpClientDecorator.java:56)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.FutureTask.run(FutureTask.java:266)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient.register(DiscoveryClient.java:815)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:837)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1396)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT at java.lang.Thread.run(Thread.java:745)��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT 2017-03-23 07:21:16.306 INFO [date-services-sa-v1,,,] 20 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_date-services-SA-V1/pcfdev01-date-services-sa-v1-GREEN.apps.cf.site.com:84e48618-3b11-46e4-7b3e-f638788786ea: registering service...���
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server��
Thu Mar 23 2017 09:21:16 GMT+0200 (IST) [APP] OUT 2017-03-23 07:21:16.331 WARN [date-services-sa-v1,,,] 20 --- [nfoReplicator-0] c.n.d.s.t.d.RetryableEurekaHttpClient : Request execution failure with status code 403; retrying on another server if available���
Eventually these errors go away, however after full blue-green the registered route in Eureka still points to GREEN and not the original route. Which is ofcourse inaccessible.
Here is the commands I am running:
cf push -p artifact.jar --hostname ${ENV_NAME}-${HOST_NAME}-${VERSION_NUMBER}-GREEN -f manifest.yml ${TARGET_JOB_NAME}-GREEN
cf map-route ${TARGET_JOB_NAME}-GREEN ${DOMAIN} --hostname ${ENV_NAME}-${HOST_NAME}-${VERSION_NUMBER}
cf delete-route ${DOMAIN} -f --hostname ${ENV_NAME}-${HOST_NAME}-${VERSION_NUMBER}-GREEN
cf rename ${TARGET_JOB_NAME}-GREEN ${TARGET_JOB_NAME}
The final URL that is registered in Eureka is:
http://pcfdev01-date-services-sa-v1-green.cf.site.com/info
With the "green" in the URL, it simply doesn't work. If I remove the "green" from the URL, it works.
I am using Camden.SR6 and Spring Cloud Services 1.4.1.RELEASE. I Believe the runtime in the CF environment is 1.7.
Thanks.
Original issue found by @pacphi
Using the following branch that was created to update client applications to using Spring Cloud Greenwich.SR1 and Spring Boot 2.1:
The client applications ran into failures on startup:
2019-04-22T18:51:21.28-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:21.289 WARN 14 --- [ main] o.s.boot.actuate.endpoint.EndpointId : Endpoint ID 'service-registry' contains invalid characters, please migrate to a valid format.
2019-04-22T18:51:21.88-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:21.882 INFO 14 --- [ main] o.s.cloud.context.scope.GenericScope : BeanFactory id=59fdf168-4b96-3fc7-810f-89ac7db619a9
2019-04-22T18:51:21.89-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:21.893 INFO 14 --- [ main] eReconfigurationBeanFactoryPostProcessor : Skipping reconfiguration because cloud services already configured
2019-04-22T18:51:22.36-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:22.364 INFO 14 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration' of type [org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration$$EnhancerBySpringCGLIB$$3f825871] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2019-04-22T18:51:22.41-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:22.417 INFO 14 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.hateoas.config.HateoasConfiguration' of type [org.springframework.hateoas.config.HateoasConfiguration$$EnhancerBySpringCGLIB$$bf02a5a3] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2019-04-22T18:51:22.43-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:22.431 INFO 14 --- [ main] trationDelegate$BeanPostProcessorChecker : Bean 'org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration' of type [org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfiguration$$EnhancerBySpringCGLIB$$5b9c5b6e] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
2019-04-22T18:51:23.29-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:23.298 INFO 14 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
2019-04-22T18:51:23.35-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:23.353 INFO 14 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2019-04-22T18:51:23.35-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:23.353 INFO 14 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.17]
...
2019-04-22T18:51:29.43-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:29.433 INFO 14 --- [ main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2019-04-22T18:51:30.59-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:30.597 INFO 14 --- [ main] o.h.h.i.QueryTranslatorFactoryInitiator : HHH000397: Using ASTQueryTranslatorFactory
2019-04-22T18:51:31.25-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.250 WARN 14 --- [ main] ConfigServletWebServerApplicationContext : Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration$ConfigClientOAuth2Configurer': Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.NoUniqueBeanDefinitionException: No qualifying bean of type 'io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration' available: expected single matching bean but found 2: configClientOAuth2BootstrapConfiguration,io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration
2019-04-22T18:51:31.25-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.253 INFO 14 --- [ main] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default'
2019-04-22T18:51:31.26-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.262 INFO 14 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown initiated...
2019-04-22T18:51:31.27-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.272 INFO 14 --- [ main] com.zaxxer.hikari.HikariDataSource : HikariPool-1 - Shutdown completed.
2019-04-22T18:51:31.27-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.274 INFO 14 --- [ main] o.apache.catalina.core.StandardService : Stopping service [Tomcat]
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.293 WARN 14 --- [ main] o.a.c.loader.WebappClassLoaderBase : The web application [ROOT] appears to have started a thread named [spring.cloud.inetutils] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/jdk.internal.misc.Unsafe.park(Native Method)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.locks.LockSupport.park(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
2019-04-22T18:51:31.29-0700 [APP/PROC/WEB/0] OUT [email protected]/java.lang.Thread.run(Unknown Source)
2019-04-22T18:51:31.32-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.326 INFO 14 --- [ main] ConditionEvaluationReportLoggingListener :
2019-04-22T18:51:31.32-0700 [APP/PROC/WEB/0] OUT Error starting ApplicationContext. To display the conditions report re-run your application with 'debug' enabled.
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT 2019-04-23 01:51:31.329 ERROR 14 --- [ main] o.s.b.d.LoggingFailureAnalysisReporter :
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT ***************************
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT APPLICATION FAILED TO START
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT ***************************
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT Description:
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT Parameter 0 of constructor in io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration$ConfigClientOAuth2Configurer required a single bean, but 2 were found:
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT - configClientOAuth2BootstrapConfiguration: defined in URL [jar:file:/home/vcap/app/BOOT-INF/lib/spring-cloud-services-spring-connector-2.1.1.RELEASE.jar!/io/pivotal/spring/cloud/service/config/ConfigClientOAuth2BootstrapConfiguration.class]
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT - io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration: defined in null
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT Action:
2019-04-22T18:51:31.33-0700 [APP/PROC/WEB/0] OUT Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed
2019-04-22T18:51:31.72-0700 [APP/PROC/WEB/0] OUT Exit status 1
2019-04-22T18:51:31.72-0700 [CELL/SSHD/0] OUT Exit status 0
The same code currently works with Spring Cloud Finchley on master branch.
This should pull in Spring Cloud Connectors 1.2.6.
required by https://github.com/pivotal-cf/spring-cloud-service-broker/issues/576
The generated pom of io.pivotal.spring.cloud:spring-cloud-services-spring-connector:2.2.0.RELEASE looks wrong to me. There are versions for certain artifacts and not others.
I don't think you can safely assume this artifact is going to be used alongside a bom so it should always provide a version for every dependency (doing so makes sure the project can run in isolation). If a bom is present, it will apply consistent versioning regardless.
In particular, no version is provided for com.sun.jersey:jersey-client and this artifact is no longer managed so the published pom is invalid with the relevant Spring Boot/Spring Cloud BOMs:
[WARNING] The POM for io.pivotal.spring.cloud:spring-cloud-services-spring-connector:jar:2.2.0.RELEASE is invalid, transitive dependencies (if any) will not be available: 1 problem was encountered while building the effective model for io.pivotal.spring.cloud:spring-cloud-services-spring-connector:2.2.0.RELEASE
[ERROR] 'dependencies.dependency.version' for com.sun.jersey:jersey-client:jar is missing. @
We need to publish SCS Starters and Connector 2.3.0.RELEASE to Maven Central so it is made available to Developers.
This issue is with v2.4.1 (boot 2.4, cloud 2020)
given a config-client app with spring.application.name set to: config-server-client in its internal application.yml file
and the app is deployed and bound to a SCS config-server instance
and the app has pulled config from config-server at the path /config-server-client/cloud
when /actuator/refresh is called on the app
then the client app should make the same call for configuration as it did on startup (path above)
actual behaviour: the second call for config uses a different application name, which is the deployed app name from cf
for example, if the app was deployed with cf push config-server-client-bla, then the second call for config would be to path /config-server-client-bla/cloud instead of the path shown above.
This is exposed in SCS 3 acceptance tests:
io.pivotal.spring.cloud.acceptance.config.specs.ConfigServerWithCredHubBackendSpec > adding and removing secrets to/from the credhub backend with the CLI
The culprit is spring-boot's new (in 2.4) ordering of property sources. Any external config is prioritized above config that's internal to the app's jar. Although, it's not clear why this only becomes a problem after /actuator/refresh.
Where we were previously able to set a default spring.application.name based on the deployed app name, here; now we'll presumably need to drop this default behaviour unless an alternative mechanism can be found.
The spring-cloud-services-connector as of version 2.0.0.RELEASE contains an application.yml that is packaged as part of the final jar.
This means that it will be picked up by spring boot applications using this library.
By picking this up the loggers of org.springframework.web and org.springframework.security will be logging to DEBUG which is certainly not the intention of most of the users of this library.
I guess the debug stuff should be removed and the yml file should be renamed to something library specific e.g. application-spring-cloud-service-connector.yml and referenced explicitly within this library, to avoid accidental picking up of this configuration file.
I'm using the spring-cloud-services-connector in order to accomplish Eureka connectivity on cloud foundry. When our app deploys, after a successful health check, our PCF renames our applications.
Example: Renaming application example-app-development-dark to example-app-development...
I'm using ${vcap.application.uris[0]} in my application-dev.yaml file in order to grab the URI for purposes of Eureka registration on the client side. Once the application renames itself, that variable isn't updated in the Eureka config. The Eureka clients are stuck associating with their dark url, which makes them unusable. Is there a way to accomplish refreshing that value in the client Eureka config?
This should incorporate spring-cloud/spring-cloud-connectors#239 or its replacement.
required by #81
As for now the dependency:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>provides a simple way to access Config server properties.
But it is missing a feature to natively download RAW text / binary based Resources.
This project provides this feature via io.pivotal.spring.cloud.service.config.OAuth2ConfigResourceClient which looks like a feature missing in:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-client</artifactId>
</dependency>I have managed to isolate the the fuctionality and created BasicConfigResourceClient which is OAuth2ConfigResourceClient without Oauth feature.
My proposal is to giveaway the required code to the mentioned spring library (https://github.com/spring-cloud/spring-cloud-config) and deprecate the classes in this project.
Request to implement the feature: spring-cloud/spring-cloud-config#1459
After a long support conversation with Jack at Vizient we found out that client applications using Vault support in their Config Server instances and Connectors 2.0.x.RELEASE were not getting auto-renewal of their tokens. In order to make this work, Jack had to add @EnableScheduling to the client application and then auto-renew of the tokens started to work. It seems in Spring Boot 2 that scheduling is not automatically turned on when a @scheduled annotation is used.
We should ensure that scheduling is enabled when a Developer add SCS Connectors into their client application bound to a Config Server using Vault backend.
GIVEN Config Server instance myconfig
AND myconfig is configured with a Vault backend
AND a client application named myapp
AND myapp is bound to myconfig
WHEN myapp has a valid Vault token added as spring.cloud.config.token to it's environment
THEN the Vault token at spring.cloud.config.token in myapp should be auto-renewed via SCS Connectors 2.0.x
It seems like ServiceInfoPropertySourceAdapter::appIsBoundToRabbitMQ does not consider the case when spring.rabbitmq.addresses(cluster mode) is used instead of spring.rabbitmq.host. In this case RabbitAutoConfiguration gets disabled silently.
Related issue: #36
Spring Cloud Finchley.SR2 came out and we should upgrade with a patch release of connectors.
The following error occurs when using Service Registry with a Gateway app in Spring Boot 2.1:
2019-03-13T16:08:05.15+0100 [APP/PROC/WEB/0] OUT The bean 'eurekaInstanceConfigBean', defined in class path resource [io/pivotal/spring/cloud/service/eureka/EurekaInstanceAutoConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.class] and overriding is disabled.
From looking into the issue, it looks like the eurekaInstanceConfigBean is used in both spring-cloud-services-spring-connector and spring-cloud-starter-netflix-eureka-client which are both sub-dependencies of spring-cloud-services-starter-service-registry. However, there seems to only be a conflict between these when the starter-gateway or gateway-core dependency is also present(which also contains a netflix-eureka-client sub-dependency). If I exclude the netflix-eureka-client dependency from the gateway dependency, it doesn’t make a difference. But if I exclude same from the service-registry dependency, the error doesn’t appear, but I don’t know if excluding this will cause further issues down the line.
I’ve reproduced this error with a gateway sample app. This error occurs when pushing the app to PCF. It requires redis-server to run. The versions used in this app are as follows:
This would include upgrading not only Spring Cloud to Greenwich.RC2 but also most recent Spring Boot 2.1 release.
Please see spring-cloud/spring-cloud-netflix#2545 for initial request in spring cloud netflix
Spring Boot 2 has changed a lot of the core framework of spring boot, including several things with the autowire process.
As a result, these connectors don't work in a spring boot 2 application as soon as it is deployed to PCF.
(Specifically, the Eureka binder crashes with a class not found exception because the relaxed property resolver been removed/moved/changed)
Exception:
Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'discoveryCompositeHealthIndicator' defined in class path resource [org/springframework/cloud/client/CommonsClientAutoConfiguration$DiscoveryLoadBalancerConfiguration.class]: Unsatisfied dependency expressed through method 'discoveryCompositeHealthIndicator' parameter 1; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'eurekaHealthIndicator' defined in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration$EurekaHealthIndicatorConfiguration.class]: Unsatisfied dependency expressed through method 'eurekaHealthIndicator' parameter 1; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'eurekaInstanceConfigBean' defined in class path resource [io/pivotal/spring/cloud/service/eureka/EurekaInstanceAutoConfiguration.class]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/springframework/boot/bind/RelaxedPropertyResolver
this was produced with:
Spring Boot 2.0.0.RELEASE
And version 1.6.1.RELEASE of this repository's discovery client library
Ultimately, the Apex library is from this repo https://github.com/pivotal-cf/spring-cloud-services-starters for the spring-cloud-services-starter-service-registry project, however I have a hunch that the code update is needed in this project. This problem probably impacts all the spring cloud services starters for PCF, I've just only tested it with Eureka.
2018-04-25T21:09:53.853+03:00 [APP/PROC/WEB/0] [OUT] 2018-04-25 18:09:53.852 INFO 14 --- [pool-7-thread-1] c.s.c.VaultTokenRenewalAutoConfiguration : Renewing Vault token e0d9[]57cf for 300000 milliseconds.
2018-04-25T21:09:53.898+03:00 [APP/PROC/WEB/0] [OUT] 2018-04-25 18:09:53.897 ERROR 14 --- [pool-7-thread-1] c.s.c.VaultTokenRenewalAutoConfiguration : Unable to renew Vault token e0d9[]57cf. Is the token invalid or expired?
while debugging i found that Vault respond:
Content type 'application/xml;charset=UTF-8' not supported","path":"/vault/v1/auth/token/renew-self"
I was able to fix it by adding to io.pivotal.spring.cloud.service.config.VaultTokenRenewalAutoConfiguration#buildTokenRenewRequest
headers.setContentType(MediaType.APPLICATION_JSON);
Hi
EurekaInstanceAutoConfiguration class has a dependency on RelaxedPropertyResolver(through SanitizingEurekaInstanceConfigBean). Spring boot 2 removed that class.
What is the roadmap for services-connectors, when are you planning on supporting Spring boot 2?
Looks like spring cloud eureka auto config has been already updated spring-cloud/spring-cloud-netflix@8d1a82f#diff-fd50bdd6abee6268d81bd6a5d0fc4dcd which is not a case for pivotal
Any feedback very much appreciated.
We're noticing an issue lately where applications will stand up fine locally but will not be able to stand up in PCF and the end result will end up being a lack of MongoTemplate bean. We've traced it down to the cloud connectors library but the exact issue is a bit beyond our current capabilities.
A sample project to reproduce is located here
That project will deploy perfectly fine into PCF until you bind a user provided service with a mongodb connection string in it. As soon as you provide that, the MongoTemplate bean will fail to be created and the application will fail to stand up its application context.
Depends on Spring Cloud Greenwich.RELEASE and Spring Boot 2.1.x.
depends on #92
I have one PCF foundation running 1.5.2-build.9 of SCS Tile and another running 2.0.2-build.6.
When I push code from https://github.com/mikegehard/pal-tracker-distributed/tree/does-not-work-with-scs-tile-2.0.x to the 1.5.x foundation, things work just fine.
When I push code from this tag to the 2.0.x foundation, I get the following error:
GET https://registration-pal-msg.apps.evans.pal.pivotal.io/health
GET https://backlog-pal-msg.apps.evans.pal.pivotal.io/health
GET https://allocations-pal-msg.apps.evans.pal.pivotal.io/health
GET https://timesheets-pal-msg.apps.evans.pal.pivotal.io/health
POST https://registration-pal-msg.apps.evans.pal.pivotal.io/registration
GET https://registration-pal-msg.apps.evans.pal.pivotal.io/accounts?ownerId=12
POST https://registration-pal-msg.apps.evans.pal.pivotal.io/projects
POST https://allocations-pal-msg.apps.evans.pal.pivotal.io/allocations
Assignment Failure: POST to https://allocations-pal-msg.apps.evans.pal.pivotal.io/allocations failed. Got response code: 500, and body: {"timestamp":1542306777346,"status":500,"error":"Internal Server Error","exception":"java.lang.IllegalStateException","message":"No instances available for registration-server","path":"/allocations"}
Please correct the above error and try again.
I have checked the Eureka dashboard and it looks like the application in question (registration-server) is properly registered.
I'm not sure why it breaks by just changing versions of the SCS tile because this graph seems to say they are compatible.
I'm seeing this exception with a very basic app. It works locally when connecting to a local Spring Cloud Config Server, but when I add the spring-cloud-pivotal-connector dependency to the POM, it throws this exception.
Here is the code with which I'm working:
https://github.com/pcf-guides/gs-configuration-server/tree/master/complete
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.springframework.boot.maven.RunMojo$LaunchRunner.run(RunMojo.java:418)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.ServiceConfigurationError: org.springframework.cloud.CloudConnector: Provider org.springframework.cloud.cloudfoundry.CloudFoundryConnector could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232)
at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.springframework.cloud.CloudFactory.scanCloudConnectors(CloudFactory.java:91)
at org.springframework.cloud.CloudFactory.<init>(CloudFactory.java:35)
at org.springframework.cloud.pcf.configserver.ConfigServerServiceConnector.onApplicationEvent(ConfigServerServiceConnector.java:32)
at org.springframework.cloud.pcf.configserver.ConfigServerServiceConnector.onApplicationEvent(ConfigServerServiceConnector.java:19)
at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:151)
at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:128)
at org.springframework.boot.context.event.EventPublishingRunListener.publishEvent(EventPublishingRunListener.java:100)
at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:59)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:286)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:961)
at org.springframework.boot.SpringApplication.run(SpringApplication.java:950)
at demo.Application.main(Application.java:10)
... 6 more
Caused by: java.util.ServiceConfigurationError: org.springframework.cloud.cloudfoundry.CloudFoundryServiceInfoCreator: Provider org.springframework.cloud.pcf.phd.PhdServiceInfoCreator could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232)
at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at org.springframework.cloud.AbstractCloudConnector.scanServiceInfoCreators(AbstractCloudConnector.java:53)
at org.springframework.cloud.AbstractCloudConnector.<init>(AbstractCloudConnector.java:33)
at org.springframework.cloud.cloudfoundry.CloudFoundryConnector.<init>(CloudFoundryConnector.java:32)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
... 20 more
Caused by: java.lang.NoSuchMethodError: org.springframework.cloud.cloudfoundry.CloudFoundryServiceInfoCreator.<init>(Lorg/springframework/cloud/cloudfoundry/Tags;[Ljava/lang/String;)V
at org.springframework.cloud.pcf.phd.PhdServiceInfoCreator.<init>(PhdServiceInfoCreator.java:22)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
... 31 more
X-Config-Token is mandatory on all requests to Spring Config Server when Vault is a property source.
PlainTextOAuth2ConfigClient doesn't set this header even when it's available on ConfigClientProperties and the request to config server fails with the following message:
Missing required header: X-Config-Token
I created a sample that replicates this issue.
This should incorporate spring-cloud/spring-cloud-connectors#240 or its replacement.
required by #83
Developers should be able to generate new projects using the SCS Starters 2.3.0.RELEASE for Config Server and Service Registry.
Spring Boot 2.3 has been out for some time so this is our story to provide a SCS Starters/Connector version 2.3.0 minor release that is based on Spring Boot 2.3.
Now based on Spring Cloud Greenwich.RELEASE
depends on #91
Based on Finchley.RC2 when it is released.
I am getting a stack trace which looks like this when trying to bind Hystrix Dashboard service in a PCF environment -
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'rabbitConnectionFactory' defined in class org.springframework.cloud.stream.binder.rabbit.config.RabbitServiceAutoConfiguration$CloudConfig: Bean insta
ntiation via factory method failed; nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.amqp.rabbit.connection.ConnectionFactory]: Factory method 'rabbitConnectionFactory' t
hrew exception; nested exception is org.springframework.cloud.CloudException: No unique service matching interface org.springframework.amqp.rabbit.connection.ConnectionFactory found. Expected 1, found 0
at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:599) ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1123) ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1018) ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:510) ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
It looks like the cloud-services-connector is not able to create a RabbitMQ related connection Factory and a downstream dependency ends up failing. This is specifically seen with version 1.1.0-RC1 of the connector and was working with version 1.0.1.RELEASE.
Can you please check and see if I am missing something here.
Application has configured OAuth2 as authentication mechanism. After cf push and cf bind-service - application starts successfully if only ONE is imported - either Service Registry starter or Spring Cloud Config.
If I have them both - App failed to start with this error:
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] APPLICATION FAILED TO START
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] Description:
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] Parameter 1 of constructor in org.springframework.boot.autoconfigure.security.oauth2.resource.ResourceServerTokenServicesConfiguration$RemoteTokenServicesConfiguration$UserInfoTokenServicesConfiguration required a single bean, but 2 were found:
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] - eurekaOAuth2ResourceDetails: defined by method 'eurekaOAuth2ResourceDetails' in class path resource [io/pivotal/spring/cloud/service/eureka/EurekaOAuth2AutoConfiguration.class]
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] - configClientOAuth2ResourceDetails: defined by method 'configClientOAuth2ResourceDetails' in io.pivotal.spring.cloud.service.config.ConfigClientOAuth2BootstrapConfiguration
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] Action:
2018-04-11T16:54:45.041+02:00 [APP/PROC/WEB/0] [OUT] Consider marking one of the beans as @Primary, updating the consumer to accept multiple beans, or using @Qualifier to identify the bean that should be consumed
Please see attached sample project.
I was able to get the app started successfully with Spring-boot-starter-parent 1.5.4. It Fails for 1.5.5 and later
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.5.4.RELEASE</version>
</parent>
Please advise.
Thanks.
The steps to reproduce:
cf cs p-service-registry standard my-srmy-srcf logs [appname] to tail outputmy-sr SI-GUID from dashboard URL via cf service my-sr outputNow the client app's log output will start to periodically (every few seconds) loop something like the following exception:
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT Caused by: org.springframework.web.client.HttpClientErrorException: 401 Unauthorized
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:94) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:79) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport$AccessTokenErrorHandler.handleError(OAuth2AccessTokenSupport.java:246) ~[spring-security-oauth2-2.3.3.RELEASE.jar!/:na]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.ResponseErrorHandler.handleError(ResponseErrorHandler.java:63) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:766) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:724) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:690) ~[spring-web-5.0.7.RELEASE.jar!/:5.0.7.RELEASE]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT at org.springframework.security.oauth2.client.token.OAuth2AccessTokenSupport.retrieveToken(OAuth2AccessTokenSupport.java:137) ~[spring-security-oauth2-2.3.3.RELEASE.jar!/:na]
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT ... 32 common frames omitted
2018-07-20T11:38:22.34-0700 [APP/PROC/WEB/0] OUT 2018-07-20 18:38:22.348 WARN 15 --- [tbeatExecutor-0] c.n.d.s.t.d.RetryableEurekaHttpClient : Request execution failed with message: Error requesting access token.
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT 2018-07-20 18:38:22.349 ERROR 15 --- [tbeatExecutor-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_GREETER-MESSAGES/greeter-messages-cs.apps.moscow.cf-app.com:[GUID] - was unable to send heartbeat!
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.shared.transport.decorator.RetryableEurekaHttpClient.execute(RetryableEurekaHttpClient.java:112) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator$3.execute(EurekaHttpClientDecorator.java:92) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.shared.transport.decorator.SessionedEurekaHttpClient.execute(SessionedEurekaHttpClient.java:77) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.shared.transport.decorator.EurekaHttpClientDecorator.sendHeartBeat(EurekaHttpClientDecorator.java:89) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.DiscoveryClient.renew(DiscoveryClient.java:846) ~[eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at com.netflix.discovery.DiscoveryClient$HeartbeatThread.run(DiscoveryClient.java:1399) [eureka-client-1.9.2.jar!/:1.9.2]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_172]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_172]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_172]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_172]
2018-07-20T11:38:22.35-0700 [APP/PROC/WEB/0] OUT at java.lang.Thread.run(Thread.java:748) [na:1.8.0_172]
I'm not sure what the best way is to stop a client app from spamming UAA after it's Service Registry is deleted along with it's service keys and bindings? Maybe a backoff request increasing the amount of time between requests for UAA? That only makes the issue smaller and doesn't resolve it entirely. Thoughts?
When configuration keys are deduced from a @ConfigurationProperties class, Spring Boot's spring-boot-configuration-processor will create a metadata file at compile time; this file is being used by various tools, especially IDEs.
If configuration keys are not declared in a configuration properties class, project maintainers should document those manually in a META-INF/additional-spring-configuration-metadata.json file. You can read more about this in the Spring Boot reference documentation and check metadata in Spring Boot itself.
It looks like this project is using configuration keys that are missing that metadata information:
spring.cloud.config.client.oauth2.client-id (used in ConfigClientOAuth2BootstrapConfiguration)eureka.client.oauth2.clientId (used in EurekaOAuth2AutoConfiguration )Could you document those configuration keys?
To make things easier, you can:
spring-configuration-metadata.json fileadditional-spring-configuration-metadata.json one (and create such a file if doesn't exist already).Config Server allows fetching resources in both plaintext and binary form.
spring-cloud-services-connector supports fetching plaintext resources but lacks support for binary resources. This will be useful for fetching binary files like images.
Implementation Notes
There is an existing client interface for fetching plaintext files from Config Server called PlainTextConfigClient. I propose refactoring this interface to be called ConfigResourceClient and it's existing methods getConfigFile() to be getPlainTextResource().
New getBinaryResource() methods can then be added to support retrieving binary resource.
I can work on a PR if there is consensus that the proposed changes make sense.
A customer indicated the Microsoft Azure Web App Firewall (WAF)[1] rule being triggered is (920320) - Missing User Agent Header for HTTP calls to UAA identity zone and Service Registry backing applications when using SCS 2.0.10. It appears the Spring Security OAuth client does not provide this header by default. On the surface this is not technically a problem with the OAuth spec but sometimes it can be an issue it appears, via Google searches. In this case, it appears this rule being triggered increases the load on the WAF. Here is the relevant Spring Security issue that mentions this behavior:
spring-projects/spring-security#4958
SCS Connectors client library should add a User-Agent header to all HTTP requests. The value of the User-Agent header is typically {product}/{version} {comment}.[2] In this case, I think we should make the value:
User-Agent: spring-cloud-services-connectors/{version}
Since the {comment} is optional, I don't see a reason for putting this into the header value. Please let me know if you have other ideas for the value.
[1] - https://docs.microsoft.com/en-us/azure/application-gateway/waf-overview
[2] - https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.