[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006312#comment-13006312
]
Jochen Wiedmann commented on IO-174:
I suggest that we continue the discussion on dev@commons. Okay?
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006289#comment-13006289
]
Niall Pemberton edited comment on IO-174 at 3/13/11 11:23 PM:
--
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package rename for IO
here in commons. So until that happens, this change can't.
was (Author: niallp):
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package for IO here in
commons. So until that happens, this change can't.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006289#comment-13006289
]
Niall Pemberton commented on IO-174:
Yes you're right and its a shame I didn't think of it at the time.
However, any break in binary compatibility will force a package for IO here in
commons. So until that happens, this change can't.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006279#comment-13006279
]
Jochen Wiedmann commented on IO-174:
There are other ways to receive reusability without breaking the contract. For
example, one could reintroduce a method reset().
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006277#comment-13006277
]
Niall Pemberton commented on IO-174:
The main point was that it was designed that way - to be reusable. Personally I
think thats OK.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-372) FTPSClient: java.security.cert.CertificateException: No X509TrustManager implementation available if trustManager == null
[ https://issues.apache.org/jira/browse/NET-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-372. -- Resolution: Fixed > FTPSClient: java.security.cert.CertificateException: No X509TrustManager > implementation available if trustManager == null > - > > Key: NET-372 > URL: https://issues.apache.org/jira/browse/NET-372 > Project: Commons Net > Issue Type: Bug >Reporter: Sebb > > FTPSClient defaults to providing the TrustManager provided by > FTPSTrustManager. > It should be possible to use setTrustManager(null) to obtain the default JVM > trust manager, however this fails with > java.security.cert.CertificateException: No X509TrustManager implementation > available > because SSLContext.init(KeyManager[] km, TrustManager[] tm, SecureRandom > random) expects null parameters, but does not allow for null entries in the > TrustManager array. > The init call needs to be changed so null is passed instead of an array with > a null entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-372) FTPSClient: java.security.cert.CertificateException: No X509TrustManager implementation available if trustManager == null
FTPSClient: java.security.cert.CertificateException: No X509TrustManager implementation available if trustManager == null - Key: NET-372 URL: https://issues.apache.org/jira/browse/NET-372 Project: Commons Net Issue Type: Bug Reporter: Sebb FTPSClient defaults to providing the TrustManager provided by FTPSTrustManager. It should be possible to use setTrustManager(null) to obtain the default JVM trust manager, however this fails with java.security.cert.CertificateException: No X509TrustManager implementation available because SSLContext.init(KeyManager[] km, TrustManager[] tm, SecureRandom random) expects null parameters, but does not allow for null entries in the TrustManager array. The init call needs to be changed so null is passed instead of an array with a null entry. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-371) Create TrustManagerFactory to provide custom TrustManagers
[ https://issues.apache.org/jira/browse/NET-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-371. -- Resolution: Fixed > Create TrustManagerFactory to provide custom TrustManagers > -- > > Key: NET-371 > URL: https://issues.apache.org/jira/browse/NET-371 > Project: Commons Net > Issue Type: New Feature >Reporter: Sebb > > There are currently additional versions of FTPSTrustManager used by different > protocols (POP3S and SMTPS); it would be useful to share the code for these. > There should also be a TrustManager that is even more lenient than the FTPSTM > (which checks certificate validity). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-371) Create TrustManagerFactory to provide custom TrustManagers
Create TrustManagerFactory to provide custom TrustManagers -- Key: NET-371 URL: https://issues.apache.org/jira/browse/NET-371 Project: Commons Net Issue Type: New Feature Reporter: Sebb There are currently additional versions of FTPSTrustManager used by different protocols (POP3S and SMTPS); it would be useful to share the code for these. There should also be a TrustManager that is even more lenient than the FTPSTM (which checks certificate validity). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006217#comment-13006217
]
Sebb commented on NET-326:
--
OK, thanks, that's cleared it up.
Any certificate can provide encryption, but if the private key is known by a
3rd party, then in theory they can intercept the transmission and decrypt it.
This can be avoided by ensuring that the certificates are trusted, i.e. we
trust the issuer to protect it,
So I think we should provide some different levels of validation:
- none (as per your patch)
- certificate must be valid (as per FTPSTrustManager, POP3S, SMTPS)
- full (i.e. use the defaults, don't override).
I'll add a TMFactory utility class that provides these.
This would allow the user to choose the appropriate level for their application.
> A KeyManager is required when the protection level is set to 'P' with
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java
> 1.6.0_12-b04
>Reporter: Terence Dudouit
> Attachments: SSLContextsFactory.java
>
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to
> the SSL cipher suites which are enabled.
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need
> for a client authentication.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (IO-174) CharSequenceReader does not obey Reader contract and throw IOExceptions if read when closed
[
https://issues.apache.org/jira/browse/IO-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006216#comment-13006216
]
Jochen Wiedmann commented on IO-174:
Niall, I don't agree with you. While preservation of binary compatibility is an
important topic, I do believe that the general contract of java.io.Reader takes
precedence.
> CharSequenceReader does not obey Reader contract and throw IOExceptions if
> read when closed
> ---
>
> Key: IO-174
> URL: https://issues.apache.org/jira/browse/IO-174
> Project: Commons IO
> Issue Type: Bug
> Components: Streams/Writers
>Affects Versions: 1.4
>Reporter: Douglas Hauge
> Attachments: IO-174.patch
>
>
> In the Java specs for
> [*java.io.Reader.close()*|http://java.sun.com/j2se/1.5.0/docs/api/java/io/Reader.html#close()],
> it states
> {panel}
> Once a stream has been closed, further read(), ready(), mark(), or reset()
> invocations will throw an IOException
> {panel}
> However, the *org.apache.commons.io.input.CharSequenceReader* does not do
> this, but instead resets the file back to the start when it is closed. This
> causes problems when passing this reader to some libraries (albeit admittedly
> poorly written ones) that rely on *read* throwing an *IOException* after the
> reader has been closed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006205#comment-13006205
]
Bogdan Drozdowski commented on NET-326:
---
isClient/ServerTrusted(): I believe we don't need these anymore. I left them
because the code I've found on the 'net used them and I figured these may be
required for backwards-comaptibility and this was my only reason. Now I'm
thining that the backward-compatible version perhaps required classes from
javax.security.cert (instead of the new java.security.cert), so this
compatibility may not be retained anyway.
checkServertrusted(): wasn't commented-out in FTPSTrustManager, but since we're
accepting everything, I'm not even validating. Validating the certificates
could cause Exceptions, so we could validate not all certificates. What to do
is the right question. If the server certificate has expired or is self-signed
or is not signed by a certificate a user has in his/her trust store, should we
reject it even if it would provide encryption?
Yes, the accept-all TrustManager looks like the other (except for the disabled
code, perhaps). It came from the Web, while POP3TrustManager and
SMTPSTrustManager came from the FTPSTrustManager. I didn't think back then that
these could be combined, I kept my classes in the packages I modified. But
you're right: at this point we're duplicating code, so these certainly can be
combined. And there wouldn't be need for the anonymous class in the
SSLContextsFactory any more.
> A KeyManager is required when the protection level is set to 'P' with
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java
> 1.6.0_12-b04
>Reporter: Terence Dudouit
> Attachments: SSLContextsFactory.java
>
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to
> the SSL cipher suites which are enabled.
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need
> for a client authentication.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MATH-549) Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static
Suggestion: Make PearsonsCorrelation.correlation(double[], double[]) static --- Key: MATH-549 URL: https://issues.apache.org/jira/browse/MATH-549 Project: Commons Math Issue Type: Improvement Affects Versions: 2.2 Reporter: Tomas Salfischberger Priority: Minor Making PearsonsCorrelation.correlation(double[], double[]) static would allow for calculating a correlation without instantiating a PearsonsCorrelation object. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006197#comment-13006197
]
Sebb commented on NET-326:
--
Thanks, the patch looks very useful.
Just a few minor points of clarification:
Do we really need the isClientTrusted/isServerTrusted methods? They appear to
be for pre-JDK 1.4 code.
Why is the checkServerTrusted code commented out?
Also, the accept-all TrustManager seems to be basically the same
FTPSTrustManager and POP3TrustManager and SMTPSTrustManager - they could surely
all be combined
into a single utility class?
Note: no need to provide patches for such changes, but feedback very welcome!
> A KeyManager is required when the protection level is set to 'P' with
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java
> 1.6.0_12-b04
>Reporter: Terence Dudouit
> Attachments: SSLContextsFactory.java
>
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to
> the SSL cipher suites which are enabled.
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need
> for a client authentication.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MATH-546) Truncation issue in KMeansPlusPlusClusterer
[ https://issues.apache.org/jira/browse/MATH-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nate Paymer updated MATH-546: - Attachment: MATH-546.txt I've a patch to fix this bug. This is my first contribution to this project, so apologies if I've screwed something up :) > Truncation issue in KMeansPlusPlusClusterer > --- > > Key: MATH-546 > URL: https://issues.apache.org/jira/browse/MATH-546 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Nate Paymer >Priority: Minor > Labels: cluster > Attachments: MATH-546.txt > > > The for loop inside KMeansPlusPlusClusterer.chooseInitialClusters defines a > variable > int sum = 0; > This variable should have type double, rather than int. Using an int causes > the method to truncate the distances between points to (square roots of) > integers. It's especially bad when the distances between points are > typically less than 1. > As an aside, in version 2.2, this bug manifested itself by making the > clusterer return empty clusters. I wonder if the EmptyClusterStrategy would > still be necessary if this bug were fixed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-326) A KeyManager is required when the protection level is set to 'P' with FTPSClient on active mode
[
https://issues.apache.org/jira/browse/NET-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bogdan Drozdowski updated NET-326:
--
Attachment: SSLContextsFactory.java
Here is a simple class that wraps all the SSLContext creation details in simple
methods. There are 2 "maximum" methods (all parameters included), 1 "minimum"
(just the keystore and a password to it) and some in between. Tested the
simplest method - still works. Put it in the right package
(org/apache/commons/net/util?), you can move tha anonymous class to a named
inner class, if you like.
> A KeyManager is required when the protection level is set to 'P' with
> FTPSClient on active mode
> ---
>
> Key: NET-326
> URL: https://issues.apache.org/jira/browse/NET-326
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.0
> Environment: Windows XP profesional service pack 2, Java Java
> 1.6.0_12-b04
>Reporter: Terence Dudouit
> Attachments: SSLContextsFactory.java
>
>
> Using a simple FTPS client that list a directory, when execPROT("P") is set
> and the active mode is on, the following exception is thrown :
> javax.net.ssl.SSLException: No available certificate or key corresponds to
> the SSL cipher suites which are enabled.
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303)
> at
> com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253)
> at
> org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:489)
> at
> org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:494)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1950)
> at org.apache.commons.net.ftp.FTPClient.listNames(FTPClient.java:1996)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.testFTPS(FTPGet.java:379)
> at
> fr.enovacom.eai.actions.dynamiques.protocole.ftp.FTPGet.main(FTPGet.java:401)
> This doesn't occur on passive mode.
> The only way to make it work is to set a keyManager although there is no need
> for a client authentication.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
