That should minimize the impact of the issue, and allow normal
operation when jclouds knows how to conenct to the node.
WDYT?
If I understand your proposal correctly, you mean essentially moving
the first attempt to find a connector to here:
https://github.com/jclouds/jclouds/blob/master/drivers/sshj/src/main/java/org/jclouds/sshj/SSHClientConnection.java#L166
? That would certainly help in the sense that, if you're providing any
one of the other connection methods, you would not see this problem.
I'm not sure what would happen in case you *do* want to use an
agentproxy, though. I guess what we want to ensure is that, if
usocket-nc works on your system, you do *not* get an error when using
jclouds-cli.
I think we would need to verify this...and then we should probably
also document (if not already done) that agent proxying is *only*
supported using netcat, i.e. not on Windows or using JNA.
If I put together a quick PR that moves the first call to JSch's
ConnectorFactory as you describe, would you be able to test whether a
CLI built using that patch works with netcat available?
Regards
ap
