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
]
-
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
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
/-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
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
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
]
-
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
]
-
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
: [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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo
