Decouple /monitor endpoint from Spring Cloud Bus

[asarkar]

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:

1. 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 SpringCloudBusAwareService by default and keep existing functionality, and I should be able to override that using my own implementation.
2. Send a non-bus event and have some listener, if present, deal with it. Same as above, SpringCloudBusAwareListener can 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.

[spencergibb]

I think I'd prefer option 1.

[cforce]

+1 for any more leightweight option