SFTP namespace handler?

We're trying to use the sftp namespace to perform an outbound SFTP file transfer.

If we specify the 2.0 xsd as per the documentation, we get an XML parsing exception: "Attribute 'session-factory' is not allowed to appear in element 'sftp:outbound-channel-adapter'.".

If we leave out the 2.0, we get another XML parsing exception that says the string "SpringSource |" is illegal in a schema element. In this case the server is clearly trying to resolve the XSD by going out to the web, where the URL http://www.springframework.org/schem...ation-sftp.xsd gets redirected to the SpringSource home page.

Even when we do include the 2.0 part of the URL, though, it seems like the server must be trying to resolve the namespace on the web, since the classpath XSD permits (indeed, requires) the session-factory attribute.

We're using the latest (Nov 18) 2.0 snapshot builds for all of Spring Integration. Our server is Virgo 2.1.0-RELEASE. We've made absolutely certain that there's no other version of the SI jars in the Virgo repositories. OS is Ubuntu 10.04.

The spring.handlers and spring.schema files in META-INF inside the sftp jar seem correct.

On an earlier post one of the lead developers said the SFTP and related elements are still undergoing some pretty rapid changes (which is why we're using the nightlies and not just RC2). Is there some other link in the chain that's just not quite there yet?

Thanks!

SFTP/FTP modules underwent major surgery in the last few days, so you may have some incompatibilities depending on the version of SI you are using. What is it?
Also, if starts align appropriately we are are planning to release 2.0.0.RELEASE today (which is the GA release),and hopefully you wont have these issues anymore. Otherwise in the interim I would suggest to grab a nightly build.

Thanks for your quick reply. We've been using 2.0.0.RC2, but switched to the nightlies for all of SI when we first hit this.

After my earlier post I thought maybe it was an OSGi manifest issue, e.g. the SFTP bundle not exporting the namespace package (o.s.i.sftp.config). That could cause problems on an OSGi server like Virgo, but not in your samples or unit tests. But the manifest seems to be ok.

Happy to wait for the release. If we're still seeing the problem after that, I'll put together a small sample project that exhibits the issue and come back to the forum.

Thanks again.

Wait, i just realized that you are using the latest snapshot. Sorry about that.
Well I am not sure what's going on with your schema issue, but lets try different direction.

Yesterday I've published SFTP samples in our samples repository (look at the 'basic' category) http://git.springsource.org/+spring-...ration/samples.

Could you possibly run it outside of OSGi/Virgo environment? I am trying to see if we can isolate the problem if there is a problem.

Actually if you can put a sample project please do so (even now if you can)

Now on the related note. SFTP module internally uses JCH libraries (http://www.jcraft.com/jsch/). Knowing how some times OSGi logs can be misleading let me ask you this. Do you have JCH bundle in your virgo repository? What version?

In all the talk of what the SI manifests might or might not be exporting, we managed to overlook that OUR manifest was not importing the o.s.i.sftp bundle. D'oh!

Correcting that mistake caused the xsd's to be resolved correctly both in RC2 and in the latest build snapshot.

We did, however, stumble across something in the latest build that might be worth addressing before your release.

The SFTP pom expresses a dependency on the JSch library at version 0.1.42.

The manifest (the template.mf file to be precise), however, depends on 0.1.41.

So if you use Maven to build your project and tell you what your dependencies are, you'll wind up with the wrong version of JSch in your OSGi repository.

While you're fixing that up, would it be too much trouble to make the pom pick up a properly OSGi-ified version of JSch , like the one from the EBR:

Code:

---

<dependency>
    <groupId>com.jcraft.jsch</groupId>
    <artifactId>com.springsource.com.jcraft.jsch</artifactId>
    <version>0.1.41</version>
</dependency>

---

EBR doesn't have a 0.1.42 version, but the better solution there surely is to urge them to upload one quick smart, rather than depending on an unusable (in OSGi) jar :).

Thanks again,

Jerry Gaines

How ironic that your brought it up ;)
https://jira.springsource.org/browse/INT-1637 - discovered it this morning
Its all fixed now

Very cool. Looking forward to the 2.0.0 release. Congratulations on that and thanks for the staggering amount of hard work you guys have put into this product!

By the way, I updated the version range to [0.1.41, 0.1.5). Obviously 0.1.42 will still work fine.