spring-cloud / spring-cloud/spring-cloud-config
Decouple /monitor endpoint from Spring Cloud Bus
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 2k
- Forks
- 1.3k
- Avg merge
- 2d 59m
- Merged PRs (30d)
- 16
Description
In my case, deploying and maintaining a queue for something that's very infrequent (dynamic updates) can't be justified. Instead, I'm choosing to use service discovery and Actuator /refresh endpoint to achieve this over HTTP.
The problem with the monitor endpoint is that it brings in the baggage of Spring Cloud Bus whether I want it or not. I can use the controller and the parsing of various events, but I want to choose how to react to the push notifications. Currently, this is not possible as the controller sends out a Spring Cloud Bus specific event after parsing the notification.
I propose one of the following:
- Either the controller hands over the set of services to some bean, that is conditionally created if not already provided by the user. You can have a
SpringCloudBusAwareServiceby default and keep existing functionality, and I should be able to override that using my own implementation. - Send a non-bus event and have some listener, if present, deal with it. Same as above,
SpringCloudBusAwareListenercan be provided by default.
Of course, the above only works if the endpoint doesn't pull in the Bus libraries, which in turn fail if no binder is present on the classpath.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the /monitor endpoint, its notification parsing, and where it publishes the Spring Cloud Bus-specific event. Done means the endpoint can operate without Bus libraries, supports a user-provided reaction mechanism, and preserves the existing default behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, spring-boot
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100