Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
What JDK are you using?
M wrote:
Hi.
Oddly enough, I took out the code where you pass the login and password, in
my FTPSClient (i.e. //client.login(test,test);) and got connected.
However, whenever I did a command listing, it will just hang like before.
so anything to do like
//client.cwd(temp);
//client.list();
will hang..
btw. I took the latest FTPSClient code from Apache too.
M wrote:
Hi.
Yes I did generate the certificate and tested using filezilla client. It
worked from filezilla client though.
I updated apache's secure code..
meaning commented:
//this.sendCommand(PBSZ, pbsz);
//this.sendCommand(PROT, prot);
It got connected but not the login now..
220-FileZilla Server version 0.9.18 beta
220-written by Tim Kosse ([EMAIL PROTECTED])
220 Please visit http://sourceforge.net/projects/filezilla/
AUTH SSL
234 Using authentication type SSL
**1
**2
**3
**4
**5
*** Connected
Is Connected:true
USER test
Exception in thread main
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed
without indication.
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:267)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:460)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:520)
at org.apache.commons.net.ftp.FTP.user(FTP.java:670)
at org.apache.commons.net.ftp.FTPClient.login(FTPClient.java:637)
at TestFTPS.main(TestFTPS.java:31)
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
//FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1);
System.out.println(*** Connected );
System.out.println(Is Connected: + client.isConnected());
client.login(test, test);
System.out.println(Is Connected: + client.isConnected());
System.out.println(*** Passed Login );
Appreciate any advise.
regards,
Rory Winston wrote:
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about
this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more
that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1, 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to
add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
/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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6328324 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Hmmm, Well if there is a problem somewhere, its got to be recorded *somehow*. There are three places it could be: 1. The FileZilla interface 2. The FileZilla logs 3. The output from the FTP Client (i.e. any JSSE exceptions thrown) So there is nothing in any of these that gives you any clues? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6313989 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String sslContext;
// Secure context (can be TLS or SSL)
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter _controlOutput_;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this(JCEKS, TLS, password, 0, P);
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore,
password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
keyManagerFactory.getKeyManagers(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IOException
{
System.out.println(* In 1 );
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IOException
{
System.out.println(* In 2 );
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect(127.0.0.1, 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( ... );
client.addProtocolCommandListener(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect(localhost, 990); it does not get connected.
FTPSClient client = new FTPSClient(JKS,SSL,password,0,P);
System.out.println(*);
client.connect(127.0.0.1,990);
System.out.println(*);
client.getStatus();
System.out.println(*);
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the License);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.OutputStreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import javax.net.ssl.KeyManagerFactory;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import org.apache.commons.net.SocketFactory;
import org.apache.commons.net.ftp.FTPClient;
/**
*
* This class extends [EMAIL PROTECTED] org.apache.commons.net.ftp.FTPClient} to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH...
private String sslContext;
// Secure context (can be TLS or SSL)
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter _controlOutput_;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this(JCEKS, TLS, password, 0, P);
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
keyManagerFactory.init(keyStore,
password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
keyManagerFactory.getKeyManagers(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
org.apache.commons.net.SocketClient#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
... 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6316503 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6315924 Sent from the Commons - Dev forum at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/-net--JSSE-classes-in-FTPS-WAS-Re%3A--net--FTPS-submission---legal-issues-tf1019716.html#a6317306 Sent from the Commons - Dev forum at Nabble.com. - 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]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. The JSSE's jar does not provide javax.net.ssl versions of the com.sun.net.ssl interfaces And, after doing a little research, I find that there are differences between JSSE 1.0.3 and the packages in JDK 1.4, such that there is no backward compatibility. Basically, JSSE 1.0.x is a prototype, a hack through which Sun worked out the bugs, culminating in the better implementation that they released in 1.4. They did not just move the JSSE.jar code into JDK 1.4. They also improved it. Since these are new classes for us, I think it makes little sense to tie into backward compatibility from the start, when that backward compatibility is already out of date. I don't think there is a clean way to have one code base that will work the way we'd like it for both cases. Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. Jose Juan Montiel wrote: 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect(127.0.0.1);
client.addProtocolCommandListener(new
PrintCommandListener(new PrintWriter(System.out)));
client.login(user, pass);
client.cwd(test);
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
OutputStream out = new FileOutputStream(c:\\temp\\test.war);
client.retrieveFile(test.war, out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
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
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Daniel F. Savarese wrote: I'm living in the timewarp of digest mode subscription, so please forgive me for having made obsoleted comments. In message [EMAIL PROTECTED], Rory Winston writes: I think that's a great suggestion. It moves us forward without necessarily sacrificing backwards compatability. ... Steve Cohen wrote: Thank you for this explanation. It is good to actually look at the code instead of making assumptions, which is what I have been doing. ... Therefore, I think the solution for this is for Jakarta Commons Net to take Rory Winston's suggestion and start a new branch of Commons Net for JDK 1.4 only (for this and other reasons) and maintain two branches for awhile, the current HEAD branch for 1.3 compatibility and the new branch for 1.4. The new branch can use the javax.ssl.net classes, the old one can use com.sun.net. +1 Since we're going to branch anyway and in light of Steve's discoveries about JSSE 1.0.3, this seems like the easiest way to handle the situation. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. I think the proposal on the floor is to do two things A) a commons-net 1.5 containing fixes for any outstanding bugs and incorporating Josejuan Montiel and Paul Ferraro's FTPS code. This code would depend on com.sun.ssl.net classes. It would be the last release supporting JDKs 1.4 B) a commons-net 2.0 (possibly a different project) that would require jdk 1.4 compatibility, including modifying the FTPS code to use javax.ssl.net, the nio extensions, and using java 1.4's regex which would have the one small advantage of reducing dependency on other jars which periodically rears its head as an issue. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. One more thing, we would need Paul Ferraro to sign a Software Grant which was mentioned about a week ago by Cliff Schmidt. I am trying to get details on this. Steve Cohen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Steve Cohen writes: Daniel, before we vote, I think we need a formal motion to vote on, especially in light of your obsoleted comments in the other thread. My +1 wasn't intended to reflect a vote. It was just shorthand for I concur. While I'm generally in favor of this, I still don't think its ready for a vote because of possibly a different project, which is too vague. +1 :) daniel - 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]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: 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] 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. 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Just use jsse. I didn't have any problems with them under jdk1.3. Running that stuff under jdk1.3 should also work like charm. Mvgr, Martin Steve Cohen wrote: Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 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. Has anyone on this list had experience with these type of issues? (technical, not legal). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
In message [EMAIL PROTECTED], Rahul Akolkar writes: No, haven't had to deal with such a situation. But doesn't this mean that the code will only work on a subset of the 1.3 JDKs (Sun)? If so, maybe (3) isn't all that bad? In general, I am biased against introducing dependencies on com.sun packages for the very reason stated. The code will work only with the Sun JDK or JVMs incorporating sublicensed parts of the JDK that include those packages. For that matter, it will work only with a particular version of the Sun JVM should the classes not appear in a future release. If JSSE will work and is usable with JDK 1.3 as an add-on jar, I don't see any reason why it should be avoided (i.e., I'm +1 for option 3 and -1 for 2). daniel - 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]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Jose Juan Montiel wrote: 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] Well if option 3 won't work, that changes things, but can you tell us how it fails? - 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
Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 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. Has anyone on this list had experience with these type of issues? (technical, not legal). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
On 1/23/06, Steve Cohen [EMAIL PROTECTED] wrote: Rory Winston wrote: Ive come across the com.sun.* issue before. They are part of the JVM, just not officially documented for public use. Usually, they are convenience classes written by Sun programmes who develop the JDK. AFAIK, Sun says that you can use them if you wish, but their use is not recommended, purely on the basis that they may disappear from one JDK release to the next. What are the com.sun.* classes being used here for, specifically? It may be possible to use official classes for this functionality. Rory From what I've been able to gather there are official classes as of jdk 1.4. Prior to that these were a separate package, the JSSE. So I guess there are three possibilities: 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. Has anyone on this list had experience with these type of issues? (technical, not legal). snip/ No, haven't had to deal with such a situation. But doesn't this mean that the code will only work on a subset of the 1.3 JDKs (Sun)? If so, maybe (3) isn't all that bad? -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
