My code is:

URI uri = URI.create("http://127.0.0.1:8000");
SaltStackClient client = new SaltStackClient(uri);
 try {
    Token token = client.login("username", "passoword", PAM);
    ScheduledJob job = client.startCommand("*", "cmd.run", param, kwargs);
    System.out.println(job.getMinions());
    Map<String, Job> jobs = client.getJobs(); 
    ......

Excetion happened when executed to Map<String, Job> jobs = client.getJobs();
I can get minions and run commands,but getjobs not work.
The exception message:

Exception in thread "main" com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 125 path $.return[0]..Target-type
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:200)
    at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:40)
    at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:187)
    at com.google.gson.internal.bind.MapTypeAdapterFactory$Adapter.read(MapTypeAdapterFactory.java:145)
    at com.google.gson.internal.bind.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:40)
    at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:81)
    at com.google.gson.internal.bind.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:60)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:103)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:196)
    at com.google.gson.Gson.fromJson(Gson.java:810)
    at com.google.gson.Gson.fromJson(Gson.java:775)
    at com.suse.saltstack.netapi.parser.JsonParser.parse(JsonParser.java:91)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.executeRequest(HttpClientConnection.java:193)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.request(HttpClientConnection.java:85)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.getResult(HttpClientConnection.java:73)
    at com.suse.saltstack.netapi.client.SaltStackClient.getJobs(SaltStackClient.java:375)
    at com.cmdb.cron.CheckSaltClient.main(CheckSaltClient.java:63)
Caused by: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 125 path $.return[0]..Target-type
    at com.google.gson.stream.JsonReader.nextString(JsonReader.java:837)
    at com.google.gson.internal.bind.TypeAdapters$13.read(TypeAdapters.java:358)
    at com.google.gson.internal.bind.TypeAdapters$13.read(TypeAdapters.java:346)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$1.read(ReflectiveTypeAdapterFactory.java:103)
    at com.google.gson.internal.bind.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:196)
    ... 16 more

http://stackoverflow.com/questions/40558646/gson-parsing-error-with-salt-net-api

ResultInfo class contains StartTime class
public class ResultInfo { @SerializedName("StartTime") private StartTime startTime;

But StartTime class has
public class StartTime { private final String dateString;

I think this creates a problem in parsing json. Please take a look at the SOF thread.

Currently, timezone returned as part of parsed Date objects is local timezone of the client. This timezone can vary from user to user, even on the same computer.

One of the following should be implemented,

• Server's timezone would be detected and used by the Date parser
• Alternatively, server's timezone should be configurable in ClientConfig

This will allow us to use the call objects to generate input for functions like state.high and state.low.

I want to excute the folloow salt-api with salt-netapi-client。 Has the funtion already been added,or I did not find it? Someone show me a model please,thank you!

curl -k https://192.168.1.72:8000 -H "Accept: application/x-yaml" -H "X-Auth-Token: c203344e84448e60582acc662d0108d69948dbfd" -d client=local -d tgt='slave1' -d fun='cp.push' -d arg="/opt/tmp/tmp1.tar.gz"

Runner calls might return Python errors and stack traces as the result, eg.

salt/run/20170212133049657941/ret       {
    "_stamp": "2017-02-12T11:30:51.183745", 
    "fun": "runner.jobs.list_jobs", 
    "jid": "20170212133049657941", 
    "return": "Exception occurred in runner jobs.list_jobs: Traceback (most recent call last):\n  File \"/usr/lib/python2.7/site-packages/salt/client/mixins.py\", line 348, in low\n    data['return'] = self.functions[fun](*args, **kwargs)\nFile \"/usr/lib/python2.7/site-packages/salt/runners/jobs.py\", line 333, in list_jobs\n
ret = mminion.returners['{0}.get_jids'.format(returner)]()\n  File \"/usr/lib/python2.7/site-packages/salt/returners/local_cache.py\", line 343, in get_jids\nfor jid, job, _, _ in _walk_through(_job_dir()):\n  File
\"/usr/lib/python2.7/site-packages/salt/returners/local_cache.py\", line 69, in_walk_through\n    for final in os.listdir(t_path):\nOSError: [Errno 2] No such file or directory: '/var/cache/salt/master/jobs/32'\n", 
    "success": false, 
    "user": "admin"
}

We get a gson conversion Exception in the assumption the result is expected to be an Object and not a String:

Stack trace:com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected
BEGIN_OBJECT but was STRING at line 1 column 14 path $.return[0]

It would be great if we had a meaningful Exception instead, especially one containing the Python stack trace that could be put in logs for later troubleshooting.

Perhaps I'm doing something wacky, but I'm unable to get the MinionList targetType to work with a list input.

String commaSeparated = "jessievm";
List<String> mytargetList = Arrays.asList(commaSeparated);
Target finaltarget = new MinionList(mytargetList);
scheduledJob = client.startCommand(finaltarget, myfunction, saltArguments, kwArgs);

Passing in a List seems to result in not sending a message to the salt master, thus leaving an a null ScheduledJob causing havoc. Passing in a plain "jessievm" string seems to work as expected.

😄

Hello,
SSHTarget is used in some the examples provided, but it's not found in release 0.9.0 jar.
What am I missing here?
Thanks.

Currently, SaltClient.startCommand sets fixed lowstate data sent towards API, which limits the usage in certain way.

Following usecase specifies the needs for this.
As Job cache method prep_jid can accept passed_jid via lowstate data, users / systems might be able to craft custom JID before actual job execution, thus bypassing several race conditions when JID wasn't known prior to actual execution.

Xor type adapter should not assume left to be SaltError instead this logic should moved to ResultTypeAdapter.

As seen in stats_response.json used by the tests the there is a Requests field in CherryPy Applications. As of now i could not find any documentation of its structure but as @moio mentioned looking at the source or asking IRC/Mailing List might reveal some details. I will look into this but feel free to leave a comment if you found some information.

Tested on '2015.8.12: previously the status.uptime` returned number, now it returns a dictionary. We should adjust the type.

We should make the library jar file available via maven central so it will be easier for anyone to include it with their project via pom.xml.

While working on #42 i found a few problems that i want to discuss and get some feedback first before changing anything.

testLoginFailure

I'm not completely sure what testLoginFailure tests. From what i can tell i would say it was supposed to test logging in with wrong credentials but since it throws the exception for all return codes other than OK and ACCEPTED this test passes in a lot of cases when it shouldn't.

Of course we could check if the exception message contains the right error code but i think it would be better to not leak the HTTP return codes and instead throw more meaningful exceptions so it is easier to handle different errors differently.

stubFor vs verify

Wiremock allows to specify matching rules in both stubFor and verify. While stubFor
is basically a router to determine which requests get served what response, verify serves the role of an assertion for the test. The problem is when a request does not match the stubFor it gets served a 404 which results in the test failing with a SaltStackException containing the 404. There is not a lot of information about what went wrong. On the other hand if a request does not match the verify rules both expected and actual request(s) are printed as part of the failure.

So my suggestion would be using a stubFor that accepts all requests and shifting the the verification completely to verify.

The expr_form argument is deprecated and must be replaced very soon with tgt_type:

DeprecationWarning: The target type should be passed using the 'tgt_type' argument instead of 'expr_form'. Support for using 'expr_form' will be removed in Salt Fluorine.

Salt is currently at the Oxygen release and Fluorine will be the next one.

Not sure if this is actually a problem, it might be even expected: Running the minimal example below does apparently not shutdown the event processing thread completely, even though shutdownNow() is used in close(). Instead the process keeps on running until terminated manually:

try (EventStream stream = client.events()) {
    stream.addEventListener(new EventListener() {
        @Override
        public void notify(String data) {
        }
        @Override
        public void eventStreamClosed() {
        }
    });
}

Hi, I found this project very useful, and using it actively.

I m facing an issue whenever Saltstack returns some syntax or template error, library is not able unmarshall the API returned JSON to Object and is causing JSON unmarshall exception.

Example error response from Salt API server:

{"return": [{"ubuntu": ["Rendering SLS 'base:test' failed: Jinja error: 'NamespacedDictWrapper' object has no attribute '__call__'\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/salt/utils/templates.py\", line 366, in render_jinja_tmpl\n    output = template.render(**decoded_context)\n  File \"/usr/lib/python2.7/dist-packages/jinja2/environment.py\", line 969, in render\n    return self.environment.handle_exception(exc_info, True)\n  File \"/usr/lib/python2.7/dist-packages/jinja2/environment.py\", line 742, in handle_exception\n    reraise(exc_type, exc_value, tb)\n  File \"<template>\", line 6, in top-level template code\nAttributeError: 'NamespacedDictWrapper' object has no attribute '__call__'\n\n; line 6\n\n---\ntest-file:\n  file.append:\n    - name: /data/test.txt\n    - text\n      - Test from API\n      - URL={{pillar('TM_URL')}}    <======================\nTraceback (most recent call last):\n  File \"/usr/lib/python2.7/dist-packages/salt/utils/templates.py\", line 366, in render_jinja_tmpl\n    output = template.render(**decoded_context)\n  File \"/usr/lib/python2.7/dist-packages/jinja2/environment.py\", line 969, in render\n    return self.environment.handle_exception(exc_info, True)\n[...]\n---"]}]}

code:

 SaltClient client = new SaltClient(URI.create(SALT_API_URL));
        client.getConfig().put(ClientConfig.SOCKET_TIMEOUT, 3000);
        Token token = null;
        Map<String, Map<String, Object>> minions = null;
        try {
            client.login(USER, PASSWORD, AuthModule.PAM);
           minions = client.getMinions();
         }

When I try to get all minions by using getMininons(),an error occured to me:
"Caused by: java.net.SocketTimeoutException: Read timed out"
But when all minions test.ping success ,I can get all minions.however if any minion can not test.ping,the error above come to me .

Thank for your reply.

Unit tests are a great resource. But there should also be a way of verifying that API works correctly vs. real Salt server instead of just a wiremock.

Recently, there are dozens and dozens of Salt calls added to the library. Most of these are simple, convenience mappings and they probably work just fine today. But what happens if Salt changes - eg. upstream decision to change something? Then maybe "status.diskusage" no longer exists for some reason, or it is replaced with a different return format. As is, we can't detect that. There is no automatic tests to verify the API remains valid (please correct me if I'm wrong here!).

There should be an automatic way to test this entire API vs. a real server.

1. automatically deploy container(s) and install salt-master and salt-minion(s) in it
2. test all API calls vs. that master

Comments welcome.

trying to listen for events on salt's event bus.
salt version report:
Salt: 2015.5.10
Python: 2.7.12 (default, Dec 6 2016, 12:45:38)
Jinja2: 2.8
M2Crypto: 0.25.1
msgpack-python: 0.4.8
msgpack-pure: 0.1.3
pycrypto: 2.6.1
libnacl: Not Installed
PyYAML: 3.12
ioflo: Not Installed
PyZMQ: 14.0.0
RAET: Not Installed
ZMQ: 4.0.8
Mako: Not Installed
Tornado: 4.4.2
timelib: 0.2.4
dateutil: 2.5.3

postman request:
GET /ws HTTP/1.1
Host: 10.214.229.16:8000
Content-Type: application/json
X-Auth-Token: 0de9a94ef8c44b73a1f82feed26009dd8d293f2e
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: s65VsgHigh7v/Jcf4nXHnA==
Upgrade: websocket
Connection: Upgrade
Cache-Control: no-cache
Postman-Token: 5a78cf06-b177-0416-f647-3da1c4ef09a6

response generated:

#traceback {
    color: red;
}
</style>
</head>
<body>
    <h2>404 Not Found</h2>
    <p>The path '/ws' was not found.</p>
    <pre id="traceback"></pre>
    <div id="powered_by">
        <span>
    Powered by 
            <a href="http://www.cherrypy.org">CherryPy 8.1.2</a>
        </span>
    </div>
</body>

can you help me out with the solution for this above problem??

Hi everyone,
I was just browsing through SaltStack sources and I was thinking about
their API we consume. One particular thing worries me a bit: how much stable is
it?

