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

remove client config and unify authentication methods #236

Merged
merged 5 commits into from
Oct 2, 2018

Conversation

lucidd
Copy link
Member

@lucidd lucidd commented Jul 3, 2018

This PR removes the ClientConfig since its generally insufficient if you want to customize http client config. Instead a user can now configure the http client backend they want to use and then simply pass it to us. Since the token has since been in the configuration each call method now uses an AuthMethod parameter to decide how to authenticate the call. AuthMethod either contains the password authentication parameters or a token. Overall this PR leads to a lot less code more unification between call method variants and also gets rid of the non thread safety we had due to the mutable config.

@lucidd lucidd added this to the Version 1.0.0 milestone Jul 3, 2018
@lucidd lucidd changed the base branch from master to master-async-http-client July 3, 2018 08:19
@renner renner self-requested a review July 6, 2018 11:26
@lucidd lucidd changed the base branch from master-async-http-client to master August 7, 2018 08:40
Copy link
Member

@renner renner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks good to me in general, just consider my comments on the patch and please fix all the javadoc warnings that show up in travis.

config.put(ClientConfig.PROXY_PASSWORD, settings.getPassword());
}
}
public SaltClient(URI url, AsyncConnection asyncHttpClient) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not really clear here: what does this object represent, a connection or an HTTP client? Let's maybe rename one of them (the class or variable name)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah the name is still the old but at this point its more of a http client then a connection. i will rename it.

@@ -15,13 +18,14 @@
private static final String PASSWORD = "saltdev";

public static void main(String[] args) {
CloseableHttpAsyncClient httpClient = TestUtils.defaultClient();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the defaultClient() is something that could be used in production I would suggest to move it away from TestUtils to a better place.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't think its suitable for production since its disables all timeout which you probably don't want in a production environment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't or shouldn't we provide some reasonable defaults for those timeouts, for example the values that were used before? I think in order to make it easy for people to get started quickly we could provide reasonable defaults with this default client.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i added a helper method for creating an async http client with the default timeout values used in our config before

Copy link
Member

@renner renner Oct 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, so I think we should use HttpClientUtils.defaultClient() everywhere throughout the examples, and even throughout the tests while removing the currently still existing TestUtils.defaultClient()? If we don't remove the TestUtils method for a reason then let's use it only in tests, please.

@lucidd lucidd force-pushed the master-config-cleanup branch 2 times, most recently from e72bfc9 to 71baa12 Compare August 15, 2018 09:56
@lucidd
Copy link
Member Author

lucidd commented Aug 15, 2018

@renner javadoc warning are addressed

@lucidd lucidd force-pushed the master-config-cleanup branch 2 times, most recently from c93ebe1 to c7c77ec Compare August 28, 2018 12:59
private final JsonParser<T> parser;
public static HttpAsyncClient defaultClient() {
//TODO
return null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lucidd: The default client can now be generated via HttpClientUtils as far as I understand, so should we remove the TODO and this whole method here?

import com.suse.salt.netapi.event.WebSocketEventStream;

import java.net.URI;


Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unnecessary new line here.

@renner renner merged commit 21d580a into master Oct 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants