Document uses of eureka appName, vipAddress, with regards to spring cloud uses of serviceId, etc...

EurekaDiscoveryClient.getIntsances(String) doesn't use the serviceId or application name but the VIP Address to lookup instances:

	public List<ServiceInstance> getInstances(String serviceId) {
		List<InstanceInfo> infos = this.eurekaClient.getInstancesByVipAddress(serviceId,
				false);
		List<ServiceInstance> instances = new ArrayList<>();
		for (InstanceInfo info : infos) {
			instances.add(new EurekaServiceInstance(info));
		}
		return instances;
	}

here's the doc for DiscoverClient.getInstances(String serviceId)

	/**
	 * Get all ServiceInstances associated with a particular serviceId
	 * @param serviceId the serviceId to query
	 * @return a List of ServiceInstance
	 */
	List<ServiceInstance> getInstances(String serviceId);

So far I haven't noticed this as EurekaInstanceConfigBean uses spring.application.name as virtualHostName which is used by InstanceInfoFactory as VIPAddress

here's the doc for InstanceInfo:

    /**
     * Gets the Virtual Internet Protocol address for this instance. Defaults to
     * hostname if not specified.
     *
     * @return - The Virtual Internet Protocol address
     */
    @JsonProperty("vipAddress")
    public String getVIPAddress() {
        return vipAddress;
    }

        /**
         * Sets the Virtual Internet Protocol address for this instance. The
         * address should follow the format <code><hostname:port></code> This
         * address needs to be resolved into a real address for communicating
         * with this instance.
         *
         * @param vipAddress - The Virtual Internet Protocol address of this instance.
         * @return the instance builder.
         */
        public Builder setVIPAddress(String vipAddress) {
            result.vipAddressUnresolved = StringCache.intern(vipAddress);
            result.vipAddress = StringCache.intern(resolveDeploymentContextBasedVipAddresses(vipAddress));
            return this;
        }

so it looks like this implementation treats application name and VIP address as synonyms - and don't rely use VIP addresses anywhere - so that's why this bug went undetected.

So the proper implementation would be this:

	@Override
	public List<ServiceInstance> getInstances(String serviceId) {
		Application application = this.eurekaClient.getApplication(serviceId);
		List<ServiceInstance> instances = new ArrayList<>();
		if (application != null) {
			for (InstanceInfo info : application.getInstances()) {
				instances.add(new EurekaServiceInstance(info));
			}
		}
		return instances;
	}

Start at EurekaDiscoveryClient.getInstances(String) and compare its VIP-address lookup with DiscoverClient.getInstances(String). Read EurekaInstanceConfigBean, InstanceInfoFactory, and InstanceInfo to clarify how application name and VIP address relate. Done means serviceId lookup behavior and the appName/VIP documentation are corrected, with relevant tests passing.