cloudfoundry / cloudfoundry/cf-java-client

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

Open
#1,229 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Java
Stars
334
Forks
319
PR merge metrics
No merged PRs in 30d

Description

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 :)

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read ReactorCloudFoundryClient.java and its @PostConstruct checkCompatibility() path; trace whether creating DefaultCloudFoundryOperations or calling organizationsV3().list() invokes info(). Reproduce the supplied client setup and establish the source of the v2/info call and the intended behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.