jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: jclouds-cli problems
Date Tue, 07 Apr 2015 19:55:27 GMT
Thinking a bit more about this, the issue only affects OSGi users. I
mean, the current code should work fine on Unix and Windows systems
that use Pageant, as there should not be dependency issues. The only
issue is about how the agentproxy dependency exports its packages.

If we merge this pull request we might be *removing* working stuff. We
won't support the SSH agent in Windows anymore, so if possible, I'd
try to think about a different approach to make OSGi happy:

* One option is to catch the NCDFE as said before.
* Another approach could be to manually ask the classloader to load
the agentproxy classes. That throws a ClassNotFoundException, which is
a checked exception that can be cached. The ugly thing here is that we
should know which class to load depending on the platform. In
practice, we would be performing the agent proxy implementation lookup
and we would be hardcoding class names and packages that might change
in future versions of the agentproxy dependency, so this seems to be
even more evil.

At this point, I'm not sure which could be the better option to
workaround the exports issue: catching the NCDFE does not seem that
evil to me now. The current PR is cleaner, though, but we might be
dropping support for the SSH agent in some non OSGi environments.


On 7 April 2015 at 15:12, Andrew Phillips <aphillips@qrmedia.com> wrote:
> TL;DR: if we want to stick with the current functionality set, I think the
> PR against the sshj driver seems like "the right one."
>> Just to confirm, this is a temporal fix until your PR to fix the
>> agentproxy
>> bundle is in and released, right? Hopefully a fix for an eventual 1.9.1
>> and
>> to be reverted in 2.0.0?
> Well, it depends. The current approach is The Right Way, I think, to set up
> agentproxy if we only want to support ssh-agent via netcat. From what I
> recall, that was essentially the idea when this was added?
> *If* we decide that we want to support *all* the agentproxy options -
> netcat, JNA, pageant on Windows - *then* we should revert the current PR and
> modify the deps for both the sshj driver and karaf appropriately.
> Testing that this latter scenario works will not be all that easy, though, I
> suspect.
> Regards
> ap

View raw message