Apache Commons NET FTP JApplet
I am having some trouble trying to implement the FTPClient library included within the Commons.Net library developed by the Apache Jakarta group.
I have been able to create an FTP Client which runs on the command line and lists all of the files on the ftp server, but when I integrate this code into a JApplet and code stops working as well as the JApplet. The JApplet runs fine but when I click a button to create a new instance of the FTPClient class it stops working!
I can't get my head round this, the only thing I can think it could be is the security with the Java Applet, I am rather new to Java and do not know much about the integration of Java Applets on client machines.
I am keeping my fingers cross that this doable, has anyone had these types of problems or anyone know what mistake I am doing?
I am trying to create a Java Applet for our company network which allows users to upload files into a secure area, for this to work we are integrating a custom Java Applet using the Commons.Net package.
Thank you for your time!
Regards,
Ben
[1100 byte] By [
benc_sla] at [2007-11-27 1:38:16]
I'm very suprised there are no Java technically experts out there which can answer this.
Do I need to create some sort of Java Certificate which the client installs on there machine for this to work, as I have been reading some information on Java Security:
http://java.sun.com/sfaq/#prevent
It appears that network connections are not available within applets unless they are to the same host. I can appreciate why this is, but was hoping there was a work around for this.
Regards,
Ben
> I'm very suprised there are no Java technically
> experts out there which can answer this.
>
You know nobody is getting paid for helping here....
>
> It appears that network connections are not available
> within applets unless they are to the same host. I
> can appreciate why this is, but was hoping there was
> a work around for this.
Yes the workaround is you need to sign your applet (with a certificate) and request permission for what you want to do.
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/rsa_signing.html
You also need to make sure the client computer firewall will not block outgoing connections on the two ports needed by FTP.
Thanks for both of your replies. I'll give it a go by creating a certificate.I appreciate that no-one gets paid for this, I just thought there would be some Java gurus that could share their wisdom!Many thanks,Ben
> I appreciate that no-one gets paid for this, I just
> thought there would be some Java gurus that could
> share their wisdom!
My 'wisdom' - don't use ftp directly in your Applet. Link your Applet to a Servlet in your server and then let your Servlet do the connection to the FTP server.
Many thanks for your prompt replies!
I've very new to Java (i'm a C#/C++/PHP/MySQL programmer), would you recommend any articles/tutorials for developing servlets?
So in theory, you are suggesting that the Java applet (the client) connects to the Java servlet (the server) running on the server. The Java servlet would then handle all FTP connections? Why did you recommend it like this? Do you think it would be more efficient or reliable?
Regards,
Ben
> Why did you
> recommend it like this? Do you think it would be
> more efficient or reliable?
>
Less efficient, possibly less reliable. Won't require a signed Applet to get access to the files but will require to be signed if you want to write them as files on the client. Won't require the firewall to be open on anything but the port already in use for HTTP.
The only thing is the file will be transferring through HTTP to the Java servlet running on the server. I presume this is going to have some file size limits. I can't really see how this is going to be more reliable, when the FTP is solely for transferring files and HTTP is used for serving files for download.
Thanks for your comments, maybe I need todo it both ways and test it thoroughly! We will be uploading and downloading file sizes of around 1Gb so I don't know whether HTTP is going to support this very well.
I know that there is file size limit with uploading with C#, I think its between 256mb and 512mb from the top of my head. Maybe this is a limitation with C# rather than the HTTP protocol.
Regards,
Ben
> We will be uploading> and downloading file sizes of around 1Gb Let me save you some testing time.You'll be doing this in FTP.
> I know that there is file size limit with uploading
> with C#, I think its between 256mb and 512mb from the
> top of my head. Maybe this is a limitation with C#
> rather than the HTTP protocol.
It's not a limit of the HTTP protocol per se but that is such a huge POST hat it really would be driving the HTTP server into the ground.
Normally I would agree with sabre but I do think that given the file-size requirement HTTP is not a realistic option here.
> The only thing is the file will be transferring
> through HTTP to the Java servlet running on the
> server. I presume this is going to have some file
> size limits.
What makes this a possibility?
> I can't really see how this is going to
> be more reliable,
I did not say it was!
> when the FTP is solely for
> transferring files
But there is nothing build into FTP for error checking that is not also in HTTP. In fact there is less because in FTP the file length of a transfer is not specified but in HTTP one has the 'Content-Length' header.
> and HTTP is used for serving files
> for download.
HTTP is more than that!
>
> Thanks for your comments, maybe I need todo it both
> ways and test it thoroughly! We will be uploading
> and downloading file sizes of around 1Gb so I don't
> know whether HTTP is going to support this very
> well.
I don't think (but may be wrong) there is any limit since there is no limit to the value of the 'Content-Length' header. I regularly download Linux distribution CDs each of about 800 MByte.
>
> I know that there is file size limit with uploading
> with C#, I think its between 256mb and 512mb from the
> top of my head. Maybe this is a limitation with C#
> rather than the HTTP protocol.
I don't think it is an HTTP protocol limit and I would be surprised if C# imposed that limit.