Usually when one works with any kind of API, he/she assumes it is kind of
stable (ideally between major versions of the project). When looking at the
sources of SaltStack, I found out that their API is just a thin layer that
"translates" requests to their backend. And not only to backend - in some cases
the API relies on external libraries as well: for instance, in case of /stats
resource, the SaltStack API forwards to the CheeryPy lib.

If the facts above are right, then any minor change in SaltStack backend
or in an API of external library (e.g CherryPy) would affect the SaltStack API
as well. This doesn't completely resemble a reliable interface.

My question is: do they guarantee stable API at least between major
versions? If the answer is yes, which I hope for, then I guess we are fine - I can
imagine we'd just release java clients matching to SaltStack major versions.
Otherwise we're in the trouble as it'd be our role to deal with it and
"stabilize their API". What do you think? Maybe I should directly ask SaltStack
guys as well.

The SaltAPI allows for setting a expr_form option which modifies what is selected by tgt.
http://docs.saltstack.com/en/latest/ref/clients/index.html#salt.client.LocalClient.cmd

By default glob is used, and it would nice to be able to select others such as nodegroup.

Salt's api supports additional methods of interaction. Specially, it would be helpful to support local_batch and runner in addition to the existing local client type.

local_batch would allow for using the batch interface, while runner would allow for kicking off orchestrate jobs.

http://docs.saltstack.com/en/latest/topics/netapi/index.html#client-interfaces

@renner can you clarify what the kwargs parameter in methods like startCommand is used for? As far as i can tell it only adds additional properties to the JSON but i don't know what i would use that for.

Initially i thought it would be to pass parameter to the remote function by name instead of by position but after a bit of research i found out that the kwarg property is used for that.

all expr_forms
maybe some relevant documenatation

• pcre - Perl style regular expression
• grain - Match based on a grain comparison
• grain_pcre - Grain comparison with a regex
• pillar - Pillar data comparison
• pillar_pcre - Pillar data comparison with a regex
• range - Use a Range server for matching
• compound - Pass a compound match string

Work in progress branch

When kicking off a job, the saltapi response includes a minion array listing minion names and the job results. If the job is long running, you can iterate through the number of minions that are targeted, and spin waiting for all to return.

Please support querying this minion listing.

The idea is to provide a low level interface to call salt modules without the need to have a Call object. This should make it easy to call functions that are not implemented as Call objects yet.

there is a very short default idle timeout on the websocket container when using Tyrus:
(Java)
got event: salt/job/20151026074505629209/ret/balthazarServer
with data:
[fun_args:[], jid:20151026074505629209, return:[datasets:[NAME USED AVAIL REFER MOUNTPOINT, core 6.58M 7.81T 5.73M /core, core/docker 170K 7.81T 170K /var/lib/docker]], retcode:0.0, success:true, cmd:_return, _stamp:2015-10-26T07:45:06.291380, fun:zfs.list, id:balthazarServer]

saltReactor stream closed

(salt master api log)
2015-10-26 07:52:19,224 [ws4py ][DEBUG ][40] Closing message received (1000) '"Session closed by the container because of the idle timeout."'
2015-10-26 07:52:19,225 [ws4py ][INFO ][40] Terminating websocket [Local => 172.17.0.74:8000 | Remote => 172.17.42.1:43364]

I believe this is configurable:
https://tyrus.java.net/apidocs/1.3/javax/websocket/WebSocketContainer.html#setDefaultMaxSessionIdleTimeout(long)

but all the config objects seem to be private.... how do i pass a custom config with a long timeout?

