Reintroducing OslcOauthClient from oslc-java-client to oslc4j-client library

[jadelkhoury]

Here are the major changes in this reintroduction:

lyo.client\oslc4j-client\src...\oslc4j\client\RootServicesHelper.java

• Copied from lyo.client\oslc-java-client\src...\client\oslc\jazz\JazzRootServicesHelper.java
• Renamed, since it is not related to JAZZ.
• Did not include the initFormClient() method
• Added some Consumer-related helper methods.

C:\Users\jelx25\git\lyo\lyo.client\oslc4j-client\src...\oslc4j\client\OslcClient.java

• Removed all code relating to "getCatalogUrl". This is in the rootServiceHelper class.
• getResource() & lookupServiceProviderUrl() methods need to throw exceptions: IOException, OAuthException, URISyntaxException

lyo.client\oslc4j-client\src...\oslc4j\client\OslcOAuthClient.java

• Copied from lyo.client\oslc-java-client\src...\client\oslc\OslcOAuthClient.java
• Introduced all getResource() methods to override all getResource() methods from parent. Otherwise, the authorisation header is not included when super method is called directly.
  • Is this an old bug?
• Did not implement update/create methods.
• getResourceInternal() creates a new httpClient, instead of using a clientPool. Is that a problem?

[berezovskyi]

I think we need to introduce an interface to make two clients interchangeable where possible.

[jadelkhoury]

Hi Jim! I am not sure how moving RootServicesHelper.java functionality into OslcClient helps. I needed this functionality even when I don't have an OslcClient. If we want to promote rootServices, why not make it more visible in the SDK with its own class, instead of hiding it within OslcClient?

@berezovskyi ! I can revert (almost) all changes to OslcClient, if I no longer make OslcOAthClient a subclass of OslcClient(). Instead OslcOAthClient has an attribute of type OslcClient that is then used to do the REST calls, once authenticated. But the central problem remains: the methods getResource() cannot share a common signature, since OslcOAuthClient needs to throw oauth exceptions. that is, I cannot define a common itnerface for both OslcOAthClient and OslcClient.

[jadelkhoury]

@berezovskyi I read now on the mailing list your point about defining a LyoResponse return value. We might need to do this together (to get it right the first time :-)) But I can prepare the grounds by reverting some of the changes on this branch.

[jadelkhoury]

This is not 100% complete, but I wonder if this new structure is more acceptable.

Please explore the proposed client application on https://github.com/OSLC/lyo-samples/pull/10.

[berezovskyi]

TODO:

• [x] throw IllegalStateException if the authorisation has not been performed. as it is, you throw IllegalArguemntException
• [x] fix OslcClient merge conflict

[jadelkhoury]

TODO:

• [ ] throw IllegalStateException if the authorisation has not been performed. as it is, you throw IllegalArguemntException
• [ ] fix OslcClient merge conflict

Fixed. But @berezovskyi ! Sure we should not fix some class names before merging?