[Re:] connect to ftp server via proxy..
I will be in touch with you around that time. I'll wait until this time Rory :) Bye. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Re:] connect to ftp server via proxy..
Hi Alex, try with this: System.setProperty(socksProxyHost, 7200); System.setProperty(socksProxyPort, 25.10.22.11); But remember that all connection under this JDK use this proxy socks... because you are changing system property of your java virtual machine. And Rory, don't mind that: This wouldn't require a huge amount of extra effort if takes 8-12 month of new release of JAKARTA COMMONS NET... remember FTPS... i'm still waiting a new release... And, under JDK 1.3, i soon see how Sun have implemented it for their internal JDK FTP client, and only works with anonymous ftp, because they don't consider pass @user:passw as we talk, long, long time ago... http://mail-archives.apache.org/mod_mbox/jakarta-commons-dev/200601.mbox/[EMAIL PROTECTED] Bye -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS...
Hi... ...Steve Cohen, Rory Winston, and all the people that contribute to Jakarta Commons. I just known, that all are very busy with JIRA migration, and many proyects: personal, from work and other jakarta proyect. My question is, when jakarta commons net 1.5 or 2.0... with FTPS in his distint aproximation (incluiding Satoshi Ishigami patch), will be release... Again, i offer my help if yours need, for this proyect, or other. Thanks to all. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re:[net] JavaWorld article review requested
Hi, I only add one thing. In the final comparison matrix put Y in FTPS (FTP over SSL) and soon TLS for Jakarta Commons Net. Because in short cut of time, the next release implement, or not Stephen? :D Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hi Steve, What I think you're missing is that if you put jsse.jar on your classpath, you can use javax.net.ssl with java 1.3. maybe i don't explain well, sorry. The three classes of com.sun.net.ssl that are used for implement FTPS (in the way that Paul did and I modified, maybe there is another...) are... com.sun.net.ssl.KeyManagerFactory (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/KeyManagerFactory.html) com.sun.net.ssl.SSLContext (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/SSLContext.html) com.sun.net.ssl.TrustManager (http://java.sun.com/products/jsse/doc/apidoc/com/sun/net/ssl/TrustManager.html) This classes in JSSE are only in the package com.sun.net.ssl, and although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't contain this classes, it contains javax.net.ssl.SSLSocket, a classes soon used, to implement FTPS. And the commons-net team would prefer to go that way because Sun says that com.sun.net may go away with some future release, but not javax.net. Yes, this would be a small inconvenience for java 1.3 users, but the stability is worth it. This three classes in JDK 1.4.2, were move to javax.net.ssl.KeyManagerFactory (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/KeyManagerFactory.html) javax.net.ssl.SSLContext (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLContext.html) javax.net.ssl.TrustManager (http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/TrustManager.html) But if you download for example JDK 1.4.2 and look inside of (jre/lib) you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun, still mantain compatiblity with JDK 1.3. And still in JDK 1.5, you'll find jre/lib/jsse.jar. But when jsse.jar desapear, i offer to modified code... In other way if use javax.net.ssl.KeyManagerFactory , javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work under JDK 1.3. I hope explain better, this time. Then, make that you consider appropiate... Thanks all, for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JDK 1.4+ Branch?
Hi Rory, i have not sufficient experience in Jakarta Commons Net, to decide or even to talk about of this, but i would said a few things about your reasoning... * FTPS support would not necessitate a separate (JSSE) jar dependency; About dependency, i hope explain well in thread JSSE and FTPS functionality. * It also may be easier to incrementally add new functionality, such as Proxy support If when you said Proxy support, you talk about the problem/bug URLConnection, in JDK 1.3, that don't send user and password in HttpURLConnection. i.e. URL url = new URL(ftp://user:[EMAIL PROTECTED]:port/path); URLConnection conexion = (url).openConnection(); conexion.connect(); InputStream in = clientHttp.getInputStream(); To the proxy it send ftp://host:port/path... Because of this, its imposible to implement FtpHttpProxyClient... (its only works with anonymous client). If you talk of this, i have a solution, 2 classes that extends and modifie 2 classes of JDK 1.3 (sun.net.www.protocol.http.HttpURLConnection, sun.net.www.http.HttpClient) and solve this problem... If you want, i could colaborate... And Steve, The only negative I can find is that our contributor of the FTPS stuff badly wants 1.3 compatibility. And I have a feeling that he's not the only one. 1.3 is not yet End of Life according to Sun, although it will be soon. I'm not negative :) only i would like use Jakarta Commons Net with my JDK 1.3 proyects... If remember i don't ask colaborate, i only want 2 variables protected... :) But, i don't mind colaborate with yours to make Jakarta Commons Net better (and if possible JDK 1.3 compilant) I guess I'm okay with it but I'm not quite a +1 yet until I understand how much work is involved. I notice a couple of the Jakarta Commons projects do separate branches: About this, i offer my time, to mantain FTPS under 1.3 or ever 1.4 :) If you want... Thank for your time. -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hi, first of all, thanks for your attention, and your time to improve Jakarta Commons Net. Then I would like to finish this point. When you had to choose the way to implement FTPS, you propose: 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. And I said: The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... And you ask: Well if option 3 won't work, that changes things, but can you tell us how it fails? I said that option don't work under JDK 1.3, because javax.net.ssl its only in JDK 1.4. In those days, the list ask about the JDK that you use... I think that Jakarta support JDK 1.3, its a good idea, because although 1.3 its too old... thera are a lot of servers that run on this In this case i think, that implement FTPS using com.sun its the best option because, it run on 1.3 (importing JSSE) and 1.4 (where you dont need any aditiona jar import) And finally, what will be the choice...? Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
1. Use the javax.net.ssl classes. (Out of the question because of our mandate to support 1.3) 2. Do what Paul and Josejuan did - use the com.sun classes 3. Maybe. use the javax.net.ssl classes but document that if used with JDK 1.4, jsse.jar must be on the classpath. Hi, i'll use the second option, because if commons-net implements SSL-FTPS under JDK 1.3, its necesary import JSSE, and if use JDK 1.4, the source code, don't need any change. When commons-net, upgrde to JDK 1.4, if want remove JSSE, the modifications in source code will be simples. I'll do it :) The 3º option it not possible, because, don't work under 1.3, although import jsse.jar... need change the import in source code... Its my opinion. Thanks for all. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to implent FTPS extending FTPClient, from a diferente package...
Hi everybody, I'm Jose from Spain. I make an implement of FTPS: using http://sourceforge.net/projects/ufsc implementation (which use a new class, created by UFSC, org.apache.commons.net.ftp.FtpsClient that extends org.apache.commons.net.ftp.FTPClient), with some minor modification to adapt Java 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author). I try to build FtpsClient under diferent packege, then i found that couldn't do it because, in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; were declare with packege visibility, and FtpsClient use this, to implement securety connection to SSLSocket. Something like this: this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); Because of this, FtpsClient, in UFSC, is under org.apache.commons.net.ftp. Then the solution I adopt, was copy (and minor modify) FTPClient and FTP from org.apache.commons.net.ftp in my own package, and extends FtpsClient, from my own FTPClient, to make it in a difetent pakage... And now, my question is: why this variables are declare this way? without a getter? It could be possible, for future version, declare protected, for simplify the extension of api, to implement FTPS, or other future protocol... in diferent package...? Thanks to all, for your time and anwers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] How to implent FTPS extending FTPClient, from a diferente package...
Hi everybody, I'm Jose from Spain. I make an implement of FTPS: using http://sourceforge.net/projects/ufsc implementation (which use a new class, created by UFSC, org.apache.commons.net.ftp.FtpsClient that extends org.apache.commons.net.ftp.FTPClient), with some minor modification to adapt Java 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author). I try to build FtpsClient under diferent packege, then i found that couldn't do it because, in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; were declare with packege visibility, and FtpsClient use this, to implement securety connection to SSLSocket. Something like this: this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); Because of this, FtpsClient, in UFSC, is under org.apache.commons.net.ftp. Then the solution I adopt, was copy (and minor modify) FTPClient and FTP from org.apache.commons.net.ftp in my own package, and extends FtpsClient, from my own FTPClient, to make it in a difetent pakage... And now, my question is: why this variables are declare this way? without a getter? It could be possible, for future version, declare protected, for simplify the extension of api, to implement FTPS, or other future protocol... in diferent package...? Thanks to all, for your time and anwers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] How to implent FTPS extending FTPClient, from a diferente package...
Hi everybody, I'm Jose from Spain. I make an implement of FTPS: using http://sourceforge.net/projects/ufsc implementation (which use a new class, created by UFSC, org.apache.commons.net.ftp.FtpsClient that extends org.apache.commons.net.ftp.FTPClient), with some minor modification to adapt Java 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author). I try to build FtpsClient under diferent packege, then i found that couldn't do it because, in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; were declare with packege visibility, and FtpsClient use this, to implement securety connection to SSLSocket. Something like this: this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); Because of this, FtpsClient, in UFSC, is under org.apache.commons.net.ftp. Then the solution I adopt, was copy (and minor modify) FTPClient and FTP from org.apache.commons.net.ftp in my own package, and extends FtpsClient, from my own FTPClient, to make it in a difetent pakage... And now, my question is: why this variables are declare this way? without a getter? It could be possible, for future version, declare protected, for simplify the extension of api, to implement FTPS, or other future protocol... in diferent package...? Thanks to all, for your time and anwers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] How to implent FTPS extending FTPClient, from a diferente package...
Hi, i send it to bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=38309 I think that variables, _controlInput, _controlOutput, could be declare protected, as well, could be a setter... Thanks for your time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] FTPS or...
...why in org.apache.commons.net.ftp.FTP the variables BufferedReader _controlInput; BufferedWriter _controlOutput; aren't declare protected? Hi everybody, i'm newbee in this list, and i'm trying to impliments SSL-FTPS over Java 1.3.1, using http://sourceforge.net/projects/ufsc implementation of FTPS, with some minor modification to adapt 1.3 and solve some fix with PASV transfer (modification and fix, that i comunicate to the author), but the problem i find, was i couldn't implement FTPSClient in diferent package of org.apache.commons.net.ftp because, this variables, that UFSC use, to implement securety connection to SSLSocket this._controlInput = new BufferedReader(new InputStreamReader(socket.getInputStream(), getControlEncoding())); this._controlOutput = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream(), getControlEncoding())); haven't a getter... and its visibility is to the package Then, i have to create FTPClient and FTP, and extends FTPSClient, from my own FTPClient, to make it in a difetent pakage... Could devoloper make getter for this properties or protected, for simplify the extension of api? Thanks for all... -- The whole purpose of places like Starbucks is for people with no decision-making ability whatsoever to make six decisions just to buy one cup of coffee. Short, tall, light, dark, caf, decaf, low-fat, non-fat, etc. So people who don't know what the hell they're doing or who on earth they are can, for only $2.95, get not just a cup of coffee but an absolutely defining sense of self: Tall. Decaf. Cappuccino. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
