commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rory Winston <rwins...@eircom.net>
Subject Re: [net] JSSE classes in FTPS WAS Re: [net] FTPS submission - legal issues
Date Sun, 29 Jan 2006 15:11:18 GMT
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 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: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message