Hi all.
So, I've been trying to set up and connect a toy netapi client to a saltapi websocket. My understanding (please correct me if I'm wrong) is that websockets in saltapi are implemented by rest_tornado* (http://salt-api.readthedocs.org/en/latest/ref/netapis/all/saltapi.netapi.rest_tornado.html) which I installed in my saltstack POC installation.

I managed to connect allright on the server itself (just an ubuntu VM) with a mad-max kind of client (https://github.com/winglet/code-garage/tree/master/saltstack-netapi-garage) but when I'm trying to replicate that with a simple java websockets implementation I get a 404 response from salt-api daemon which on the java client translates to a handshake exception.

I could possibly research this a bit further before dumping logs etc here but the main question right now I guess is whether this direction (salt-api websockets that is) is of any interest to the netapi project.

• This is not clear in the salt-api online documentation.

Travis could generate javadocs with every build, at least as long as it is the master branch that's being built. An always up to date development version of the javadocs can then be automatically pushed to github pages I guess. Note that the current v0.1.0 javadocs were pushed manually.

How others are doing this:

• http://benlimmer.com/2013/12/26/automatically-publish-javadoc-to-gh-pages-with-travis-ci/
• https://github.com/Jasig/cas/blob/master/travis/push-javadoc-to-gh-pages.sh

When looking at SaltStackClientTest.java it seems that we do not run checkstyle on the test classes, there is long lines and star imports.

When I run the following code: result = localCall.callSync(client, globTarget, saltUser, saltPassword, AuthModule.PAM); result is an empty map.

The current generically used DateAdapter is null-safe per default: whenever an expected date is missing in the returned JSON the library would just silently accept that. Instead we should probably fail per default and rather support the declaration of optional fields allowing us to accept missing values for selected date fields that may or may not be returned by the API.

I use Jobs.listJob(jid).callSync(saltClient) to get the JobInfo . If the jid is invalid for example 123 , I will get a IllegalStateException .
com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_ARRAY at line 1 column 107 path $.return[0].Target-type
However i run the command in shell
$ salt-run jobs.list_job 123

I will get the result like this:
Arguments:
Function:
unknown-function
Result:
----------
StartTime:
Target:
unknown-target
Target-type:
User:
root
jid:
123

A lot of types have no constructor because they are usually just created by gson. It would be good to have constructors for those. Also a mapping function for types with a single type parameter would be good.

The default read timeout is 10 seconds. Using that default timeout on a master/api with default timeout (no change in master config), I get timeout exception if a host happens to be down. Raising the read timeout above 15 seconds, that is 16 or higher will return the json that does not contain the missing host. That should be the right behavior. Should ClientConfig.SOCKET_TIMEOUT be a little bit higher (maybe 20 seconds) so that one minion timeout does not affect the response when using default settings for library+api+master?

For me it would be easy to override ClientConfig.SOCKET_TIMEOUT, but I think the default should work even if something goes wrong.

This is not a serious issue, but it would be nice to get rid of those stacktraces in the test output, see for instance here (and go to line 1824 by manual scrolling if necessary).

The current logout() method returns a Result<String>, which in my test environment weirdly even says "Welcome". While posting to the /logout endpoint should actually return "Your token has been cleared", I guess we could change the return type of the logout() to boolean (in case the string matches the above).

Hi guys,

I am running into a problem when trying to use this module. I am trying to issue an ad-hoc command to a minion via the run() method in the SaltStackClient class. Here is the code I am trying:

SaltStackClient saltClient = new SaltStackClient("http://salt-server");
ResultInfo resultInfo = saltClient.run(
        "user",
        "pass",
        AuthModule.PAM,
        "local",
        new MinionList("myhostname"),
        "cmd.run",
        Collections.singletonList("pwd"),
        Collections.emptyMap());

The above code produces a NullPointerException when trying to do resultInfo.getResult("myhostname") to get the output. I did some debugging and grabbed the request body that gets generated and used Postman to verify that the server accepts it and sends a response. Here is an example:

{
  "return": [
    {
      "myhostname": "/root"
    }
  ]
}

I think there is a mismatch between the structure of this response and what the json parser is expecting. Can you confirm this suspicion? I am using version 0.6.0 of this library and tried with Salt versions 2015.8.0 and 2015.5.2.

Hi,
Sorry for posting here but I didn't know where to go.
Can someone give me an example how to use Token authentication for subsequent requests after login?
I need to use it in web application but could not find any example of this.
Thanks
Jarek

com.suse.salt.netapi.exception.SaltException: javax.websocket.DeploymentException: Handshake response not received.
at com.suse.salt.netapi.event.EventStream.initializeStream(EventStream.java:108)
at com.suse.salt.netapi.event.EventStream.(EventStream.java:84)
at com.suse.salt.netapi.client.SaltClient.events(SaltClient.java:544)

The module classes and functions have not been documented so far since they are only bindings to the salt module functions and the documentation already exists there. Furthermore our library may work with different salt versions which could have slightly different but documented behavior. In that case our documentation would never be correct since it always depends against which salt version you run it.

One suggestion by @isbm is to provide links in the documentation of each function/module to the latest documentation on the salt side. That wouldn't be always correct but from there its easy to switch to the documentation of a different version.

Some test code

         URI uri = URI.create(saltapiurlString);

         SaltStackClient client = new SaltStackClient(uri);
        try {
            Token token = client.login(saltuser, saltpassword, AuthModule.PAM);
            System.out.println(token.getToken());
            List<String> param = new ArrayList<>();

I can use

[birdzhang@myhost:salt]$ curl -k http://192.168.0.72:8000/login -H "Accept: application/x-yaml" -d username='ops' -d password='ops' -d eauth='pam'
return:
- eauth: pam
  expire: 1440012727.2649801
  perms:
  - .*
  - '@runner'
  - '@wheel'
  start: 1439969527.2649801
  token: ecbd8f11d469ddafa1c91fb97cad343b3b931d65
  user: ops

Console log:

com.suse.saltstack.netapi.exception.SaltStackException: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.request(HttpClientConnection.java:87)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.getResult(HttpClientConnection.java:65)
    at com.suse.saltstack.netapi.client.SaltStackClient.login(SaltStackClient.java:133)
    at com.gomo.test.CheckSaltClient.main(CheckSaltClient.java:34)
Caused by: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
    at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1916)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:279)
    at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:273)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1469)
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:213)
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:901)
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:837)
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1035)
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:394)
    at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:353)
    at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:134)
    at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:353)
    at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:380)
    at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236)
    at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
    at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
    at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
    at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
    at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.executeRequest(HttpClientConnection.java:188)
    at com.suse.saltstack.netapi.client.impl.HttpClientConnection.request(HttpClientConnection.java:85)
    ... 3 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
    at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
    at sun.security.validator.Validator.validate(Validator.java:260)
    at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
    at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:231)
    at sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:126)
    at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1451)
    ... 24 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
    at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:196)
    at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:268)
    at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:380)
    ... 30 more

