[jira] [Commented] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established
[ https://issues.apache.org/jira/browse/NET-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13258318#comment-13258318 ] Sebb commented on NET-459: -- Where exactly does the method block? Can you take a thread dump to see? FTPClient.storeFile never returns in active mode if data channel cannot be established -- Key: NET-459 URL: https://issues.apache.org/jira/browse/NET-459 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1, 3.1 Reporter: Jaroslav Chmurny FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout). -- 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] (IO-323) What should happen in FileUtils.sizeOf[Directory] when an overflow takes place?
[ https://issues.apache.org/jira/browse/IO-323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13254935#comment-13254935 ] Sebb commented on IO-323: - bq. How about a BigInteger method that will give you the right answer no matter now big? File a separate JIRA enhancement request? What should happen in FileUtils.sizeOf[Directory] when an overflow takes place? --- Key: IO-323 URL: https://issues.apache.org/jira/browse/IO-323 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.3 Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) Maven home: C:\Java\apache-maven-3.0.4\bin\.. Java version: 1.6.0_31, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_31\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory FileUtils.sizeOf[Directory] adds longs. What should happen when an overflow happens? -- 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] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253283#comment-13253283
]
Sebb commented on NET-458:
--
Looks like the problem is caused by trying to split a string containing only
space(s)
MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
---
Key: NET-458
URL: https://issues.apache.org/jira/browse/NET-458
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: zOS
Reporter: Denis Molony
Line 360 in MVSFTPEntryParser.parseSimpleEntry :
String name = entry.split( )[0];
gives an ArrayIndexOutOfBoundsException: 0
It appears to be caused by a partitioned dataset whose members only contain
names. No other details (creation date, file type etc).
This is the method, if it helps:
{code}
private boolean parseSimpleEntry(FTPFile file, String entry) {
if (entry != null entry.length() 0) {
file.setRawListing(entry);
String name = entry.split( )[0]; // --- error occurs here
file.setName(name);
file.setType(FTPFile.FILE_TYPE);
return true;
}
return false;
}
{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] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
[
https://issues.apache.org/jira/browse/LANG-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13252960#comment-13252960
]
Sebb commented on LANG-799:
---
There seems no reason to treat Locale.ENGLISH specially here.
I think option D is the best.
i.e. leave the current behaviour as is (and make sure it's documented), but
allow the Locale to be provided.
DateUtils#parseDate uses default locale instead of US (or trying both default
locale and Locale.English)
Key: LANG-799
URL: https://issues.apache.org/jira/browse/LANG-799
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Reporter: Oliver Kopp
Priority: Minor
Labels: features
Original Estimate: 2h
Remaining Estimate: 2h
Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
Following line throws an ParseException on a German system:
d = DateUtils.parseDate(Wed, 09 Apr 2008 23:55:38 GMT, new String[] {EEE,
dd MMM HH:mm:ss zzz});
Reason: parseDate internally calls SimpleDateFormat without providing a
locale. This causes MMM to be interpreted using the system locale. If the
system is German, the date is trying to be interpreted as German date.
I see following solutions:
A) Always instantiate SimpleDateFormat with Locale.ENGLISH
B) Make two instances of SimpleDateFormat. One without providing a locale
and one with Locale.ENGLISH. Try two parsings
C) Make as many SimpleDateFormat instances as locales are availble iterate
over all instances at the parsing attempts.
D) provide an additional (optional) parameter to parseDate for providing a
Locale
I would prefer B) as this seems the best trade-off between
internationalization and local usage.
What do you think?
--
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] (IO-319) FileUtils.sizeOfDirectory follows symbolic links.
[
https://issues.apache.org/jira/browse/IO-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251777#comment-13251777
]
Sebb commented on IO-319:
-
Symbolic links are likely to be very rare on Windows.
IMO it does not matter if the patch does not fix the crash for Windows hosts,
so long as it does not otherwise change the behaviour on Windows.
FileUtils.sizeOfDirectory follows symbolic links.
-
Key: IO-319
URL: https://issues.apache.org/jira/browse/IO-319
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.1
Reporter: Ravi Prakash
Priority: Critical
Attachments: commons-io-319.patch, commons-io-319.patch
First of all Thanks tons Apache Commons folks for all the amazing work! :) My
first JIRA. Yayyy. I contributed B-)
A symbolic link may create a cycle and so sizeOfDirectory crashes with an
IllegalArgumentException. e.g.
{noformat}
$ tree test
test
├── file
└── ravi
├── cycle - ../../test
└── file
{noformat}
causes FileUtils.sizeOfDirectory to crash like so
{noformat}
java TestJAVA
Exception in thread main java.lang.IllegalArgumentException:
somepath/test/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle
does not exist
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2053)
at
org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at
org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at
org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at
org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
{noformat}
We faced the same issue in Hadoop :(. Checkout
https://issues.apache.org/jira/browse/HADOOP-6963 for our solution
--
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] (EXEC-54) Problem with argument containing spaces
[
https://issues.apache.org/jira/browse/EXEC-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245102#comment-13245102
]
Sebb commented on EXEC-54:
--
Note that the quoting / escaping requirements vary by OS.
AFAIK, not all OSes support escapes, and the mechanism may vary depending on
the shell that is used.
Problem with argument containing spaces
---
Key: EXEC-54
URL: https://issues.apache.org/jira/browse/EXEC-54
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1
Environment: Mac OsX 10.6.6, JVM 1.6.0
Reporter: Jeremias Rößler
Assignee: Siegfried Goeschl
Labels: arguments, quotes, spaces
I am new to Commons Exec, so this could also be an error in usage, but...
When I use the {{CommandLine}} class to add a argument that contains spaces,
some quotes are added and are then part of the argument that is given.
For example: When I call {{java what version}} I get
{{java.lang.NoClassDefFoundError: what version}}, and when I call {{java
\what version\}} (which contains escaped quotes, that are part of the
command line argument itself), I get {{java.lang.NoClassDefFoundError: what
version}}.
So the following test fails, because as you can see in the last line, Apache
Exec is producing the latter version where it should have produced the first
version:
{code:java}
@Test
public void testArgumentQuoting() throws Exception {
String argument = what version;
DefaultExecutor executor = new DefaultExecutor();
DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);
executor.setStreamHandler(streamHandler);
CommandLine cmdLine = new CommandLine(java);
cmdLine.addArgument(argument);
executor.execute(cmdLine, resultHandler);
resultHandler.waitFor();
String resultPattern = Exception in thread \main\
java\\.lang\\.NoClassDefFoundError: ([\\w \]+);
Pattern pattern = Pattern.compile(resultPattern);
Matcher matcher = pattern.matcher(out.toString());
Assert.assertTrue(matcher.find());
// Note: Result should be what version and NOT what
version!
Assert.assertEquals(argument, matcher.group(1));
}
{code}
Note that the same test passes if the space is removed from the argument.
Please also note, that I am not trying to start an external Java process, but
this is merely an example that I assume will work on every developers machine.
--
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-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245570#comment-13245570 ] Sebb commented on CODEC-138: Note: InputStream.reset() throws IOE so I think the patch is correct. Complete FilterInputStream interface for BaseNCodecInputStream -- Key: CODEC-138 URL: https://issues.apache.org/jira/browse/CODEC-138 Project: Commons Codec Issue Type: Improvement Reporter: Thomas Neidhart Fix For: 1.7 Attachments: CODEC-138.patch Small patch to implement mark and reset in a safe manner. markSupported is already implemented, but the other two methods are inherited from the default FilterInputStream implementation, which calls the corresponding methods of the underlying stream. The patch provides a noop implementation for mark, and throws an IOException when reset is called. -- 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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13244472#comment-13244472
]
Sebb commented on CODEC-96:
---
The mark/reset patch should really be on a separate JIRA, as it is nothing to
do with the original thread safety issue.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch, complete_inputstream_interface.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13243742#comment-13243742
]
Sebb commented on CODEC-96:
---
codec-96-3rd-attempt.patch is very old (2010). I think it can be ignored.
CODEX-96-2.patch is the latest patch, but as already mentioned on the dev list
causes Clirr to report errors.
I think these are harmless, as they don't affect the public API as far as I can
tell, but I don't use Codec in earnest.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, CODEX-96-2.patch,
codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-78) Use Character instead of char for char fields except delimiter
[
https://issues.apache.org/jira/browse/CSV-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241211#comment-13241211
]
Sebb commented on CSV-78:
-
I no longer like the idea of using a null Character to disable the setting, as
it entails implicit or explicit boxing for the user code.
Option 2) above was intended to allow the existing char (if any) to be
preserved.
However, using setEscape(true) would need to check if an escape had been set,
so I think it was not a good idea either.
Another possibility would be to provide no-arg versions of the with() methods.
{noformat}
1) withNoEscape() withNoEncapsulator() withNoCommentStart()
3) withEscape() withEncapsulator() withCommentStart()
4) withEscapeNone() withEncapsulatorNone() withCommentStartNone()
{noformat}
Option4 above is just option 1 renamed to look more like the existing methods.
Other renames are possible.
Use Character instead of char for char fields except delimiter
--
Key: CSV-78
URL: https://issues.apache.org/jira/browse/CSV-78
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Apart from the delimiter - which must be specified (obviously) - the other
char fields are optional.
At present it's not possible to create a new format from an existing format
and remove (say) the encapsulation character.
If the parameters were changed to Character instead of char, then it would be
possible to pass null.
--
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-35) Escaped line separators are not supported
[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241295#comment-13241295
]
Sebb commented on CSV-35:
-
The Lexer does currently (r1036896) handle escLF and escCR.
The code currently treats escCRLF as escCR followed by LF. The LF is
handled as EOL.
Escaped line separators are not supported
-
Key: CSV-35
URL: https://issues.apache.org/jira/browse/CSV-35
Project: Commons CSV
Issue Type: Bug
Reporter: Emmanuel Bourg
Fix For: 1.0
Commons CSV doesn't handle escaped line separators, for example:
{code}
value1;value2;value3a\
value3b
{code}
In this case the expected result is:
{code}[value1, value2, value3a\nvalue3b]{code}
This kind of escaping is produced by MySQL, whether the field enclosing is
enabled or not. It's possible to see enclosing quotes and escaped line
separators like this:
{code}
value1;value2;value3a\
value3b
{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-88) Not possible to create a CSVFormat from scratch
[
https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241526#comment-13241526
]
Sebb commented on CSV-88:
-
bq. PRISTINE is useless as a base format because all properties have to be
defined.
No, it's not useless; that's why it was created as empty.
The PRISTINE format provides a base that is untainted by existing settings,
which is why it works well for creating the pre-defined public formats.
The only setting that is absolutely required is the delimiter, which is why I
suggested providing a ctor which takes the delimiter as its only parameter.
As I see it, there are the following possibilities for creating a new basic
format using : as the delimiter.
{code}
fmt1 = new CSVFormat(':');
fmt2 = new CSVFormat().withDelimiter(':');
fmt3 = CSVFormat.PRISTINE.withDelimiter(':');
fmt4 = CSVFormat.newInstance(':');
fmt5 = CSVFormat.newInstance().withDelimiter(':');
{code}
Obviously the constant name PRISTINE can be changed, or the newInstance()
method could be renamed.
Not possible to create a CSVFormat from scratch
---
Key: CSV-88
URL: https://issues.apache.org/jira/browse/CSV-88
Project: Commons CSV
Issue Type: Bug
Reporter: Sebb
It's not possible to create a CSVFormat except by modifying an existing
format.
Could either make the PRISTINE format public, or provide a constructor with a
single parameter (the delimiter).
Could provide a no-args ctor instead, but there seems little point in that.
--
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-52) Keep track of record numbers
[ https://issues.apache.org/jira/browse/CSV-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241528#comment-13241528 ] Sebb commented on CSV-52: - Maybe the number should also be stored in the record? The counter should be long. Keep track of record numbers Key: CSV-52 URL: https://issues.apache.org/jira/browse/CSV-52 Project: Commons CSV Issue Type: Improvement Components: Parser Reporter: Emmanuel Bourg Priority: Minor Fix For: 1.x The parser is able to return the current line number of the file, it should also be able to return the record number. -- 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-90) CSVFormat isEscaping/isEscaping are not public
[ https://issues.apache.org/jira/browse/CSV-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13241969#comment-13241969 ] Sebb commented on CSV-90: - Likewise there could be a public version of getHeader(). It would need to clone the array. CSVFormat isEscaping/isEscaping are not public -- Key: CSV-90 URL: https://issues.apache.org/jira/browse/CSV-90 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVFormat methods isEscaping() and isEncapsulating() are package protected, whereas the other 3 isXXX() methods are public. There seems no reason for this difference. These are external settings - they are defined by the user - so I don't see why the methods should not be public. AFAICT making them public would not commit the API to anything new. -- 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-137) Main documentation page links wrong javadocs
[ https://issues.apache.org/jira/browse/CODEC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240351#comment-13240351 ] Sebb commented on CODEC-137: As a work-round the current Javadocs (i.e. 1.6) are available from the Javadoc (SVN latest) at present. Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor Labels: documentation Original Estimate: 1h Remaining Estimate: 1h http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- 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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240542#comment-13240542
]
Sebb commented on CODEC-96:
---
bq. BaseNCodec has a member xcontext which is never used
Sorry, looks like a bit of debug code I left in
bq. some fields in the Context class are protected, others package private
Should probably all be package private
I'll create an amended patch.
bq. for the BaseNCodecInputStream, the mark/markSupported/reset methods should
be implemented
That's a separate issue; this patch only addresses the thread-safety aspects.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: CODEC-96.patch, codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-88) Not possible to create a CSVFormat from scratch
[ https://issues.apache.org/jira/browse/CSV-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239359#comment-13239359 ] Sebb commented on CSV-88: - bq. +0 for a no arg constructor equivalent to the default format. If you mean the DEFAULT format here then that achieves nothing, as the user would have to override any unwanted settings - and the use would have to know which ones to override. If the DEFAULT format were ever later updated, that could invalidate the user's format. I meant that the ctor should be equivalent to PRISTINE or perhaps PRISTINE + CRLF. To fit in with the fluent API, there needs to be a static method. For example, withDefault(char) would do. Not possible to create a CSVFormat from scratch --- Key: CSV-88 URL: https://issues.apache.org/jira/browse/CSV-88 Project: Commons CSV Issue Type: Bug Reporter: Sebb It's not possible to create a CSVFormat except by modifying an existing format. Could either make the PRISTINE format public, or provide a constructor with a single parameter (the delimiter). Could provide a no-args ctor instead, but there seems little point in that. -- 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-53) Allow to always enclose printed values into quotes
[ https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239364#comment-13239364 ] Sebb commented on CSV-53: - +1 to including an OutputQuoting setting along those lines, e.g. an Enum. Though I don't think we should convert numeric fields to type float! QUOTE_NONE cannot be allowed to generate invalid output, so must either escape or throw an error. So I don't understand what you mean by a separate parameter. Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- 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-53) Allow to always enclose printed values into quotes
[ https://issues.apache.org/jira/browse/CSV-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239491#comment-13239491 ] Sebb commented on CSV-53: - If the user selects QUOTE_NONE then the only options for printing a value which contains a delimiter or EOL - or which starts with the quote character - are: - escape the character(s) - throw an Exception In which case, we just use the escape character setting to determine which to do. [Otherwise the printed output will not be valid, and I don't think we should allow that.] If the user wants to use a different escape setting for parsing and printing, then they can just create a different format. Otherwise we are back into having separate parsing and printing CSVFormat classes, which you already said you did not want. Allow to always enclose printed values into quotes -- Key: CSV-53 URL: https://issues.apache.org/jira/browse/CSV-53 Project: Commons CSV Issue Type: Improvement Components: Printer Reporter: Emmanuel Bourg Fix For: 1.x The printer encloses the values into quotes only if it contains a special character like a field separator or a line separator. However some applications expect the values to always be enclosed into quotes. It's necassary to be able to control how the quotes are added, either always or as needed. -- 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] (JELLY-290) Links to source code in tutorial page are broken
[ https://issues.apache.org/jira/browse/JELLY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239530#comment-13239530 ] Sebb commented on JELLY-290: The files had moved from their original locations, which is why the cvs = svn redirect did not work. Temporary fix applied to HTML files; this should show up in a few hours on the main site. Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor Labels: documentation The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. Thanks -- 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] (JELLY-290) Links to source code in tutorial page are broken
[ https://issues.apache.org/jira/browse/JELLY-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239549#comment-13239549 ] Sebb commented on JELLY-290: Also fixed XML source files so eventual rebuild will hopefully keep the changes Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor Labels: documentation The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. Thanks -- 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-84) Clarify comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240074#comment-13240074 ] Sebb commented on CSV-84: - OK, so we should only allow comments at the start of a record. This may be a bit tricky to achieve, as the lexer knows about tokens, not records. Clarify comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Fix For: 1.0 Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- 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-84) Clarify comment handling
[
https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13240089#comment-13240089
]
Sebb commented on CSV-84:
-
bq. This case is not covered by the tests,
In fact - as I discovered when I tried to fix the code - it is tested.
The test CSVParserTest.testDefaultFormat() includes the CSV source:
{code}
a,b\n
\n, \n
,#\n
{code}
Note that the comment follows the empty quoted value.
However, I think this is mistake.
Clarify comment handling
Key: CSV-84
URL: https://issues.apache.org/jira/browse/CSV-84
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Fix For: 1.0
Comment handling is not currently fully documented / tested.
There are several possible situations:
1) trailing comment following one or more values
2) comment marker starts in the first column
3) comment marker starts in the first non-whitespace column
How should these be handled?
1) The trailing comment should be ignored
2) Entire line should be ignored, i.e. don't treat it as a blank line
3) This is trickier: if whitespace is being trimmed, treat as 2, else treat
as 1, i.e. there is a single value containing whitespace
It might also be useful to consider returning comments to the application
program as part of CSVRecord.
--
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] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238278#comment-13238278
]
Sebb commented on IO-315:
-
I don't think this is a good idea.
There are a lot of different encodings, and who is to say which ones are
useful?
There would still need to be a way to use the String encoding to allow for
encodings that are not provided by the interface.
Also, the code would still need to catch {{UnsupportedEncodingException}}.
As far as I know there is no requirement for a Java class-library to support
any specific encodings, though it would be a fairly useless implementation that
did not support UTF-8.
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
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] (IO-233) Add Methods for Buffering Streams/Writers To IOUtils
[ https://issues.apache.org/jira/browse/IO-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238298#comment-13238298 ] Sebb commented on IO-233: - @Aaron As I understand it, this issue is about adding buffering to I/O classes. Converting between byte and character oriented classes is somewhat different. Add Methods for Buffering Streams/Writers To IOUtils Key: IO-233 URL: https://issues.apache.org/jira/browse/IO-233 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Affects Versions: 2.0 Environment: Java 1.4+ Reporter: Michael Wooten Priority: Minor Fix For: 3.x Original Estimate: 2h Remaining Estimate: 2h I suggest adding utility methods for buffering streams and writers to the IOUtils class. The methods would have the following signatures: BufferedInputStream buffer(InputStream inputStream) BufferedOutputStream buffer(OutputStream outputStream) BufferedReader buffer(Reader reader) BufferedWriter buffer(Writer writer) -- 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-82) CSVRecord inconsistent behaviour when header mapping is not found
[ https://issues.apache.org/jira/browse/CSV-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238362#comment-13238362 ] Sebb commented on CSV-82: - bq. In case 2 a null value is returned, because some column may be optional. I don't understand this concept of optional columns. Surely any CSV header line needs to provide names for all the columns? Otherwise, what's the point of the header line? CSVRecord inconsistent behaviour when header mapping is not found - Key: CSV-82 URL: https://issues.apache.org/jira/browse/CSV-82 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVRecord#get(String) method has inconsistent behaviour. If no header mapping was provided, then it throws IllegalStateException. If the header name is not found, null is returned. Apart from being inconsistent, it might be useful in the future to be able to return null as a column value (as distinct from the empty string). It should throw IllegalArgumentException for a missing header name, instead of returning null. -- 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] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238378#comment-13238378
]
Sebb commented on IO-315:
-
Thanks for the list.
However, I don't think that makes a significant difference.
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
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] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238598#comment-13238598
]
Sebb commented on IO-315:
-
That makes a more sense now, but I think it would be overkill to introduce a
new interface here.
Using Charset would be better IMO.
Using Charset would convert the checked {{UnsupportedEncodingException}} into
the unchecked {{UnsupportedCharsetException}}.
This should simplify application code that does not already catch
{{IOException}}, though of course in Commons IO many methods throw IOE already.
AFAICT, parameters would need to be changed to use (e.g.)
{{Charset.forName(UTF-8)}} instead of {{UTF-8}} so user code would be
slightly longer.
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
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-73) HSQLDB supports two different field separators
[ https://issues.apache.org/jira/browse/CSV-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238623#comment-13238623 ] Sebb commented on CSV-73: - Nor do I, but for whatever reason, they do use two different separators. HSQLDB supports two different field separators -- Key: CSV-73 URL: https://issues.apache.org/jira/browse/CSV-73 Project: Commons CSV Issue Type: New Feature Reporter: Sebb HSQLDB supports a second field separator for VARCHAR fields according to: http://www.hsqldb.org/doc/2.0/guide/texttables-chapt.html#ttc_configuration Do we want to implrment this? -- 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-86) Remove current character input parameter from Lexer methods
[ https://issues.apache.org/jira/browse/CSV-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238827#comment-13238827 ] Sebb commented on CSV-86: - I cannot see the point of dropping the current char from the simpleTokenLexer method call if the first thing it does is fetch the char by invoking in.readAgain(). Remove current character input parameter from Lexer methods --- Key: CSV-86 URL: https://issues.apache.org/jira/browse/CSV-86 Project: Commons CSV Issue Type: Sub-task Components: Parser Reporter: Benedikt Ritter Fix For: 1.0 Attachments: CSV-86.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] [Commented] (CSV-85) Allow comments to be returned in CSVRecord
[
https://issues.apache.org/jira/browse/CSV-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238863#comment-13238863
]
Sebb commented on CSV-85:
-
{code}
a,b,c#Inline comment (1)
#Separate comment (2)
d,e,f,#Inline comment (3)
{code}
In the first case, the record would have 3 values and a comment, in the second,
0 values and a comment, and the 3rd would have 4 values and a comment.
At present, the code treats (1) as part of the 3rd value, but it does allow
case (3) - but thinks there are 3 values.
Maybe only separate comment lines should be allowed, but that is not the case
currently.
Allow comments to be returned in CSVRecord
--
Key: CSV-85
URL: https://issues.apache.org/jira/browse/CSV-85
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
It might be useful to provide a comment field in the CSVRecord class.
This would be null if no comment is present for that record.
A line consisting of only a comment would have a size() of 0.
--
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-84) Comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238874#comment-13238874 ] Sebb commented on CSV-84: - I don't know if there are formats with inline comments. The code currently recognises comments at the start of a value as well as at the start of a record. This behaviour may be unintentional. I agree that empty lines are generally not needed, but a comment line may not be useless. Comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- 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-83) Provide a header encapsulator class
[ https://issues.apache.org/jira/browse/CSV-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238876#comment-13238876 ] Sebb commented on CSV-83: - bq. This would allow more a more flexible implementation if required. Provide a header encapsulator class --- Key: CSV-83 URL: https://issues.apache.org/jira/browse/CSV-83 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Might be useful to have a class to encapsulate the headers, rather than assuming they are stored as a map. This would allow more a more flexible implementation if required. Methods which it would be useful to have: - getIndex(name) - could return -1 for unknown name? - iterator() -- 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-85) Allow comments to be returned in CSVRecord
[ https://issues.apache.org/jira/browse/CSV-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238916#comment-13238916 ] Sebb commented on CSV-85: - OK, that makes sense, and should be relatively easy to implement. The only detail still missing is what to do about the header record (if specified). It would be simplest to just treat it as a normal record, i.e. comments would be ignored when evaluating the column names. Allow comments to be returned in CSVRecord -- Key: CSV-85 URL: https://issues.apache.org/jira/browse/CSV-85 Project: Commons CSV Issue Type: Improvement Reporter: Sebb It might be useful to provide a comment field in the CSVRecord class. This would be null if no comment is present for that record. A line consisting of only a comment would have a size() of 0. -- 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-77) RFC 4180 (DEFAULT) format is wrong; should not ignore spaces or blank lines
[
https://issues.apache.org/jira/browse/CSV-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238991#comment-13238991
]
Sebb commented on CSV-77:
-
I think we should keep the strict RFC4180 definition.
RFC 4180 (DEFAULT) format is wrong; should not ignore spaces or blank lines
---
Key: CSV-77
URL: https://issues.apache.org/jira/browse/CSV-77
Project: Commons CSV
Issue Type: Bug
Reporter: Sebb
According to the RFC [1]:
Section 2.4
{quote}
... Spaces are considered part
of a field and should not be ignored.
{quote}
Also, the RFC does not mention that blank lines are to be ignored.
However, some of the alternate CSV specifications referenced by RFC 4180 do
say that spaces are ignored.
I've not yet found a mention to say that blank lines are to be ignored.
[1] http://tools.ietf.org/html/rfc4180
--
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-83) Provide a header encapsulator class
[ https://issues.apache.org/jira/browse/CSV-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239032#comment-13239032 ] Sebb commented on CSV-83: - It looks as though the header Map is not part of the public API. If that is the case then using a separate encapsulator class is not necessary. We could change the headers to be (e.g.) a sorted list - if that were more efficient - without affecting the API. It's not good to over-engineer, but IMO it's worse to expose internal implementation details in the public API, which is why I raised the issue initially. Provide a header encapsulator class --- Key: CSV-83 URL: https://issues.apache.org/jira/browse/CSV-83 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Might be useful to have a class to encapsulate the headers, rather than assuming they are stored as a map. This would allow more a more flexible implementation if required. Methods which it would be useful to have: - getIndex(name) - could return -1 for unknown name? - iterator() -- 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-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239072#comment-13239072 ] Sebb commented on CSV-75: - Yes, perhaps it should be done by the lexer. But the quickest fix would be to patch the reader. I wonder whether ExtendedBufferReader is actually necessary; lookAhead() could easily be provided by the Lexer class. And I'm not sure that readAgain() is really necessary. ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- 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-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13239084#comment-13239084 ] Sebb commented on CSV-75: - Enabled new test and added patch to fix it. But we should still consider if ExtendedBufferReader is really necessary. ExtendedBufferReader does not handle EOL consistently - Key: CSV-75 URL: https://issues.apache.org/jira/browse/CSV-75 Project: Commons CSV Issue Type: Bug Reporter: Sebb Attachments: CSV-75.patch ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found. However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them). If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator. It should work if the code increments the line counter for CR, and for LF if the previous character was not CR. -- 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-86) Remove current character input parameter from Lexer methods
[ https://issues.apache.org/jira/browse/CSV-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238032#comment-13238032 ] Sebb commented on CSV-86: - As I wrote on the dve list, the current character may perhaps be required for the readEscape method. Remove current character input parameter from Lexer methods --- Key: CSV-86 URL: https://issues.apache.org/jira/browse/CSV-86 Project: Commons CSV Issue Type: Sub-task Components: Parser Reporter: Benedikt Ritter Fix For: 1.0 Attachments: CSV-86.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] [Commented] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238039#comment-13238039 ] Sebb commented on CSV-70: - Yes, I tried something similar and it broke the tests. I think it would be useful to provide (optional) access to the comment fields so one way to solve this would be to return the comment as a token, and deal will it at the record level. Improve readability of CSVLexer --- Key: CSV-70 URL: https://issues.apache.org/jira/browse/CSV-70 Project: Commons CSV Issue Type: Improvement Components: Parser Affects Versions: 1.0 Reporter: Benedikt Ritter Fix For: 1.0 There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() * Add convenience methods isDelimiter(c) and isEncapsulator(c) * Remove current caracter input parameter from methods * If possible: replace while(true) loops -- 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-84) Comment handling
[
https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13237549#comment-13237549
]
Sebb commented on CSV-84:
-
At present (r1304503), the comment introducer is not recognised whilst
processing a value.
It is only recognised at the start of a value.
This seems wrong, as it makes it impossible to add a trailing comment to the
end of a record without adding a preceeding delimiter. This is not consistent,
see below:
{code}
# No comment following, 4 values found
a,b,c,dEOL
d,e,f,g# comment treated as part of 4th valueEOL
h,i,j,k,# this will be recognised as a comment following 4 fieldsEOL
l,m,n,o,EOL
# previous line should have 5 fields but actually gets merged to previous line.
{code}
Comments currently only work correctly at the start of a record.
Comment handling
Key: CSV-84
URL: https://issues.apache.org/jira/browse/CSV-84
Project: Commons CSV
Issue Type: New Feature
Reporter: Sebb
Comment handling is not currently fully documented / tested.
There are several possible situations:
1) trailing comment following one or more values
2) comment marker starts in the first column
3) comment marker starts in the first non-whitespace column
How should these be handled?
1) The trailing comment should be ignored
2) Entire line should be ignored, i.e. don't treat it as a blank line
3) This is trickier: if whitespace is being trimmed, treat as 2, else treat
as 1, i.e. there is a single value containing whitespace
It might also be useful to consider returning comments to the application
program as part of CSVRecord.
--
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-35) Escaped line separators are not supported
[
https://issues.apache.org/jira/browse/CSV-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236649#comment-13236649
]
Sebb commented on CSV-35:
-
What should happen in the case of escapeCRLF?
I presume only the CR should be subject to the escape.
If an application wants to include CRLF in a field, then the application should
generate escapeCRescapeLF.
Escaped line separators are not supported
-
Key: CSV-35
URL: https://issues.apache.org/jira/browse/CSV-35
Project: Commons CSV
Issue Type: Bug
Reporter: Emmanuel Bourg
Fix For: 1.0
Commons CSV doesn't handle escaped line separators, for example:
{code}
value1;value2;value3a\
value3b
{code}
In this case the expected result is:
{code}[value1, value2, value3a\nvalue3b]{code}
This kind of escaping is produced by MySQL, whether the field enclosing is
enabled or not. It's possible to see enclosing quotes and escaped line
separators like this:
{code}
value1;value2;value3a\
value3b
{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=13236661#comment-13236661
]
Sebb commented on CSV-54:
-
Definitely better to drop the separate leading/trailing space options.
However, I think interleavedSpacesIgnored should apply for both quoted and
unquoted values.
As far as I can tell, that is the expectation in the CSV format specs I've seen.
The trimmedSpaces setting would then be identical to
interleavedSpacesIgnored for unquoted values.
For quoted values it would also trim the enclosed value; not sure that's
particularly useful to provide as part of CSV.
It's easy enough for the application to trim the fields, so I'm not sure the
setting is necessary.
Seems like it is straying away from the basic purpose of CSV.
However, if/when CSV is updated support creating Java Beans, value trimming
would be much more appropriate there, as it would be on a per-column basis.
Let's keep the initial parsing simple.
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-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236687#comment-13236687 ] Sebb commented on CSV-70: - Another tricky aspect of the lexer is that currently it does a recursive call for handling comments. Could this lead to stack overflow if a file contained lots of comments in sequence? It would be better to eliminate the recursive call. Improve readability of CSVLexer --- Key: CSV-70 URL: https://issues.apache.org/jira/browse/CSV-70 Project: Commons CSV Issue Type: Improvement Components: Parser Affects Versions: 1.0 Reporter: Benedikt Ritter Fix For: 1.0 There are several things that can be improved in the token lexer (this has also been discussed on ML, see http://markmail.org/thread/c6x5ji4v44nx5k4h): * Remove Token input parameter in nextToken() * Add convenience methods isDelimiter(c) and isEncapsulator(c) * Remove current caracter input parameter from methods * If possible: replace while(true) loops -- 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-78) Use Character instead of char for char fields except delimiter
[ https://issues.apache.org/jira/browse/CSV-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236732#comment-13236732 ] Sebb commented on CSV-78: - Two alternatives: 1) provide methods to disable the setting, e.g. withNoEscape(), withNoEncapsulator(), withNoCommentStart() 2) provide enable disable methods, e.g. setUseEscape(boolean). In both cases it would be useful to use separate fields to store the enabled/disabled setting. This would allow the tricky DISABLED char to be dropped. Use Character instead of char for char fields except delimiter -- Key: CSV-78 URL: https://issues.apache.org/jira/browse/CSV-78 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Apart from the delimiter - which must be specified (obviously) - the other char fields are optional. At present it's not possible to create a new format from an existing format and remove (say) the encapsulation character. If the parameters were changed to Character instead of char, then it would be possible to pass null. -- 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-78) Use Character instead of char for char fields except delimiter
[ https://issues.apache.org/jira/browse/CSV-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236783#comment-13236783 ] Sebb commented on CSV-78: - Also, it would speed up the isEscaping() etc methods; the Lexer would not then need to cache the values. Use Character instead of char for char fields except delimiter -- Key: CSV-78 URL: https://issues.apache.org/jira/browse/CSV-78 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Apart from the delimiter - which must be specified (obviously) - the other char fields are optional. At present it's not possible to create a new format from an existing format and remove (say) the encapsulation character. If the parameters were changed to Character instead of char, then it would be possible to pass null. -- 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] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
[
https://issues.apache.org/jira/browse/NET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13236849#comment-13236849
]
Sebb commented on NET-455:
--
Does seem rather odd, because the listFiles() method actually filters the files
using FTPFileFilters.NON_NULL.
The second method should be slightly slower.
One possibility is that the FTP server (or its OS) does some caching of the
file directory listing, so that fetching the second listing is much faster than
the first.
Try repeating the test the other way around, or just repeating both methods A
B - e.g. ABAB - in a single test.
If the behaviour really is repeatable, can you provide a simple (complete) test
case that shows the behaviour?
FTPClient listFiles(FTPFileFilter) can be faster...
---
Key: NET-455
URL: https://issues.apache.org/jira/browse/NET-455
Project: Commons Net
Issue Type: Improvement
Components: FTP
Affects Versions: 3.0.1
Environment: all
Reporter: Nicolas
Priority: Minor
Labels: ftpclient, listFiles
Original Estimate: 1h
Remaining Estimate: 1h
I tested two ways of sorting files on a remote FTP server with many files (
110 000). Both of these use the FtpFileFilter class (with a test on the
extension filename... very simple).
The first one is the conventionnal =
{code}
files = ftpClient.listFiles(./, ftpFileFilter);
{code}
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
{code}
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
{code}
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
{code}
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
{code}
The second method is EIGHT times faster than the first one ... and I don't
really understand why...
--
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-72) CSVFormat.DEFAULT should be renamed as RFC4180
[ https://issues.apache.org/jira/browse/CSV-72?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234253#comment-13234253 ] Sebb commented on CSV-72: - I would expect DEFAULT to be an instance of CSVFormat with the default values for all fields, i.e. null or false etc, suitable for further customisation using the fluent interface. Besides, why should the default format be RFC 4180, rather than EXCEL? CSVFormat.DEFAULT should be renamed as RFC4180 -- Key: CSV-72 URL: https://issues.apache.org/jira/browse/CSV-72 Project: Commons CSV Issue Type: Bug Reporter: Sebb Priority: Minor CSVFormat.DEFAULT should be renamed as RFC4180. It's confusing to use the name DEFAULT. -- 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-71) Add convenience Methods to CSVLexer
[
https://issues.apache.org/jira/browse/CSV-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234856#comment-13234856
]
Sebb commented on CSV-71:
-
Just tried on my system, and I see similar performance both with and without
the patch.
Likewise if the patch is extended to check whether the character is enabled or
not, and using class fields, for example:
private boolean isEscape(int c) {
return escaping c == escape;
}
Add convenience Methods to CSVLexer
---
Key: CSV-71
URL: https://issues.apache.org/jira/browse/CSV-71
Project: Commons CSV
Issue Type: Sub-task
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Fix For: 1.0
Attachments: CSV-71.patch, Emmanuels_Performance_Test.patch
Add {{isDelimiter(c)}} and {{isEncapsulator(c)}} to CSVLexer
--
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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13233362#comment-13233362
]
Sebb commented on CODEC-96:
---
I think it might be possible to move the mutable fields out of the lower level
classes and back into the streaming classes which are the ones that actually
need them.
Whether it is possible to do this in a compatible way, I don't yet know, but
I'd like to give it a try over then next week or so.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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-96) Base64 encode() method is no longer thread-safe, breaking clients using it as a shared BinaryEncoder
[
https://issues.apache.org/jira/browse/CODEC-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13234003#comment-13234003
]
Sebb commented on CODEC-96:
---
I've got a prototype which passes all the tests.
Basically I put all the mutable fields in a Context class which is created by
the appropriate stream classes and public methods. This allows the BaseN
classes to be immutable i.e. threadsafe.
Clirr reports several incompatibilities because I moved all the protected
mutable fields into the context.
However, these are protected fields, and are not really intended for use by
external code, so it's very unlikely to cause problems. I did not need to
change the test code (except where it was overriding or testing
package-protected methods), which is a good sign.
See attachment to follow.
Base64 encode() method is no longer thread-safe, breaking clients using it as
a shared BinaryEncoder
Key: CODEC-96
URL: https://issues.apache.org/jira/browse/CODEC-96
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.4
Reporter: Matt Ryall
Assignee: Julius Davies
Fix For: 1.x
Attachments: codec-96-3rd-attempt.patch
Streaming support was added to Base64 in commons-codec 1.4 with CODEC-69.
This introduced instance variables to Base64 which means the class can no
longer be used as a shared BinaryEncoder instance.
For example, BinaryEncoder has an interface which could be (and was) used
like this with Base64:
{code:java}
class Example {
private BinaryEncoder encoder = new Base64();
byte[] someMethod(byte[] data) {
try {
return encoder.encode(data);
}
catch (EncoderException e) {
throw new RuntimeException(e);
}
}
}
{code}
Base64 is no longer thread-safe in commons-codec 1.4, so code like the above
which is accessed by multiple threads can throw NullPointerException:
{noformat}
java.lang.NullPointerException
at org.apache.commons.codec.binary.Base64.encode(Base64.java:469)
at org.apache.commons.codec.binary.Base64.encode(Base64.java:937)
at ... (application code)
{noformat}
Looking at the implementation of Base64, I think making it thread-safe for
this kind of usage would be quite tricky. I haven't attempted to prepare a
patch.
I would be happy if it was indicated in the Javadoc that Base64 is not
thread-safe and should not be shared. However, some other users of
commons-codec might be more worried about this regression.
--
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] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232280#comment-13232280 ] Sebb commented on IO-295: - It's far from ideal using a command shell for this, but if it is the only way it might be worth it. The class FileSystemUtils currently uses the same approach for getting the system free space, so if it is necessary to use a shell, we can re-use the process code from that class. FileUtils.isSymlinks misses symlink folders --- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross Attachments: IO-295.patch I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- 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-58) Unicode escapes are lost if escape character is backslash
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231924#comment-13231924 ] Sebb commented on CSV-58: - I think the default should be to retain the original source characters if the escape sequence is not recognised. This will allow the application to take further action if necessary. Failing that, throw an exception. Silently dropping the escape character seems the worst choice as the default. There's also the issue of what meta-characters should be de-escaped. It seems reasonable to include the encapsulator and CR, LF, possibly also the delimiter. But should any escapes - apart from the encapsulator itself - be processed in an encapsulated token? There's no need to do so. Maybe escape handling should be overrideable by the user. Unicode escapes are lost if escape character is backslash - Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Components: Parser Reporter: Sebb Fix For: 1.0 The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- 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] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231927#comment-13231927 ] Sebb commented on IO-305: - The default buffer size of 4096 was chosen because it gives good performance. Have you any performance tests that show otherwise? If so, we can consider implementing this for all the copyLarge methods, see: IO-308 bq. Is the check for len == -1 really a performance issue Code no longer checks the length twice; I reimplemented the loop in order to support returning the copied length. New copy() method in IOUtils that takes additional offset, length and buffersize arguments -- Key: IO-305 URL: https://issues.apache.org/jira/browse/IO-305 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Manoj Mokashi Priority: Minor Fix For: 2.2 Attachments: IOUtils.java, IOUtilsTest.java /** * Copy from input to output stream * @param is : input stream * @param os : output stream * @param offset : number of bytes to skip from input before copying * -ve values are ignored * @param len : number of bytes to copy. -1 means all * @param bufferSize : buffer size to use for copying * @throws IOException */ public static void copy( InputStream is, OutputStream os, int offset, int len, int bufferSize) throws IOException -- 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-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231930#comment-13231930
]
Sebb commented on CSV-68:
-
I've just discovered another disadvantage of the current code.
Removal of unicode escaping required changes to every single constructor call
in CSVFormat, of which there are a lot.
It was also necessary to be very careful to remove the correct parameter in the
predefined formats and test cases.
Similarly when adding a new parameter, a lot of code has to be changed.
With the proposed builder pattern, the changes are much simpler, because there
is only one constructor call to change (and its parameters are named, so it's
obvious where it should be put).
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch, CSVFormat2.java, CVSFormat2Main.java
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
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] (NET-454) paths with spaces result in inaccurate file information
[
https://issues.apache.org/jira/browse/NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232018#comment-13232018
]
Sebb commented on NET-454:
--
bq. ftp ls 78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #1054.pdf
bq. usage: ls [remote-path [local-file]]
That's a feature of the command-line client; it's expecting an optional second
parameter.
You need to quote the remote-path, for example:
{code}
ls 78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #1054.pdf
{code}
Works for me with Apache FTP server.
Try it with Pure-FTPd.
I think this is a bug in Pure-FTPd.
As far as I am aware, the LIST command only supports a single parameter which
is the path.
Try enclosing the path in double-quotes in your test case.
paths with spaces result in inaccurate file information
---
Key: NET-454
URL: https://issues.apache.org/jira/browse/NET-454
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: Mac OS X 10.7.3, FTP server is Pure-FTPd on Linux CentOS
5
Reporter: Shane Witbeck
Labels: ftp, path
Attachments: FTPClientTest.java
Calling FTPClient.listFiles(String pathname) results in an inaccurate file
list being returned. The following test illustrates the issue:
{code:java}
@Test
public void remoteListFilesFailure() throws Exception {
FTPClient client = new FTPClient();
client.connect(REMOTE_SERVER);
client.enterLocalPassiveMode();
client.login(REMOTE_USERNAME, REMOTE_PASSWORD);
client.setFileType(FTP.BINARY_FILE_TYPE);
int reply = client.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
client.disconnect();
log.error(FTP server refused connection. reply= + reply);
}
FTPFile[] rootFiles =
client.listFiles(78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #
1054.pdf);
Assert.assertEquals(1, rootFiles.length); // -- fails with
rootFiles.length = 0
}
{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] (CONFIGURATION-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232022#comment-13232022 ] Sebb commented on CONFIGURATION-486: Fixing the thread-safety issue is trivial. However, the class will still be potentially thread-hostile, depending on when the setter and getter are used. Fixing that might require a redesign of the code. BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- 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-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232043#comment-13232043 ] Sebb commented on CONFIGURATION-486: Same problem with AbstractConfiguration.defaultListDelimiter BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- 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-490) DefaultConfigurationKey.setExpressionEngine - non-final method called by constructor
[ https://issues.apache.org/jira/browse/CONFIGURATION-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232045#comment-13232045 ] Sebb commented on CONFIGURATION-490: ConfigurationFactory as well DefaultConfigurationKey.setExpressionEngine - non-final method called by constructor Key: CONFIGURATION-490 URL: https://issues.apache.org/jira/browse/CONFIGURATION-490 Project: Commons Configuration Issue Type: Bug Reporter: Sebb If a constructor calls an overrideable method, sub-classes that override the method can cause failures -- 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-490) DefaultConfigurationKey.setExpressionEngine - non-final method called by constructor
[ https://issues.apache.org/jira/browse/CONFIGURATION-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232047#comment-13232047 ] Sebb commented on CONFIGURATION-490: Also: ConfigurationXMLReader() DefaultConfigurationBuilder There are probably lots more DefaultConfigurationKey.setExpressionEngine - non-final method called by constructor Key: CONFIGURATION-490 URL: https://issues.apache.org/jira/browse/CONFIGURATION-490 Project: Commons Configuration Issue Type: Bug Reporter: Sebb If a constructor calls an overrideable method, sub-classes that override the method can cause failures -- 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-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232048#comment-13232048 ] Sebb commented on CONFIGURATION-486: ALso FileSystem.fileSystem BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- 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-486) BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe
[ https://issues.apache.org/jira/browse/CONFIGURATION-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232049#comment-13232049 ] Sebb commented on CONFIGURATION-486: HierarchicalConfiguration.defaultExpressionEngine BeanHelper.setDefaultBeanFactory() is thread-hostile and not thread-safe Key: CONFIGURATION-486 URL: https://issues.apache.org/jira/browse/CONFIGURATION-486 Project: Commons Configuration Issue Type: Bug Reporter: Sebb BeanHelper.setDefaultBeanFactory() sets a private static field. This is thread-hostile, because different threads cannot safely use different factories. It's also not thread-safe, as the variable is not guaranteed to be published safely. Should either make the variable volatile, or synchronize both getter and setter. -- 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] (IO-269) Tailer locks file from deletion/rename on Windows
[ https://issues.apache.org/jira/browse/IO-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13232137#comment-13232137 ] Sebb commented on IO-269: - Thanks for the patch. In the benchmark, how big was the file that you were tailing? Tailer locks file from deletion/rename on Windows - Key: IO-269 URL: https://issues.apache.org/jira/browse/IO-269 Project: Commons IO Issue Type: Bug Reporter: Sebb Attachments: IO-269.patch The Tailer code works on Windows, except that it locks the file against deletion or rename. The test code fails to detect this, because it fails to check if the file deletion succeeds. This seems to be a Windows OS issue. A possible solution might be to keep closing and re-opening the file. -- 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] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231047#comment-13231047 ] Sebb commented on IO-305: - The code would probably be simplified by using copyLarge for the case where len == -1 (otherwise it has to keep checking for this). Also, unless the copyLarge methods are enhanced to allow the buffer or its size to be specified, it would be more consistent to use the same buffer size as the copyLarge methods, and omit the size parameter. New copy() method in IOUtils that takes additional offset, length and buffersize arguments -- Key: IO-305 URL: https://issues.apache.org/jira/browse/IO-305 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Manoj Mokashi Priority: Minor Attachments: IOUtils.java, IOUtilsTest.java /** * Copy from input to output stream * @param is : input stream * @param os : output stream * @param offset : number of bytes to skip from input before copying * -ve values are ignored * @param len : number of bytes to copy. -1 means all * @param bufferSize : buffer size to use for copying * @throws IOException */ public static void copy( InputStream is, OutputStream os, int offset, int len, int bufferSize) throws IOException -- 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-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231073#comment-13231073
]
Sebb commented on CSV-68:
-
The extra verbosity is .init(',') and .build()
Not a lot.
The gains are:
- much clearer setup of built-in formats
- guaranteed validation
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
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-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231369#comment-13231369
]
Sebb commented on CSV-68:
-
bq. how about renaming init(char) to withDelimiter(char)
The delimiter is different, in that it is the only parameter that must be
specified.
But one could still potentially have a withDelimiter() method that could be
applied to an existing Builder chain, e.g. to modify an existing format. [The
builder delim field is final. I might well change that and add the method.]
Note that the first and last methods in the chain have different input/output
classes, so should use a different naming convention.
CSVFormat.init() could be replaced by new CSVFormat.Builder() but I thought
it was slightly neater to have a static newInstance() method, and given that
the delimiter needs to be defined, I thought it might as well be a parameter to
the init() method.
The init() method can of course be renamed.
It cannot be renamed to withDelimiter() unless the existing method of the same
name is dropped; but even without the name clash I think it would be a mistake
to use a name prefixed with as the newInstance method as users would expect
to be able to provide the parameters in any order.
Just realised that this would also be possible if each withMethod were defined
as a static method in CSVFormat as well as a class method in the Builder. [Only
the build() method would be unique to the Builder.]
The only extra method call required would then be the build() method.
So the syntax would be
{code}
CSVFormat.withDelimiter(',').withEncapsulator('')...build();
CSVFormat.excel().withDelimiter(';').build();
{code}
Maybe that would satisfy everyone?
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
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-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231440#comment-13231440
]
Sebb commented on CSV-68:
-
How about:
{code}
CSVFormat.withDelimiter(';').withEncapsulator('').go();
{code}
It's one character shorter than your example.
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
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-71) Add convenience Methods to CSVLexer
[
https://issues.apache.org/jira/browse/CSV-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231452#comment-13231452
]
Sebb commented on CSV-71:
-
What performance test is that? On my system the tests take about 3 times as
long!
But that is using Java 1.6 on an old XP laptop.
Can you attach the code; it would help to ensure we use the same tests.
Add convenience Methods to CSVLexer
---
Key: CSV-71
URL: https://issues.apache.org/jira/browse/CSV-71
Project: Commons CSV
Issue Type: Sub-task
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Fix For: 1.0
Attachments: CSV-71.patch
Add {{isDelimiter(c)}} and {{isEncapsulator(c)}} to CSVLexer
--
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-67) UnicodeUnescapeReader should not be applied before parsing
[ https://issues.apache.org/jira/browse/CSV-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231472#comment-13231472 ] Sebb commented on CSV-67: - OK, I'm working on removing it and moving the reader class to IO for a future release. UnicodeUnescapeReader should not be applied before parsing -- Key: CSV-67 URL: https://issues.apache.org/jira/browse/CSV-67 Project: Commons CSV Issue Type: Bug Reporter: Sebb The UnicodeEscapeReader is currently applied before the input file is parsed. This means that unicode escapes are treated differently from other escapes. For example, the sequence escrescn is not treated as a new-line for the purpose of recognising the end of a record, yet \o000D\u000A is converted to CRLF and would terminate the record (unless embedded in a quoted string). The unicode escape processing (if selected) should occur as part of the parsing, just as for ordinary escape processing. The class can be made public so the user can wrap the input if required; this preserves the existing functionality should it be required, so there is no need to introduce another setting. -- 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-71) Add convenience Methods to CSVLexer
[
https://issues.apache.org/jira/browse/CSV-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231474#comment-13231474
]
Sebb commented on CSV-71:
-
I meant that *all* the tests take about 3 times longer (including the current
code).
I've not tried the patch yet so I don't know if it is faster or slower or about
the same on my system.
Add convenience Methods to CSVLexer
---
Key: CSV-71
URL: https://issues.apache.org/jira/browse/CSV-71
Project: Commons CSV
Issue Type: Sub-task
Components: Parser
Affects Versions: 1.0
Reporter: Benedikt Ritter
Fix For: 1.0
Attachments: CSV-71.patch, Emmanuels_Performance_Test.patch
Add {{isDelimiter(c)}} and {{isEncapsulator(c)}} to CSVLexer
--
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-68) Use Builder pattern for CSVFormat
[
https://issues.apache.org/jira/browse/CSV-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231794#comment-13231794
]
Sebb commented on CSV-68:
-
OK, let's use build, which is only two characters longer. Is it really that
important to save 2 characters?
==
The current validate method cannot be called in the CSVFormat ctor, because the
fluent chain may create an invalid instance part way through.
Therefore the format method has to be called outside the class; it's very easy
for the call to be omitted when the code is later maintained.
It's not just so that the validate can be invoked earlier; it's to guarantee
that an invalid format cannot be created.
Use Builder pattern for CSVFormat
-
Key: CSV-68
URL: https://issues.apache.org/jira/browse/CSV-68
Project: Commons CSV
Issue Type: Improvement
Reporter: Sebb
Attachments: CSV-68.patch, CSVFormat2.java, CVSFormat2Main.java
Using a builder pattern to create CSVFormat instances would allow the
settings to be validated at creation time and would eliminate the need to
keep creating new CSVFormat instances whilst still allowing the class to be
immutable.
A possible API is as follows:
{code}
CSVFormat DEFAULT = CSVFormat.init(',') // delimiter is required
.withEncapsulator('')
.withLeadingSpacesIgnored(true)
.withTrailingSpacesIgnored(true)
.withEmptyLinesIgnored(true)
.withLineSeparator(\r\n) // optional, as it would be the default
.build();
CSVFormat format = CSVFormat.init(CSVFormat.DEFAULT) // alternatively start
with pre-defined format
.withSurroundingSpacesIgnored(false)
.build();
{code}
Compare this with the current syntax:
{code}
// internal syntax; not easy to determine what all the parameters do
CSVFormat DEFAULT1 = new CSVFormat(',', '', DISABLED, DISABLED, true, true,
false, true, CRLF);
// external syntax
CSVFormat format = CSVFormat.DEFAULT.withSurroundingSpacesIgnored(false);
{code}
As a proof of concept I've written skeleton code which compiles (but needs
completing).
--
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] (NET-454) paths with spaces result in inaccurate file information
[
https://issues.apache.org/jira/browse/NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231798#comment-13231798
]
Sebb commented on NET-454:
--
What are the file names on the server?
paths with spaces result in inaccurate file information
---
Key: NET-454
URL: https://issues.apache.org/jira/browse/NET-454
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: Mac OS X 10.7.3, FTP server is Pure-FTPd on Linux CentOS
5
Reporter: Shane Witbeck
Labels: ftp, path
Calling FTPClient.listFiles(String pathname) results in an inaccurate file
list being returned. The following test illustrates the issue:
{code:java}
@Test
public void remoteListFilesFailure() throws Exception {
FTPClient client = new FTPClient();
client.connect(REMOTE_SERVER);
client.enterLocalPassiveMode();
client.login(REMOTE_USERNAME, REMOTE_PASSWORD);
client.setFileType(FTP.BINARY_FILE_TYPE);
int reply = client.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
client.disconnect();
log.error(FTP server refused connection. reply= + reply);
}
FTPFile[] rootFiles =
client.listFiles(78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #
1054.pdf);
Assert.assertEquals(1, rootFiles.length); // -- fails with
rootFiles.length = 0
}
{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] (NET-454) paths with spaces result in inaccurate file information
[
https://issues.apache.org/jira/browse/NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231801#comment-13231801
]
Sebb commented on NET-454:
--
Also, can you perform the listing using command-line FTP ?
paths with spaces result in inaccurate file information
---
Key: NET-454
URL: https://issues.apache.org/jira/browse/NET-454
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: Mac OS X 10.7.3, FTP server is Pure-FTPd on Linux CentOS
5
Reporter: Shane Witbeck
Labels: ftp, path
Calling FTPClient.listFiles(String pathname) results in an inaccurate file
list being returned. The following test illustrates the issue:
{code:java}
@Test
public void remoteListFilesFailure() throws Exception {
FTPClient client = new FTPClient();
client.connect(REMOTE_SERVER);
client.enterLocalPassiveMode();
client.login(REMOTE_USERNAME, REMOTE_PASSWORD);
client.setFileType(FTP.BINARY_FILE_TYPE);
int reply = client.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
client.disconnect();
log.error(FTP server refused connection. reply= + reply);
}
FTPFile[] rootFiles =
client.listFiles(78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #
1054.pdf);
Assert.assertEquals(1, rootFiles.length); // -- fails with
rootFiles.length = 0
}
{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] (NET-454) paths with spaces result in inaccurate file information
[
https://issues.apache.org/jira/browse/NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13231820#comment-13231820
]
Sebb commented on NET-454:
--
What happens if you try:
{code}
client.listFiles(78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/);
{code}
I tried setting up an identical test, and everything works OK for me:
{code}
set classpath=commons-net-examples-3.1.jar;commons-net-3.1.jar
java examples/ftp/FTPClientExample -l host user password
78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO # 1054.pdf
...
215 UNIX Type: Apache FtpServer
Remote system is UNIX Type: Apache FtpServer
PASV
227 Entering Passive Mode (127,0,0,1,18,81)
LIST 78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO # 1054.pdf
150 File status okay; about to open data connection.
226 Closing data connection.
-rw--- 1 user group0 Mar 17 02:47 ModComp PO # 1054.pdf
-rw---1 groupuser0 2012-03-17 02:47:00 GMT ModComp PO
# 1054.pdf
NOOP
200 Command NOOP okay.
QUIT
221 Goodbye.
{code}
paths with spaces result in inaccurate file information
---
Key: NET-454
URL: https://issues.apache.org/jira/browse/NET-454
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.0.1, 3.1
Environment: Mac OS X 10.7.3, FTP server is Pure-FTPd on Linux CentOS
5
Reporter: Shane Witbeck
Labels: ftp, path
Calling FTPClient.listFiles(String pathname) results in an inaccurate file
list being returned. The following test illustrates the issue:
{code:java}
@Test
public void remoteListFilesFailure() throws Exception {
FTPClient client = new FTPClient();
client.connect(REMOTE_SERVER);
client.enterLocalPassiveMode();
client.login(REMOTE_USERNAME, REMOTE_PASSWORD);
client.setFileType(FTP.BINARY_FILE_TYPE);
int reply = client.getReplyCode();
if (!FTPReply.isPositiveCompletion(reply)) {
client.disconnect();
log.error(FTP server refused connection. reply= + reply);
}
FTPFile[] rootFiles =
client.listFiles(78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #
1054.pdf);
Assert.assertEquals(1, rootFiles.length); // -- fails with
rootFiles.length = 0
}
{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-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230085#comment-13230085
]
Sebb commented on CSV-65:
-
It should still be possible to read a CSV file without a header and without
providing one.
Header support
--
Key: CSV-65
URL: https://issues.apache.org/jira/browse/CSV-65
Project: Commons CSV
Issue Type: New Feature
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
Commons CSV is missing some elements to help dealing with CSV file headers.
With the current API one has to write the following code to read the fields
by name:
{code:java}
CSVParser parser = new CSVParser(in);
IteratorString[] it = parser.iterator();
// read the header
String[] header = it.next();
// build a name to index mapping
MapString, Integer mapping = new HashMap();
for (int i = 0; i header.length; i++) {
mapping.put(header[i], i);
}
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[mapping.get(name)]);
person.setEmail(record[mapping.get(email)]);
person.setPhone(record[mapping.get(phone)]);
persons.add(person);
}
{code}
The header should be defined in the format with something like this:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
{code}
Then either the parser provides the column name to index mapping
automatically:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
CSVParser parser = new CSVParser(in, format);
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[parser.indexOf(name)]);
person.setEmail(record[parser.indexOf(email)]);
person.setPhone(record[parser.indexOf(phone)]);
persons.add(person);
}
{code}
or the parser returns a Map like structure similar to a JDBC ResultSet
(replacing String[]):
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
for (CSVRecord record : format.parse(in)) {
Person person = new Person();
person.setName(record.get(name));
person.setEmail(record.get(email));
person.setPhone(record.get(phone));
persons.add(person);
}
{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-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230103#comment-13230103
]
Sebb commented on CSV-65:
-
I think the header should be initialised in the CSVParser ctor (failing that,
could perhaps use an IODH idiom).
As it stands, getRecord() calls format.getHeader() every time if that returns
null.
Also, I'm not sure why CSVRecord should ever have a null values array - surely
a zero-length array would be easier to use?
Also, the mapping applies to all records, so I don't think it belongs in the
record.
Header support
--
Key: CSV-65
URL: https://issues.apache.org/jira/browse/CSV-65
Project: Commons CSV
Issue Type: New Feature
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
Attachments: CSVFormat.java, CSVParser.java, CSVRecord.java
Commons CSV is missing some elements to help dealing with CSV file headers.
With the current API one has to write the following code to read the fields
by name:
{code:java}
CSVParser parser = new CSVParser(in);
IteratorString[] it = parser.iterator();
// read the header
String[] header = it.next();
// build a name to index mapping
MapString, Integer mapping = new HashMap();
for (int i = 0; i header.length; i++) {
mapping.put(header[i], i);
}
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[mapping.get(name)]);
person.setEmail(record[mapping.get(email)]);
person.setPhone(record[mapping.get(phone)]);
persons.add(person);
}
{code}
The header should be defined in the format with something like this:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
{code}
Then either the parser provides the column name to index mapping
automatically:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
CSVParser parser = new CSVParser(in, format);
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[parser.indexOf(name)]);
person.setEmail(record[parser.indexOf(email)]);
person.setPhone(record[parser.indexOf(phone)]);
persons.add(person);
}
{code}
or the parser returns a Map like structure similar to a JDBC ResultSet
(replacing String[]):
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
for (CSVRecord record : format.parse(in)) {
Person person = new Person();
person.setName(record.get(name));
person.setEmail(record.get(email));
person.setPhone(record.get(phone));
persons.add(person);
}
{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-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13230147#comment-13230147
]
Sebb commented on CSV-65:
-
bq. I preferred a null array to save some memory.
The empty string array is immutable and can be safely shared.
Using null increases the code because have to check for null.
Header support
--
Key: CSV-65
URL: https://issues.apache.org/jira/browse/CSV-65
Project: Commons CSV
Issue Type: New Feature
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
Attachments: CSVFormat.java, CSVParser.java, CSVRecord.java
Commons CSV is missing some elements to help dealing with CSV file headers.
With the current API one has to write the following code to read the fields
by name:
{code:java}
CSVParser parser = new CSVParser(in);
IteratorString[] it = parser.iterator();
// read the header
String[] header = it.next();
// build a name to index mapping
MapString, Integer mapping = new HashMap();
for (int i = 0; i header.length; i++) {
mapping.put(header[i], i);
}
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[mapping.get(name)]);
person.setEmail(record[mapping.get(email)]);
person.setPhone(record[mapping.get(phone)]);
persons.add(person);
}
{code}
The header should be defined in the format with something like this:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
{code}
Then either the parser provides the column name to index mapping
automatically:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
CSVParser parser = new CSVParser(in, format);
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[parser.indexOf(name)]);
person.setEmail(record[parser.indexOf(email)]);
person.setPhone(record[parser.indexOf(phone)]);
persons.add(person);
}
{code}
or the parser returns a Map like structure similar to a JDBC ResultSet
(replacing String[]):
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
for (CSVRecord record : format.parse(in)) {
Person person = new Person();
person.setName(record.get(name));
person.setEmail(record.get(email));
person.setPhone(record.get(phone));
persons.add(person);
}
{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-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229206#comment-13229206
]
Sebb commented on CSV-57:
-
Patch dated 13/Mar/12 19:39 looks good to me.
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
Attachments: CSV-57.txt
{{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-58) Unicode escapes are lost if escape character is backslash
[ https://issues.apache.org/jira/browse/CSV-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229415#comment-13229415 ] Sebb commented on CSV-58: - If unicode parsing is not selected, the unicode sequences lose their escape character so cannot then be parsed later. This is really about more than just unicode escape sequences, though that is what alerted me to the issue. The whole business of escape handling needs to be very carefully documented (and tested!) to ensure predictable behaviour. Unicode escapes are lost if escape character is backslash - Key: CSV-58 URL: https://issues.apache.org/jira/browse/CSV-58 Project: Commons CSV Issue Type: Bug Reporter: Sebb The current escape parsing converts escchar to plain char if the char is not one of the special characters to be escaped. This can affect unicode escapes if the esc character is backslash. One way round this is to specifically check for char == 'u', but it seems wrong to only do this for 'u'. Another solution would be to leave escchar as is unless the char is one of the special characters. There are several possible ways to treat unrecognised escapes: - treat it as if the escape char had not been present (current behaviour) - leave the escape char as is - throw an exception -- 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-61) CSVFormat combines input and output settings in a single class; might be clearer as separate classes
[ https://issues.apache.org/jira/browse/CSV-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229522#comment-13229522 ] Sebb commented on CSV-61: - Applications that read CSV files don't necessarily want to write them and vice-versa. Separating the configurations would allow them to be used independently. It might be a bit different if the same format definitions were used for input and output (as for DateFormat), but they are not, and I suspect that would not be possible. CSVFormat combines input and output settings in a single class; might be clearer as separate classes Key: CSV-61 URL: https://issues.apache.org/jira/browse/CSV-61 Project: Commons CSV Issue Type: Improvement Reporter: Sebb CSVFormat currently includes both input (parsing) and output (formatting) settings in a single class. This is a bit confusing; for example lineSeparator could be either. (The Javadoc has now been corrected) It might be clearer to have separate classes for input and output. This would also reduce the number of parameters in each ctor. -- 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-63) CSVPrinter always quotes empty string if it is the first on a line
[ https://issues.apache.org/jira/browse/CSV-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229532#comment-13229532 ] Sebb commented on CSV-63: - Yes, I saw that, but it does not apply to records with multiple values. Also, I just tried creating a one-column spreadsheet in OpenOffice Calc - it saves an empty row as an empty line. It reads the file back successfully, recreating the empty row. CSVPrinter always quotes empty string if it is the first on a line -- Key: CSV-63 URL: https://issues.apache.org/jira/browse/CSV-63 Project: Commons CSV Issue Type: Bug Reporter: Sebb CSVPrinter always quotes the empty string if it is the first on a line. This is inconsistent. -- 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=13229562#comment-13229562
]
Sebb commented on CSV-57:
-
I use displayed tab width 4, use spaces for tabs.
I've not found out how to stop Eclipse adding leading spaces to blank lines, so
I tend to delete those as I go along.
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
Attachments: CSV-57.txt
{{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-63) CSVPrinter always quotes empty string if it is the first on a line
[ https://issues.apache.org/jira/browse/CSV-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229567#comment-13229567 ] Sebb commented on CSV-63: - I don't think we should take account of the number of fields, because again that is inconsistent. A field should be encapsulated (quoted) if either the format always encapsulates or the value requires encapsulation. CSVPrinter always quotes empty string if it is the first on a line -- Key: CSV-63 URL: https://issues.apache.org/jira/browse/CSV-63 Project: Commons CSV Issue Type: Bug Reporter: Sebb CSVPrinter always quotes the empty string if it is the first on a line. This is inconsistent. -- 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-64) CSVPrinter does not distinguish null and the empty string
[ https://issues.apache.org/jira/browse/CSV-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229764#comment-13229764 ] Sebb commented on CSV-64: - Other databases may use explicit text strings for null. I used to work on Ingres, and IIRC that used something like ]NULL[ by default. It may be OK to treat null as the empty string by default, but it should be possible to distinguish them when necessary. This will become vital if/when CSV is enhanced to create beans. CSVPrinter does not distinguish null and the empty string - Key: CSV-64 URL: https://issues.apache.org/jira/browse/CSV-64 Project: Commons CSV Issue Type: Bug Components: Printer Reporter: Sebb CSVPrinter does not distinguish null and the empty string. There should be a way to denote that a string is null rather than empty. -- 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-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13229825#comment-13229825
]
Sebb commented on CSV-65:
-
If the file does not provide a header record, it should be possible for the
user to provide one.
Header support
--
Key: CSV-65
URL: https://issues.apache.org/jira/browse/CSV-65
Project: Commons CSV
Issue Type: New Feature
Components: Parser
Reporter: Emmanuel Bourg
Fix For: 1.0
Commons CSV is missing some elements to help dealing with CSV file headers.
With the current API one has to write the following code to read the fields
by name:
{code:java}
CSVParser parser = new CSVParser(in);
IteratorString[] it = parser.iterator();
// read the header
String[] header = it.next();
// build a name to index mapping
MapString, Integer mapping = new HashMap();
for (int i = 0; i header.length; i++) {
mapping.put(header[i], i);
}
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[mapping.get(name)]);
person.setEmail(record[mapping.get(email)]);
person.setPhone(record[mapping.get(phone)]);
persons.add(person);
}
{code}
The header should be defined in the format with something like this:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
{code}
Then either the parser provides the column name to index mapping
automatically:
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
CSVParser parser = new CSVParser(in, format);
// parse the records
for (String[] record : parser) {
Person person = new Person();
person.setName(record[parser.indexOf(name)]);
person.setEmail(record[parser.indexOf(email)]);
person.setPhone(record[parser.indexOf(phone)]);
persons.add(person);
}
{code}
or the parser returns a Map like structure similar to a JDBC ResultSet
(replacing String[]):
{code:java}
CSVFormat format = CSVFormat.DEFAULT.withHeader();
for (CSVRecord record : format.parse(in)) {
Person person = new Person();
person.setName(record.get(name));
person.setEmail(record.get(email));
person.setPhone(record.get(phone));
persons.add(person);
}
{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] (IO-295) FileUtils.isSymlinks misses symlink folders
[ https://issues.apache.org/jira/browse/IO-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13228909#comment-13228909 ] Sebb commented on IO-295: - At present, the method always returns false for Windows systems. Not sure whether it's possible to detect symbolic links on Windows (except by using Java 7 of course). FileUtils.isSymlinks misses symlink folders --- Key: IO-295 URL: https://issues.apache.org/jira/browse/IO-295 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Environment: Windows 7 64 bit, Oracle Java 7 Reporter: Ron Gross I created a symlink folder via mklink. Then, while debugging, I noticed that FileUtils.isSymlink() returns false on this directory, while Java 7's Files.isSymbolicLink() returns true. -- 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-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-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-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=13227307#comment-13227307 ] Sebb commented on CSV-34: - That's quite surprising. Obviously volatile will have some overhead, but I'm surprised it is as much as that, but then there are quite a few variables to be checked. 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] [Commented] (COMMONSSITE-67) Add instructions for migrating Sandbox component to Proper
[ https://issues.apache.org/jira/browse/COMMONSSITE-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226847#comment-13226847 ] Sebb commented on COMMONSSITE-67: - More updates to POM: Change commons.jira.componentid - pid can be found using JIRA createIssue Change scm URLs Remove Sandbox from name if necessary Update Gump: URL: http://svn.apache.org/viewvc?rev=1299111view=rev Log: CSV moved to proper Modified: gump/metadata/project/commons-proper.xml gump/metadata/project/commons-sandbox.xml Update Continuum: - fix SVN URL Add instructions for migrating Sandbox component to Proper -- Key: COMMONSSITE-67 URL: https://issues.apache.org/jira/browse/COMMONSSITE-67 Project: Commons All Issue Type: Improvement Reporter: Sebb Need proper documentation on migrating a Sandbox component. Here's a summary of what I did for CSV recently. Remove external link from trunks-sandbox svn rename -mCSV = proper \ https://svn.apache.org/repos/asf/commons/sandbox/csv/trunk \ https://svn.apache.org/repos/asf/commons/proper/csv/trunk Add external link to trunks-proper Login to minotaur Rename the site directory /www/commons.apache.org/sandbox/csv = /www/commons.apache.org/csv Edit /www/commons.apache.org/sandbox/.htaccess to add redirect Create /www/commons.apache.org/csv/download_csv.cgi from an existing cgi file (copy rename) Update commons-site: - remove CSV entry from src/site/xdoc/sandbox/index.xml - add CSV entry to src/site/site.xml, src/site/xdoc/index.xml, src/site/xdoc/components.xml, src/site/xdoc/downloads/index.xml - regenerate and deploy Update CSV pom: Change parent to normal commons-parent -- 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-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226862#comment-13226862 ] Sebb commented on CSV-43: - Yes, every fluent method creates a new instance. That seems very wasteful. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- 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-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226888#comment-13226888 ] Sebb commented on CSV-43: - Yes, a builder would also work, and would allow the class to be truly immutable. However it would mean bigger changes to the API. A simpler fix would be to add a flag to reject further changes. Not immutable, but thread-safe since code uses volatile. Either fix would be fine by me. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- 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-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226591#comment-13226591 ] Sebb commented on CSV-43: - OK, but so long as the predefined formats are frozen, it would still be possible to code the fluent API more efficiently. The simplest way would be to add a flag that stops further updates. CSVFormat fluent API is rather inefficient -- Key: CSV-43 URL: https://issues.apache.org/jira/browse/CSV-43 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The implementation of the CSVFormat fluent API is rather inefficient, as each method invocation clones the original class instance. Now that the fields are volatile, it would be possible to do away with the clone() calls entirely. This would mean that the format could be updated later. If such usage is not desirable, then perhaps consider adding some kind of freeze method to prevent further changes. Or perhaps the parse() and format() methods could perform the freeze (e.g. set a flag to disable further updates). -- 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] (LANG-792) ToStringStyle registry may retain entries between invocations - is this a problem?
[ https://issues.apache.org/jira/browse/LANG-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225361#comment-13225361 ] Sebb commented on LANG-792: --- bq. If the registry was not a thread local, then all threads would share the registry That is only true if the ToStringStyle (TSS) instance is shared between threads. I had assumed that each ToStringBuilder would use its own TSS instance, but that is not the case. Looking again at the code, I see that the ToStringStyle (TSS) classes seem to be intended to be used as singletons which are then shared between threads. That explains why the ThreadLocal is needed. Also, I now realise that the earlier problem with the test cases failing on Gump is that some of them created a builder but then failed to use the toString() method on it. That left entries in the registry, and caused the subsequent test to fail if it checked that the registry was empty. In normal use, the toString() method is required; the registry will then be cleaned up. The test cases need to do so too; I'll fix them up again. ToStringStyle registry may retain entries between invocations - is this a problem? -- Key: LANG-792 URL: https://issues.apache.org/jira/browse/LANG-792 Project: Commons Lang Issue Type: Bug Reporter: Sebb The class ToStringStyle maintains a registry in order to try to detect object cycles (introduced by LANG-69). Multiple instances in the same thread share the same registry (it's a ThreadLocal - not clear why). Entries can be left in the registry on return from calling various methods on the instance. Is this a bug? Can object cycles cause problems across method calls? If it is intended for the registered objects to remain across method calls, can objects from different instances interfere with each other? The registry uses a WeakHashMap, so the entries should not cause problems for garbage collection. One solution would be to use an instance field to hold the map instead of sharing them. Would that use more memory, or be otherwise less efficient? -- 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] (NET-451) FTPClient list and listName gives 500 error but when i use listFiles it is working fine
[ https://issues.apache.org/jira/browse/NET-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13225365#comment-13225365 ] Sebb commented on NET-451: -- You need to give a bit more information. What is the exact error message? What is the code you are using? What version of Net are you using? FTPClient list and listName gives 500 error but when i use listFiles it is working fine --- Key: NET-451 URL: https://issues.apache.org/jira/browse/NET-451 Project: Commons Net Issue Type: Bug Components: FTP Reporter: srinivasan Priority: Minor -- 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] (IO-305) New copy() method in IOUtils that takes additional offset, length and buffersize arguments
[ https://issues.apache.org/jira/browse/IO-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224225#comment-13224225 ] Sebb commented on IO-305: - Should use long for the offset and length. It would be useful to return the number of bytes actually copied, as per the copyLarge methods. New copy() method in IOUtils that takes additional offset, length and buffersize arguments -- Key: IO-305 URL: https://issues.apache.org/jira/browse/IO-305 Project: Commons IO Issue Type: New Feature Components: Utilities Reporter: Manoj Mokashi Priority: Minor Attachments: IOUtils.java, IOUtilsTest.java /** * Copy from input to output stream * @param is : input stream * @param os : output stream * @param offset : number of bytes to skip from input before copying * -ve values are ignored * @param len : number of bytes to copy. -1 means all * @param bufferSize : buffer size to use for copying * @throws IOException */ public static void copy( InputStream is, OutputStream os, int offset, int len, int bufferSize) throws IOException -- 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] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224859#comment-13224859 ] Sebb commented on SANDBOX-408: -- I thought you wanted to be able to pass CSVFormat objects between threads? As it stands, the implementation is not completely thread-safe. And the Javadoc comment is still misleading. CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe Key: SANDBOX-408 URL: https://issues.apache.org/jira/browse/SANDBOX-408 Project: Commons Sandbox Issue Type: Bug Components: CSV Reporter: Sebb 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] [Commented] (COLLECTIONS-397) BoundedFifoBuffer could allow null entries
[ https://issues.apache.org/jira/browse/COLLECTIONS-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224885#comment-13224885 ] Sebb commented on COLLECTIONS-397: -- If COLLECTIONS-398-2.patch is applied (see COLLECTIONS-398) then the underlying code will support nulls. The null check in add() would obviously have to be disabled to allow null entries. Two possible approaches: - remove the restriction that nulls are not allowed; this would be a change in behaviour so might not be acceptable - add new ctors with a boolean parameter to specify whether nulls are allowed. BoundedFifoBuffer could allow null entries -- Key: COLLECTIONS-397 URL: https://issues.apache.org/jira/browse/COLLECTIONS-397 Project: Commons Collections Issue Type: Improvement Reporter: Sebb BoundedFifoBuffer could easily allow null entries - it uses an array for storage. Is there any reason why nulls should not be (optionally) allowed? This would mean changing the remove() implementation. -- 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] (COLLECTIONS-285) TreeBidiMap should implement Serializable
[ https://issues.apache.org/jira/browse/COLLECTIONS-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224934#comment-13224934 ] Sebb commented on COLLECTIONS-285: -- This patch only adds transient markers to the main class fields. What about the nested classes? Some of those have fields - should they be serialised or not? TreeBidiMap should implement Serializable - Key: COLLECTIONS-285 URL: https://issues.apache.org/jira/browse/COLLECTIONS-285 Project: Commons Collections Issue Type: Improvement Components: BidiMap Affects Versions: 3.2 Reporter: Geert Pante Fix For: 4.0-beta-1 Attachments: COLLECTIONS-285.patch, COLLECTIONS_285.diff TreeBidiMap does not implement Serializable. DualTreeBidiMap does. It's just a matter of checking which fields should be transient and done. In fact, all Maps should be Serializable. -- 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
