This makes perfect sense since there is already support in the API.
Unfortunately Eureka also uses that information to set the Server
zones by default (duh?!) - see DiscoveryClient.getZone(InstanceInfo),
so unless you aggressively update them, the zones will all be the same
in all servers.
I fixed that problem by unconditionally applying the "domain as zone"
guess algorithm, which is fine unless you actually want to use
the Amazon metadata. So that's an outstanding problem
See gh-30
A EurekaInstanceConfig can declare a "zone" in its metadataMap, and then
it will be matched by the RibbonLoadBalancerClient. The zone of a server
is derived from the hostname - it is the whole host name or the host name
excluding the least significant subdomain (period separated identifier).
Fixes gh-29
Without extracting to autoconfig the @ConditionalOnMissingBean won't
always work because it is dependent on the order of the configuration
classes being processed (and autoconfig always somes last).
Because we were using Lifecycle to kick off the eureka registration the
local server port wasn't available yet. The change is to use an
ApplicationListener and listen for the event that contains the container
with its port instead.
Fixes gh-15
Dave Syer
Spencer Gibb
Christian Dupuis