|
| Re: using RSE in OSGi containers (Equinox) [message #640558 is a reply to message #640228] |
Mon, 22 November 2010 13:49   |
 Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
RSE carries pretty heavy UI dependencies from its old heritage.
The Services layer is the only layer that's UI-less, so you could
probably leverage that if you need to exchange different communication
mechanisms over a single API. But even there, you'll have to play some
tricks to get rid of the IConnectorService, all of which implementations
require UI yet again.
In general, I think that in a UI-less Server environment you're better
off using the libs directly (i.e. JSch, commons.net), or you use ECF.
HTH,
Martin
Alex Pitigoi wrote:
> Is there any recommendation on how RSE could be used in a server
> environment based on an OSGi container (Equinox) where SWT dependencies
> are not welcome?
>
> Is the only choice remaining for such a usage scenario to build the
> necessary SSH functionality only based on JCraft/JSch direct dependency?
>
> Any hint, suggestion and recommendation is highly appreciated.
> Thanks,
> Alex
|
|
|
|
| Re: using RSE in OSGi containers (Equinox) [message #640871 is a reply to message #640696] |
Tue, 23 November 2010 11:44 |
Martin Oberhuber
Messages: 1007
Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
org.eclipse.rse.services.ssh does not depend on anything SWT like. To
instantiate SftpFileService, you need an ISshSessionProvider in the
constructor.
Since you cannot use the RSE SshConnectorService, you will need to make
your own implementation of ISshSessionProvider (could clone some code
from SshConnectorService#createSession(). That's quite simple.
The other IFileService implementation that doesn't need SWT at the
moment is LocalFileService, so you could replace your SSH/SFTP service
by local access easily.
services.files.ftp currently does have an rse.core (and thus SWT)
dependency but that's very thin (only IPropertySet) and could be removed
easily. I'd surely accept a contribution getting rid of this in Indigo
since having it was not wise in the first place. Then you could replace
SSH/Sftp with FTP/FTPS if you want. Please file a bug asking for removal
of IPropertySet from FTP if you want to go that route.
TCFFileService and WinCEFileService would be slightly harder to
refactor, but only because they use a single plugin for both the
services and the subsystem layer at the moment so splitting them up
would be possible. For DStoreFileService I don't see how you could get
rid of the dependency.
Your call what you want to do... use JSch directly if you don't see a
need for replacing a protocol in the future, or RSE IFileService if you
do think you'll want to replace the protocol, or use ECF.
ECF is the other protocol abstraction layer at Eclipse. ECF providers
currently exist for URL, HTTP/HTTPS, BitTorrent and XMPP [1]. I'm being
told that it's easy to add new providers; so you could also write your
ECF provider abstraction on top of JSch, there's enough example code
available. ECF has a history of being used on the server side, so I'm
sure you'd get good support from the ECF people writing such a provider.
[1]
http://wiki.eclipse.org/ECF_Providers#File_Transfer_.28org.e clipse.ecf.filetransfer.29
HTH,
Martin
Alex Pitigoi wrote:
> Hi Martin,
>
> My initial attempt was to rely solely on the Services layer, but that
> seems to have a org.eclipse.rse.core dependency which has the
> unfortunate SWT dependency. I am interested in the SSH/SFTP services,
> and I was wondering what kind of tricks are available to "get rid of the
> IConnectorService", if you can possibly provide some quick reference.
> Otherwise, I shall focus on the direct usage of JSch in an OSGi bundle,
> as I haven't identified any ECF services that would provide SSH/SFTP,
> unless you can recommend something specifically.
>
> Thanks,
> Alex
|
|
|
|
Powered by
FUDForum. Page generated in 0.03438 seconds
] 
Search
Help
Register
Login
Home