The main library class (SaltStackClient.java) has grown quite a bit, especially since the recent merge of #94. It could make sense to refactor this class now, moving away the new methods (callSync() and callAsync()) into a separate module of the library for instance.

Eclipse fails to compile the code and shows compilation errors even though it compiles just fine using openjdk's javac via maven. This patch works around the issues for Eclipse version 4.5.

Is it normal to receive log messages like this?

Jul 01, 2016 10:32:55 PM org.apache.http.client.protocol.ResponseProcessCookies processCookies
WARNING: Invalid cookie header: "Set-Cookie: session_id=_MASKED_INFO_; expires=Sat, 02 Jul 2016 15:32:55 GMT; Path=/". Invalid 'expires' attribute: Sat, 02 Jul 2016 15:32:55 GMT
salt auth token: _MASKED_INFO_ Until: Sat Jul 02 10:32:55 MST 2016 Perms : [.*, @runner, @wheel, @jobs]
Jul 01, 2016 10:32:55 PM org.apache.http.client.protocol.ResponseProcessCookies processCookies
WARNING: Invalid cookie header: "Set-Cookie: session_id=_MASKED_INFO_; expires=Sat, 02 Jul 2016 15:32:55 GMT; Path=/". Invalid 'expires' attribute: Sat, 02 Jul 2016 15:32:55 GMT

Gson Javadoc for JsonDeserializer says: "New applications should prefer TypeAdapter, whose streaming API is more efficient than this interface's tree API". We still have some implementations of JsonDeserializer in the JsonParser class that should be converted, namely:

• StatsDeserializer
• ArgumentsDeserializer