[jira] [Commented] (FILEUPLOAD-193) FileNotFoundException thrown by DiskFileItem.write
[
https://issues.apache.org/jira/browse/FILEUPLOAD-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057131#comment-13057131
]
jagub zhang commented on FILEUPLOAD-193:
did you use DiskFileItem#write twice?
or you register a FileCleaningTracker in your DiskFileItemFactory.
FileNotFoundException thrown by DiskFileItem.write
--
Key: FILEUPLOAD-193
URL: https://issues.apache.org/jira/browse/FILEUPLOAD-193
Project: Commons FileUpload
Issue Type: Bug
Affects Versions: 1.2.2
Environment: Ubuntu 10.10
java version 1.6.0_24
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
Reporter: Dan Washusen
Priority: Critical
Under certain conditions the DiskFileItem.write throws a FileNotFound
exception. It seems to be when outputFile.renameTo(file) fails.
{code}java.io.FileNotFoundException:
/tmp/UploadController/uploading/upload_69651d04_13000a31964__8000_1651.tmp
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:106)
at
org.apache.commons.fileupload.disk.DiskFileItem.write(DiskFileItem.java:447)
at upload.UploadController.handle(UploadController.java:90)
...{code}
I can't see any obvious reason why the source file (outputFile) wouldn't
exist...
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057371#comment-13057371
]
Bogdan Drozdowski commented on NET-408:
---
Short-time fix - probably not. As you can see, it's just not that easy. But if
you find an open-source FTP program in Java that works with your ProFTPd, it
might help us create something similar in Commons-Net, so let us know as soon
as you find something.
@David: Yes, TlsProtocolHandler connects TlsClients which have something to do
with session IDs, so this also might be an option. But, as you say, it's not a
drop-in. This would also require a partial or complete re-write of the
FTPSClient. It might be easier to use than PureTLS. Not to mention that it is
more maintained and up-to-date (PureTLS's ChangLog ends on the year 2002).
Unfortunately, still a new dependency for Commons-Net.
problem connecting to ProFTPD with FTPES
Key: NET-408
URL: https://issues.apache.org/jira/browse/NET-408
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2, 3.0
Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
32bit, Kernel 2.6.16.46-0.12-default (config file attached)
ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
Java 1.5
Reporter: Michael Voigt
Attachments: ftpes.jpg, proftpd.conf
I have a problem with the FTPClient connecting to a ProFTPD server.
If the server uses the configuration option TLSProtocol TLSv1, I
cannot connect to it at all. I recieve the following error message:
- javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
On the server side I see in the log:
unable to accept TLS connection: protocol error:
- (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
certificate unknown
- TLS/TLS-C negotiation failed on control channel
If the server uses the configuration option TLSProtocol SSLv23, I
can connect to it but I cant transfer any files. In the server log I
see:
- starting TLS negotiation on data connection
- TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
- client did not reuse SSL session, rejecting data connection (see
TLSOption NoSessionReuseRequired)
- unable to open data connection: TLS negotiation failed
If I add the NoSessionReuseRequired parameter to the ProFTPD config
everything works fine.
Here is my code:
FTPClient ftpClient = new FTPClient();
ftpClient = new FTPSClient(TLS);
// this throws an exception with TLSProtocol TLSv1
ftpClient.connect(host, port);
int reply = ftpClient.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
ftpClient.disconnect();
log.error(The FTP Server did not return a positive
completion reply!);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
}
boolean loginSuccessful = ftpClient.login(userName, password);
if (!loginSuccessful) {
log.error(Login to the FTP Server failed! The
credentials are not valid.);
throw new
FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
}
ftpClient.execPBSZ(0);
ftpClient.execPROT(P);
boolean success = ftpClient.storeFile(fileName, fis);
if (!success) {
// this is false if NoSessionReuseRequired is not set
}
Now my question is if it is generally possible to connect to a server
with TLSProtocol TLSv1 or TLSProtocol SSLv23 without the
NoSessionReuseRequired parameter? Could someone provide a piece of
example code for this?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057382#comment-13057382 ] Matthew Pocock commented on CODEC-125: -- Hi Gary, This code is a port of some PHP code. I kept the names as close as possible for the first attempt. However, I agree with most of your points. Re class names, I will change these. Re resource files, I think we have complete freedom about how to name these files. I'll look at using the standard locale names instead. Re file format, there will be a need over time to keep the Java and PHP code in sync. The plain text files are as close to a mechanical translation of the relevant PHP as possible. It will be significantly harder to keep a format based on java.util.Properties in sync. Re package name, it should actually be bmpm for Beider Morse Phonetic Matching. I shall rename this package. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: bmpm.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057393#comment-13057393 ] Matthew Pocock commented on CODEC-125: -- Re test failures, I have all tests passing on linux with maven and in intellij. I have all tests passing in intellij in windows. However, I see the same problems building from the command-line. If you have any ideas, I'm all ears. Until then I'm going to carry on trying things. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: bmpm.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057439#comment-13057439 ] Matthew Pocock commented on CODEC-125: -- Got it. On linux and in intellij, the resources are being loaded as UTF8. Through the windows shell, the resources are being loaded as Cp1252. This is a new one on me - I kind of expect resources stored in the classpath to be platform independent. Anyway, I've hard-wired the scanners that eat these resources to UTF8 and now the tests pass for me in the windows command line. I will upload a revised patch once I've addressed the naming issues you raised. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: bmpm.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057442#comment-13057442 ] Gary D. Gregory commented on CODEC-125: --- Sounds good Matthew. The default code page in Java is OS dependent, as you found out, Cp1252 on Windows. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: bmpm.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CODEC-125) Implement a Beider-Morse phonetic matching codec
[ https://issues.apache.org/jira/browse/CODEC-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthew Pocock updated CODEC-125: - Attachment: bmpm.patch Here is a new patch that passes tests on windows 7 for me and has the classes/packages renamed as discussed. The java Locale class doesn't have constants for several of the languages covered here, so for now I've left off moving over to ISO language codes, as I'd need to by-hand maintain an iso language code to country name mapping. Implement a Beider-Morse phonetic matching codec Key: CODEC-125 URL: https://issues.apache.org/jira/browse/CODEC-125 Project: Commons Codec Issue Type: New Feature Reporter: Matthew Pocock Priority: Minor Attachments: bmpm.patch, bmpm.patch I have implemented Beider Morse Phonetic Matching as a codec against the commons-codec svn trunk. I would like to contribute this to commons-codec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-607) Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets.
Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets. - Key: MATH-607 URL: https://issues.apache.org/jira/browse/MATH-607 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: Java Reporter: greg sterijevski Fix For: 3.0 The current multiple regression class does a QR decomposition on the complete data set. This necessitates the loading incore of the complete dataset. For large datasets, or large datasets and a requirement to do datamining or stepwise regression this is not practical. There are techniques which form the normal equations on the fly, as well as ones which form the QR decomposition on an update basis. I am proposing, first, the specification of an UpdatingLinearRegression interface which defines basic functionality all such techniques must fulfill. Related to this 'updating' regression, the results of running a regression on some subset of the data should be encapsulated in an immutable object. This is to ensure that subsequent additions of observations do not corrupt or render inconsistent parameter estimates. I am calling this interface RegressionResults. Once the community has reached a consensus on the interface, work on the concrete implementation of these techniques will take place. Thanks, -Greg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-607) Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets.
[ https://issues.apache.org/jira/browse/MATH-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] greg sterijevski updated MATH-607: -- Attachment: updating_reg_ifaces This is the patch file with the proposed changes. Current Multiple Regression Object does calculations with all data incore. There are non incore techniques which would be useful with large datasets. - Key: MATH-607 URL: https://issues.apache.org/jira/browse/MATH-607 Project: Commons Math Issue Type: New Feature Affects Versions: 3.0 Environment: Java Reporter: greg sterijevski Labels: Gentleman's, QR, Regression, Updating, decomposition, lemma Fix For: 3.0 Attachments: updating_reg_ifaces Original Estimate: 840h Remaining Estimate: 840h The current multiple regression class does a QR decomposition on the complete data set. This necessitates the loading incore of the complete dataset. For large datasets, or large datasets and a requirement to do datamining or stepwise regression this is not practical. There are techniques which form the normal equations on the fly, as well as ones which form the QR decomposition on an update basis. I am proposing, first, the specification of an UpdatingLinearRegression interface which defines basic functionality all such techniques must fulfill. Related to this 'updating' regression, the results of running a regression on some subset of the data should be encapsulated in an immutable object. This is to ensure that subsequent additions of observations do not corrupt or render inconsistent parameter estimates. I am calling this interface RegressionResults. Once the community has reached a consensus on the interface, work on the concrete implementation of these techniques will take place. Thanks, -Greg -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
