v2/info call getting triggered internally while creating CloudFoundryClient and consuming v3 api's

[bhavinshah-mendix]

Hello,

Could someone assist me in grasping why the invocation of v3 API functions such as organizationsV3(), spacesV3(), or routesV3() etc., triggers the automatic invocation of v2/info when I create a CloudFoundryOperation client using CloudFoundryClient?

CloudFoundryClient Creation code:

cloudFoundryClient = ReactorCloudFoundryClient.builder()
        		.connectionContext(connectionContext)
                .tokenProvider(tokenProvider)
                .build();

OperationClient Creation Code:

cloudFoundryOperations = DefaultCloudFoundryOperations.builder()
                .cloudFoundryClient(cloudFoundryClient)
                .organization(StringUtils.EMPTY)
                .space(StringUtils.EMPTY)
                .build();

Fetching Organization:

ListOrganizationsRequest orgListRequest = ListOrganizationsRequest.builder().build();
ListOrganizationsResponse listOrganizationsResponse =  cloudFoundryClient.organizationsV3().list(orgListRequest).timeout(CF_REQUEST_TIMEOUT).block();

After investigation, I discovered that within _ReactorCloudFoundryClient.java, there's a checkCompatibility() method annotated with @PostConstruct, triggering the info() function. However, it remains uncertain whether this is the sole factor contributing to the observed behaviour.

looping @anthonydahanne , as I noticed your impressive contribution to the repository! Your dedication and expertise shine through in your work, so could help me :)

[Lokowandtg]

I will try to replace the internal usages of /v2/info with corresponding calls in /3/info and in "/". Here is the mapping for calls I have found:

/v2/info.name						/v3/info.name
/v2/info.build						/v3/info.build
/v2/info.support					/v3/info.links.support.href
/v2/info.version					/v3/info.version
/v2/info.description				  	/v3/info.description
/v2/info.authorization_endpoint				/.links.login.href
/v2/info.token_endpoint					/.links.uaa.href
/v2/info.min_cli_version				/v3/info.cli_version.minimum
/v2/info.min_recommended_cli_version			/v3/info.cli_version.recommended 
/v2/info.app_ssh_endpoint				/.links.app_ssh.href
/v2/info.app_ssh_host_key_fingerprint			/.links.app_ssh.meta.host_key-fingerprint
/v2/info.app_ssh_oauth_client				/.links.app_ssh.meta.oauth_client
/v2/info.doppler_logging_endpoint			/.links.logging.href
/v2/info.api_version					/.links.cloud_controller_v2.meta.version
/v2/info.osbapi_version					missing	
/v2/info.user						missing

For the two "missing" fields I could not find a corresponding field in the other endpoints. Let's see if they are used at all.

[markdboyd]

Is there any ETA for these fixes to land? They're blocking some of our customers from migrating from V2 to V3 APIs in their apps.