[jira] [Commented] (NET-443) Threads are in State RUNNABLE FTPCLient
[ https://issues.apache.org/jira/browse/NET-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227334#comment-13227334 ] Dominic Soundranayagam commented on NET-443: Hi Korcan I had faced the same issue couple of day before. I have two projects in my workspace both are related to FTP .One has the JRE 6 and other one is on JDK1.6_25 ,So when i ran the ftp.listFiles() the programme got hang.I tried with the ftp.setConnectionTimeOut() and derived the getResponseString() it said try to connect to channel and the return code was 150. Its absolutly wored. WHen i changed the environment to JDK 1.6_26 it worked Well.. Threads are in State RUNNABLE FTPCLient --- Key: NET-443 URL: https://issues.apache.org/jira/browse/NET-443 Project: Commons Net Issue Type: Bug Components: FTP Environment: WIN2003 Reporter: Korcan Labels: newbie Original Estimate: 612h Remaining Estimate: 612h Hi there, I have developed new application which uses apachi commons.net FTPClient to connect to a Windows OS FTP Server and checks approximately 4000 folders on FTP Server. I am generating Threads to minimize the looping over folders.Every thread tries to loop for example 250 folders.When i run the application on my local computer WinXP no problem.When i yesterday installed WIN2003 Server and run the application i realized that program runs , tries 3-5 times for every thread and sleeps ...and suddenly i see that threads are blocked. I use JRE6 and JConsole also i can see very well that every thread are in state RUNNABLE and RMI TCP threads are time waited state.I could not find any solution the whole day. is it api problem or JRE problem or OS problem? Thanks in advance for your helps BTW there is a code ftp.listfiles(); threads are waiting for this i think but why i dont know -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-765) Refactoring the vector and matrix classes
[
https://issues.apache.org/jira/browse/MATH-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard updated MATH-765:
---
Description:
{panel:title=Warning|borderStyle=solid}
This is not a bug report, but rather a summary of all discussions which have
taken place on the mailing list regarding the refactoring of the vector and
matrix classes. Indeed, it has been argued many times that the {{RealVector}}
and {{RealMatrix}} interfaces are really cluttered, and could benefit from
other approaches (like functional programming).
The description of this ticket will be updated as the discussion progresses on
the mailing-list, and new JIRA tickets will be created to carry out the real
work. {color:red}In order to keep this ticket tidy, contributors should refrain
from commenting on this website. Instead, messages should be posted on the dev
mailing-list{color}.
{panel}
h1. The current API (version 3.0)
In this section, the current interfaces for vectors and matrices are compared.
Vectors and matrices are two mathematical objects which are very close in
nature. Their implementations should therefore be as similar as possible. The
methods will be sorted as follows
* methods reflecting the mathematical structure of vector space: addition,
multiplication by a scalar, matrix-vector product, ...
* methods reflecting the mathematical structure of euclidean space
* ...
h2. Methods reflecting the mathematical structure of vector space
h3. List of the methods
|| {{RealVector}} || {{RealMatrix}}
|| Comments ||
| {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix m)}}
| |
| {{int getDimension()}}| {{int getRowDimension()}},\\
{{int getColumnDimension()}} | |
| {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}}
| (1) |
| {{RealVector outerProduct(RealVector v)}} |
| |
| | {{double getTrace()}}
| |
| | {{multiply(RealMatrix m)}}
| |
| | {{double[] operate(double[])}}
| (2) |
| | {{RealVector
operate(RealVector)}}| |
| | {{RealMatrix power(int p)}}
| |
| | {{double[]
preMultiply(double[])}}| (2) |
| | {{RealMatrix
preMultiply(RealMatrix)}}| |
| | {{RealVector
preMultiply(RealVector)}}| |
| | {{RealMatrix transpose()}}
| |
h3. Comments on the above methods
h4. Comment (1)
{{RealVector RealVector.mapMultiply(double)}} and {{RealMatrix
RealMatrix.scalarMultiply(double)}} perform essentially the same task.
Readibility of the classes would be improved if they add the same name. This is
very important since these methods reflect the fact that the space of vectors
as well as the space of matrices are two vector spaces.
h4. Comment (2)
Prior to the release of version 3.0, all methods taking as argument, or
returning, {{double[]}} as a representation of vectors were removed. The
rationale for this is that calling {{new ArrayRealVector(double[], false)}} is
very easy, and comes at virtually no cost (see MATH-653 and MATH-660). It might
be worth considering the same simplification for the {{RealMatrix}} interface.
h2. Methods reflecting the mathematical structure of euclidean space
h3. List of the methods
|| {{RealVector}} || {{RealMatrix}} || Comments ||
| {{double cosine(RealVector v)}} | | |
| {{double dotProduct(RealVector v)}} | | (3) |
| {{double getDistance(RealVector v)}}| | |
| {{double getNorm()}}| | |
| {{RealVector projection(RealVector v)}} | | |
| {{void unitize()}} | | (4) |
| {{RealVector unitVector()}} | | |
h3. Comments on the above methods
h4. Comment (3)
In a way, {{RealMatrix RealMatrix.transpose()}} could be seen as a method
inherent to the euclidean structure, and the generalization of the dot product.
For this reason, {{transpose()}} should probably _not_ be
[jira] [Commented] (CSV-34) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/CSV-34?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227352#comment-13227352 ] Emmanuel Bourg commented on CSV-34: --- volatile prevents the variables from being cached in the registers and creates a memory barrier, so that's not that surprising to see an impact on the performances. But I admit I didn't expect as much as 5%. That's probably because the parser calls the format properties many time on every character read. CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: CSV-34 URL: https://issues.apache.org/jira/browse/CSV-34 Project: Commons CSV Issue Type: Bug Reporter: Sebb Fix For: 1.0 Attachments: CSVFormat.java CSVFormat describes itself as immutable, but it is not @Immutable - the class fields are all mutable. The methods that change the fields do so by creating a clone, and returning the changed clone. So in a sense the class is immutable. However, the normal expectation is that @Immutable classes are @ThreadSafe. CSVFormat is not thread-safe, because the fields are not volatile, and the fields are not written read using a common lock. The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANSELAN-66) Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
[
https://issues.apache.org/jira/browse/SANSELAN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Piyush Kapoor updated SANSELAN-66:
--
Attachment: tiffimage.patch
I have removed the byte order from static to private , but there are some
additional arguments in some of the api . Please have a look at it.
Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
---
Key: SANSELAN-66
URL: https://issues.apache.org/jira/browse/SANSELAN-66
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Environment: Windows 7 64 bit
Reporter: Piyush Kapoor
Labels: patch
Attachments: BinaryFileParser.java.patch, tiffimage.patch
Original Estimate: 1h
Remaining Estimate: 1h
We have a very large Tiff image tha uses 16 bits for each pixel (bits per
sample total = 48) . The class
org.apache.commons.sanselan.common.Bitinputstream didn't have support for
Endianness of the Tiff format . I added that support in the patch and image
worked absolutely fine.
The image is very large . If you want i can upload it (140 mb).Otherwise here
is the patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Reporter: Emmanuel Bourg
{{CSVFormat}} has two parameters to control how the leading and trailing spaces
around values are handled, but the actual behavior depends on the value being
enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the delimiter
and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated CSV-54:
--
Component/s: Parser
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Components: Parser
Reporter: Emmanuel Bourg
{{CSVFormat}} has two parameters to control how the leading and trailing
spaces around values are handled, but the actual behavior depends on the
value being enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the
delimiter and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated CSV-54:
--
Fix Version/s: 1.0
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
{{CSVFormat}} has two parameters to control how the leading and trailing
spaces around values are handled, but the actual behavior depends on the
value being enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the
delimiter and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
The current implementation of {{getRecords()}} uses a while(true) loop, that
gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227540#comment-13227540
]
Emmanuel Bourg commented on CSV-54:
---
I suggest replacing {{leading/trailingSpacesIgnored}} with two parameters:
- {{interleavedSpacesIgnored}}: this will ignore the spaces between the
delimiter and the opening quote, and between the closing quote and the next
delimiter.
- {{trimmedSpaces}}: this will remove the spaces around the values, on the left
and on the right. I don't see the need to trim only on one side and not the
other.
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
{{CSVFormat}} has two parameters to control how the leading and trailing
spaces around values are handled, but the actual behavior depends on the
value being enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the
delimiter and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
I do not think we need to tickets for this kind of change.
Gary
On Mar 12, 2012, at 9:59, Benedikt Ritter (Created) (JIRA) j...@apache.org
wrote:
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
The current implementation of {{getRecords()}} uses a while(true) loop, that
gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-63) Implement NYSIIS
[ https://issues.apache.org/jira/browse/CODEC-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-63. -- Resolution: Fixed Implement NYSIIS Key: CODEC-63 URL: https://issues.apache.org/jira/browse/CODEC-63 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.x Reporter: Henri Yandell Fix For: 1.7 Attachments: CODEC-63-reworked.tar, Nysiis.patch, codec-63-nysiis-ggregory.diff http://en.wikipedia.org/wiki/NYSIIS -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
[
https://issues.apache.org/jira/browse/CSV-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved CSV-55.
---
Resolution: Fixed
Fix Version/s: 1.0
Thank you, that's fixed on the trunk.
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
Fix For: 1.0
Attachments: CSV-55.txt
The current implementation of {{getRecords()}} uses a while(true) loop, that
gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
[
https://issues.apache.org/jira/browse/CSV-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-55:
---
Attachment: CSV-55.txt
patch attached ;)
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Key: CSV-55
URL: https://issues.apache.org/jira/browse/CSV-55
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Priority: Trivial
Fix For: 1.0
Attachments: CSV-55.txt
The current implementation of {{getRecords()}} uses a while(true) loop, that
gets canceled by an if statement:
{code:java}
while (true) {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
if(reusableToken.type != TOKEN) {
break;
}
}
{code}
This should be replaced by a do-while-loop:
{code:java}
do {
reusableToken.reset();
lexer.nextToken(reusableToken);
// omitted
} while (reusableToken.type == TOKEN);
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-56) Do not use exotic escape characters for sequences like \r or \n
Do not use exotic escape characters for sequences like \r or \n --- Key: CSV-56 URL: https://issues.apache.org/jira/browse/CSV-56 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.0 The parser is able to recognize escape sequences like \r and \n, and transform them automatically. But if the format is changed to use another escape character like !, the parser will also replace !n and !r, which is rather unusual. The replacement should be independent from the escape character defined in the format. This escape character should only be used to escape a delimiter, a quote or a line separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-56) Do not use exotic escape characters for sequences like \r or \n
[ https://issues.apache.org/jira/browse/CSV-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227654#comment-13227654 ] Sebb commented on CSV-56: - I think there are two kinds of escaping here. Sequences such as \r and \n are used to encode characters that cannot easily be expressed in a string. This is different from the need to prevent meta-characters from being treated as such, as in regular expresssions where . is a meta-character and \. is a literal .. The Javadoc needs to be very clear on exactly what the escape character is used for. Do not use exotic escape characters for sequences like \r or \n --- Key: CSV-56 URL: https://issues.apache.org/jira/browse/CSV-56 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.0 The parser is able to recognize escape sequences like \r and \n, and transform them automatically. But if the format is changed to use another escape character like !, the parser will also replace !n and !r, which is rather unusual. The replacement should be independent from the escape character defined in the format. This escape character should only be used to escape a delimiter, a quote or a line separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-56) Do not use exotic escape characters for sequences like \r or \n
[ https://issues.apache.org/jira/browse/CSV-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227660#comment-13227660 ] Emmanuel Bourg commented on CSV-56: --- I agree, I also think it should be possible to disable the transformation of \n sequences. People reading files with Windows paths should appreciate. Do not use exotic escape characters for sequences like \r or \n --- Key: CSV-56 URL: https://issues.apache.org/jira/browse/CSV-56 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.0 The parser is able to recognize escape sequences like \r and \n, and transform them automatically. But if the format is changed to use another escape character like !, the parser will also replace !n and !r, which is rather unusual. The replacement should be independent from the escape character defined in the format. This escape character should only be used to escape a delimiter, a quote or a line separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227659#comment-13227659
]
Sebb commented on CSV-54:
-
I'm not sure I would expect any space removal to ever occur within quoted
values.
Surely that's one of the reasons why values are quoted - to prevent removal of
spaces.
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
{{CSVFormat}} has two parameters to control how the leading and trailing
spaces around values are handled, but the actual behavior depends on the
value being enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the
delimiter and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227699#comment-13227699
]
Emmanuel Bourg commented on CSV-54:
---
The reason for enclosing the values into quotes is to put a delimiter or a line
separator in the value. Spaces are always part of the value, quoted or not. At
least that's how it's specified in RFC 4180.
Confusing semantic of the ignore leading/trailing spaces parameters
---
Key: CSV-54
URL: https://issues.apache.org/jira/browse/CSV-54
Project: Commons CSV
Issue Type: Bug
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
{{CSVFormat}} has two parameters to control how the leading and trailing
spaces around values are handled, but the actual behavior depends on the
value being enclosed in quotes or not.
If the value is not enclosed in quotes, setting
{{leading/trailingSpacesIgnored}} to {{true}} will left or right trim the
value. For example with this input (using the default format):
{code}a, b ,c{code}
the second value will be equal to {{'b'}}.
But if the value is enclosed into quotes, the value is no longer trimmed:
{code}a, b ,c{code}
this will give {{' b '}}.
With quoted values the parser actually ignores the spaces between the
delimiter and the quote. Thus with this input:
{code}a, b ,c{code}
The value returned is {{' b '}}.
If {{leading/trailingSpacesIgnored}} is set to {{false}}, we get instead {{'
b '}} which is consistent with RFC 4180.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-57) CSVParser.getRecords() contract is confusing
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all records
from the current position instead of all values in the parsed file. This
implies that users will first iterate over the records using the iterator and
then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should return
an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227751#comment-13227751 ] Hanson Char commented on CODEC-134: --- Hi Gary, did you get a chance to try out the patch ? Base32 would decode some invalid Base32 encoded string into arbitrary value --- Key: CODEC-134 URL: https://issues.apache.org/jira/browse/CODEC-134 Project: Commons Codec Issue Type: Bug Affects Versions: 1.6 Environment: All Reporter: Hanson Char Labels: security Attachments: diff-120305-20.txt Example, there is no byte array value that can be encoded into the string C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===, but the existing Base32 implementation would not reject it but decode it into an arbitrary value which if re-encoded again using the same implementation would result in the string C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===. Instead of blindly decoding the invalid string, the Base32 codec should reject it (eg by throwing IlleglArgumentException) to avoid security exploitation (such as tunneling additional information via seemingly valid base 32 strings). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227754#comment-13227754
]
Emmanuel Bourg commented on CSV-57:
---
The use case it to first read the headers, and then the content of the file.
I agree on the null return value, an empty array is better to avoid a null
check.
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227772#comment-13227772
]
Benedikt Ritter commented on CSV-57:
Okay, how about providing {{public String[] getHeaders()}} in addition?
{{getRecords()}} and the iterator would then just operate on the records.
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227774#comment-13227774 ] Gary D. Gregory commented on CODEC-134: --- Yes, it works but that is not issue ATM. The issues are: (1) if the behavior is changed, when is it OK to do so, 1.7 or 2.0? (2) is it better to provide a strict version of the class No consensus has emerged to far. See the thread [codec] What version should implement a behavior change? on the dev ML. Base32 would decode some invalid Base32 encoded string into arbitrary value --- Key: CODEC-134 URL: https://issues.apache.org/jira/browse/CODEC-134 Project: Commons Codec Issue Type: Bug Affects Versions: 1.6 Environment: All Reporter: Hanson Char Labels: security Attachments: diff-120305-20.txt Example, there is no byte array value that can be encoded into the string C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===, but the existing Base32 implementation would not reject it but decode it into an arbitrary value which if re-encoded again using the same implementation would result in the string C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===. Instead of blindly decoding the invalid string, the Base32 codec should reject it (eg by throwing IlleglArgumentException) to avoid security exploitation (such as tunneling additional information via seemingly valid base 32 strings). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227785#comment-13227785
]
Emmanuel Bourg commented on CSV-57:
---
Or simply make {{String[] getRecord()}} public.
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227800#comment-13227800
]
Benedikt Ritter commented on CSV-57:
I'm afraid that making {{getRecord()}} public will cause trouble with the
iterator. At least it should be mentioned in the javadoc, that calling
{{getRecord()}} during an iteration will cause the iterator to skip an element
(and in the worst case cause a {{NoSuchElementException}}).
If there is the concept of a header in CSV, why not provide a method that is
specific for this purpose?
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227896#comment-13227896
]
Emmanuel Bourg commented on CSV-57:
---
Let's discuss the headers on the list, there are many ideas to explore.
CSVParser.getRecords() contract is confusing
Key: CSV-57
URL: https://issues.apache.org/jira/browse/CSV-57
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Reporter: Benedikt Ritter
Priority: Minor
{{CSVParser.getRecords()}} has a confusing contract. It will return all
records from the current position instead of all values in the parsed file.
This implies that users will first iterate over the records using the
iterator and then call getRecords(). This seems like an unlikely use case.
Also, it is not good practice to return {{null}}. So getRecords() should
return an empty array, if no records can be found.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-136) Reloading may corrupt the configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227903#comment-13227903
]
Oliver Heger commented on CONFIGURATION-136:
I had a look at the patch, but I am not sure whether I fully understand what
you intend. I expected something similar to what Emmanuel had suggested in his
comments, i.e. a modification of the {{reload()}} method to temporarily store
the configuration's content before it is loaded again from disk.
But you modified the {{save()}} method. It looks like that you try to restore
the original content of the configuration if an error occurs during saving.
This does not solve the problem this ticket is about.
Also, are you sure that your solution is robust? I mean, if you get an error on
saving (maybe because the disk is full or not readable), how likely is it that
the rollback operation succeeds?
Reloading may corrupt the configuration
---
Key: CONFIGURATION-136
URL: https://issues.apache.org/jira/browse/CONFIGURATION-136
Project: Commons Configuration
Issue Type: Bug
Components: File reloading
Affects Versions: 1.1
Reporter: nicolas de loof
Fix For: 1.9
Attachments: commons-configuration-1.5_patch_CONFIGURATION-136.jar,
commons-configuration-1.8_patch_CONFIGURATION-136.jar, patch.txt
Current reloading process clears current properties and load updated values
from
resource reader. If an IO error occurs (or invalid format), the configuration
gets corrupted and the application becomes unstable.
It may be better for hot-reload to put loaded values into a temporary
Properties
and replace previous values only when reloading is successful.
It may also allow to use a 'currentlty-reloading' flag in the synchronized
'reload' block to avoid blocking threads during a reload (they could access
safelly the 'old' properties until reload is finished)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-482) Optional dependencies are not marked optional in the manifest's Import-Package section
[ https://issues.apache.org/jira/browse/CONFIGURATION-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13227912#comment-13227912 ] Oliver Heger commented on CONFIGURATION-482: Hm, you are right. Then I wonder why it does not work as expected. Is a special configuration required? I will have to study the plug-in documentation. Any hints are welcome! Optional dependencies are not marked optional in the manifest's Import-Package section -- Key: CONFIGURATION-482 URL: https://issues.apache.org/jira/browse/CONFIGURATION-482 Project: Commons Configuration Issue Type: Bug Components: Build Affects Versions: 1.8 Reporter: Chris Seieroe Priority: Minor The following page lists the runtime dependencies based on the components. This is reflected in the pom file since many are listed as optional (e.g. commons-jexl). However, if you want to use commons-configuration in an OSGi container, those become required because the corresponding packages are listed in the manifest's Import-Package section. They do not have the resolution:=optional qualifier on it so you get an error if you do not include something like commons-jexl yourself. http://commons.apache.org/configuration/dependencies.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-51) Support unicode line separators
[ https://issues.apache.org/jira/browse/CSV-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228058#comment-13228058 ] Sebb commented on CSV-51: - Would these be used as an alternative to CR/LF? Or would both be operative at the same time? Are there any example files that use such separators? Support unicode line separators --- Key: CSV-51 URL: https://issues.apache.org/jira/browse/CSV-51 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.x CSVParser doesn't recognizes the Unicode characters U+2028 (LINE SEPARATOR), U+2029 (PARAGRAPH SEPARATOR) and U+0085 (NEXT LINE) as line separators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CSV-51) Support unicode line separators
[ https://issues.apache.org/jira/browse/CSV-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228079#comment-13228079 ] Emmanuel Bourg commented on CSV-51: --- They would be used in addition to the existing line separators. The Scanner and Pattern classes in the JDK do recognize these separators for example, but not BufferedReader. Support unicode line separators --- Key: CSV-51 URL: https://issues.apache.org/jira/browse/CSV-51 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.x CSVParser doesn't recognizes the Unicode characters U+2028 (LINE SEPARATOR), U+2029 (PARAGRAPH SEPARATOR) and U+0085 (NEXT LINE) as line separators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
