Less state agent client

[cschroedl-gov]

I've removed the management of state from the AgentClient in the interest of making it more broadly useful.

These changes enable you to interact with multiple Consul Services and Checks using one AgentClient instance. Currently this Java API does not permit you to interact with multiple Consul Services and Checks via the same agent; rather you would need to construct a new AgentClient for every host-Service pair or for every host-Check pair that you wanted to interact with.

These changes also enable you to interact with checks and services if you do not have a reference to the AgentClient that registered them. For example, if the HealthClient gives you a list of Consul services failing their health checks and you want to deregister each of those services, the current Java API would require that you create an AgentClient for each of the failing services, re-register each service, and then deregister each one. The proposed changes permit you to create a single AgentClient and deregister each of the failing services. Currently the Java API cannot deregister a specific check. These changes add the ability to do so.

[rickfast]

Managing service registrations and de-registrations from outside the context of the service itself might make more sense using the Catalog API. We haven't implemented the /register and /deregister endpoints in the CatalogClient yet, but we could easily.

http://www.consul.io/docs/agent/http.html#catalog

That being said, I appreciate the idea of AgentClient being stateless. We made it stateful to make the API simpler, e.g. using pass() and warn() from the context of a registered service. I'll talk with our platform team on Monday and see what they think.

Thanks for the pull request!

[cschroedl-gov]

Hi @rickfast. You're extra-welcome. Thanks for the consideration. The Consul docs discourage you from relying exclusively on the catalog /register and /deregister endpoints.

/v1/catalog/deregister

The deregister endpoint is a low level mechanism for direclty removing entries in the catalog. It is usually recommended to use the agent local endpoints, as they are simpler and perform anti-entropy.

• http://www.consul.io/docs/agent/http.html#catalog_deregister

So while it would be awesome if we implemented the /catalog/(de)register endpoints in the CatalogClient, I think that is still a pretty solid argument for making the AgentClient a little more flexible to support the API's intended use, even if it comes at the expense of shifting the burden of state management to the user of the CatalogClient.

[rickfast]

team agreed stateless is better, so i merged it. thanks again!

[cschroedl-gov]

Sweet. De nada. Thank you! Here's hoping we can help each other out like this more in the future as our orgs hammer out use cases.