Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ClientBuilder needs connection test #239

Closed
jamesdcarroll opened this issue Dec 10, 2018 · 6 comments
Closed

ClientBuilder needs connection test #239

jamesdcarroll opened this issue Dec 10, 2018 · 6 comments

Comments

@jamesdcarroll
Copy link

Just starting out with SDK so built simple client per doc. No matter what orgURL or token I pass, however, there's no indication of success or failure. client is always not null and its not until I try to make a call that I get 401 for bad token or java.net.UnknownHostException for bad address. Seems like that should be a way to determine if the client is "ready"; either by throwing those errors from build() (or a boolean isReaday function that does) or setting client to null.

@bdemers
Copy link
Contributor

bdemers commented Dec 10, 2018

Hey @jamesdcarroll!

The client doesn't make any URL connections until you call a client method. I do like the idea of an isReady() method or something like that. That said these errors could also happen after the client is initialized (for example: if there was a network issue, or the API key was revoked)

Were you able to figure out what the issue was based on the descriptions in the exceptions/logs?

@jamesdcarroll
Copy link
Author

jamesdcarroll commented Dec 11, 2018

Yea, the funny thing is I knew the error going in as I was testing how it handled badURL or badToken so I could write the error handling code. But build() wouldn't throw anything so it was irking me that I couldn't really validate that what I had gotten back from build() was usable before I tried to make a call.

@bdemers
Copy link
Contributor

bdemers commented Dec 11, 2018

We could do this a few ways 🤔

client.isReady()
Clients.builder()
  .validateConnection()
  .build()

@jamesdcarroll
Copy link
Author

If it were me, I would vote for

Clients.builder()
  .build()
  
client.isValid();

That way I can write

Clients.builder()
  .build()
  if(client == null{
    for (Error err: client.errors){
         log.fatal("Connenction could not be built:" + err.message;
         return nulll;
     }
   }
 if (!client.isValid){
  for (Error err: client.errors){
         log.fatal("Connenction could not be validated:" + err.message;
         return client;
    }
   }

@bdemers
Copy link
Contributor

bdemers commented Jan 7, 2019

Trying to think about this a little more, in the case of an "invalid" client what would your application do? Throw an exception? Or go down another logic path?

arvindkrishnakumar-okta added a commit that referenced this issue Jun 11, 2020
align with open api spec update PRs #238 and #239
arvindkrishnakumar-okta added a commit that referenced this issue Jul 7, 2020
* upgrade to openapi v2.0.0 (#380)

* openapi spec update - remove 200 response from generateCsrForApplication

* Update OktaOrgCleaner.groovy

* Fix flaky GroupsIT#groupUserOperationsTest test

* Update GroupsIT.groovy

* OKTA-279039: Fix flaky ApplicationsIT associateUserWithApplication test

* Update GroupsIT.groovy

* Addressed review comment

* OKTA-289656: Add Applications API Integration Tests

* OKTA-289655: Add Admin role API Integration Tests

* Open API Csr rename update (#394)

* openapi csr rename update

* Merge pull request #396

* revert csr model rename (#398)

* revert csr model rename

* open api spec update (#401)

* open api spec update

* Open API spec - fix binding enum value for ProtocolEndpoint model (#406)

* OKTA-289662: Add SMS Templates API Integration Tests (#395)

* OKTA-289665: Add Linked Objects Integration Tests (#404)

* Updated Licence Header in LinkedObjectsIT (#410)

* OKTA-289668: Add User Type Integration Tests (#405)

* Open API Update - Sync with #238 #239  (#411)

* sync with open api pr #240 (#413)

* Open API Update - Sync with #241 (#412)

* Open API Update - Sync with #242 (#414)

* Open API Update - Sync with Open API PR 243 (#416)

* OKTA-289657: Add Factors API Integration Tests (#391)

* OKTA-289659: Add Event Hooks Integration Tests (#399)

* OKTA-289659: Add Authorization Server Integration Tests (#402)

* OKTA-289660: Add Inline Hooks Integration Tests (#400)

* Open API Update - Sync with Open API PR 244 (#418)

* fixed copy paste error

* OKTA-289661: Add Feature API Integration Tests (#397)

* Open API Update - Sync with Open API PR 249 (#420)

* OKTA-289663: Add IdP Integration Tests (#409)

* resolved merge conflicts with master changes

* removed Default prefix from few Idp builders

* added swagger code gen check for backward compatibility requirements per review comments

* fixed findbugs error

* updates per swagger regen code and one other update to Idp builder

* fixed expiresAt param type in spec

* deprecated old classes

* refactored InlineHooksIT - deactivate created hooks so it can be cleaned up after test

* Remove deprecated code (#426)

* Remove deprecated code

* fix typo

* fixed PMD violation - unused inports

* Update integration-tests/src/test/groovy/com/okta/sdk/tests/it/CrudTestSupport.groovy

Co-authored-by: Brian Demers <bdemers@apache.org>

* Update integration-tests/src/test/groovy/com/okta/sdk/tests/it/FactorsIT.groovy

Co-authored-by: Brian Demers <bdemers@apache.org>

* Update integration-tests/src/test/groovy/com/okta/sdk/tests/it/UsersIT.groovy

Co-authored-by: Brian Demers <bdemers@apache.org>

* Update integration-tests/src/test/groovy/com/okta/sdk/tests/it/GroupsIT.groovy

Co-authored-by: Brian Demers <bdemers@apache.org>

* minor improvements (#427)

* OKTA-308935: Create Migration Guide for Java Mgmt SDK v2.0.0 (#423)

Co-authored-by: Ivan Ezeigbo <56391095+ivanezeigbo-okta@users.noreply.github.com>
Co-authored-by: Brian Demers <bdemers@apache.org>
@VitaliiTytarenko-okta
Copy link
Contributor

The new method isReady was added to the DataStore.
see:

boolean isReady(Supplier<? extends Resource> methodReference);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants