I was reviewing the new features in Dalston. I was curious how to appropriately use the ServiceRegistry for Consul.
In both the register and deregister methods, it uses a ConsulRegistration object. Where do I get this object to us in the deregister?
I checked DiscoveryClient and it seems to return ServiceInstance.
The scenario I am thinking of is to remove zombie services and I was to deregister an instance that I believe is bad.
You can autowire ConsulRegistration object with Spring Boot.
The below test class might be helpful for you.
Spring Cloud Consul: ConsulServiceRegistryTests
Related
Spring Cloud Config uses Spring Cloud Bus uses Spring Cloud Stream to push configuration change events to clients.
My question - since I was yet to find it - is: what kind of queues does Spring Cloud Config create when it starts up? I noticed that it creates topics/queues automatically, but are they temporary, i.e. bound to the lifecycle of the server/client or durable. Do they have to be removed manually?
EDIT: I am using Spring Cloud Hoxton.SR3 with Spring Boot 2.2.5.RELEASE (or higher)
Thanks in advance!
I've built up a Spring Cloud Config Server integrated using Spring Cloud Bus via Kafka for refreshing properties dynamically. I've another application that is Spring Cloud Gateway that consumes those properties and refreshes them dynamically.
One of the things I'm struggling with is if I (unintentionally) update a bad property (for example: spring.cloud.gateway.routes[0].predicates[0]=Path=/demo/{demoId\:[0-9]+}, here backslash is something that is wrong here) in a Spring Gateway route.
The routing breaks in Spring Cloud Gateway with the error something like unable to initialize bean GatewayProperties and things starts behaving weirdly.
Two questions:
Is there a way to ignore bad config refresh events? Probably skipping refresh event that has a bad config.
If it's possible, Is there a way to evaluate those properties even before those are applied to the Spring context?
We are using spring cloud sidecar with a node.js application. It would be extremely useful if we could serve up configuration from the spring configuration server and make that configuration available to the node application.
I would like the sidecar to resolve any property place holders on behalf of the node application.
The sidecar already hits the configuration server and I know that the Environment in the sidecar WILL resolve all the property place holders. My problem is, how do I efficiently expose all those properties to the node application? I could create a simple rest endpoint that accepts a key and then returns environment.getProperty(key) but that would be extremely inefficient.
I am thinking that I could iterate over all property sources (I know that not all property sources can be enumerated), collect a unique set of the names and then turn around and call environment.getProperty() for each name....
But is there a better way?
I have to imagine this is functionality that others have needed when using Spring Cloud in a polyglot environment?
I want to add some lookup before the Spring context is loaded, which is ideally on the bootstrap phase of Spring Cloud (When it lookup for Configuration Server, Cloud connectors etc). How can I make my code to be executed on that phase ?
What I want to do is query Vault to get all my databases secrets and api keys and set the properties, I know I can encrypt with Spring Cloud Config, but I liked the strong box of Vault. (The integration with Vault part I can handle)
As I saw in the code of Spring Cloud Config, the bootstrap configuration is auto-configured by using the class org.springframework.cloud.bootstrap.BootstrapConfiguration on the resources/META-INF/spring.factories file, the same which you can use to register new auto configuration classes for Spring Boot, as reference you can refer to the file on the project here. This will make your configuration be started and registered before the "normal" application context.
I have two database configuration javaconfig classes - one for JPA purposes with transactionManager() and entityManagerFactory() #Bean methods and one config class for non-JPA JDBCTemplate based query submission to access data from that database. The overall idea is to read using JDBCTemplate to read data and persist the data, after transformation, into the JPA based datasource. I am using Spring Boot to enable auto configuration. My test fails with:
java.lang.IllegalArgumentException: Not an managed type:
I have both spring-boot-starter-jdbc and spring-boot-starter-data-jpa in my build.gradle. My gut feeling is that the two data sources are in collision course with each other. How do I enforce the use of each of these datasources for the two use-cases that I mentioned earlier - one for JPA and another for JDBCTemplate purposes?
Details (Added after Dave's reply):
My service classes have been annotated with #Service and my repository classes have #Repository. Service uses repository objects using #Autowired though there are some services that are JDBCTemplate-based for data retrieval.
More complex depiction of my environment goes as follows (logically): JDBCTemplate(DataSource(Database(DB2)))--> Spring Batch Item Reader;Processors; Writer --> Service(Repository(JPADataSource(Database(H2)))). Spring batch item processors connect to both databases using services. For spring batch, I am using a H2 Job repo database (remote) to hold job execution details. Does this make sense? For Spring batch, I am using de.codecentric:spring-boot-starter-batch-web:1.0.0.RELEASE. After getting past the entityManagerFactory bean not found errors, I want to have control over the wiring of the above components.
I don't think it's anything to do with the data sources. The log says you have a JPA repository for a type that is not an #Entity. Repositories are automatically scanned from the package you define #EnableAutoConfiguration by default. So one way to control it is to move the class that has that annotation to a different package. In Boot 1.1 you can also set "spring.data.jpa.repositories.enabled=false" to switch off the scan if you don't want it. Or you can use #EnableJpaRepositories as normal.