[jira] [Resolved] (VFS-411) [SFTP] Update Jsch to version 0.1.47 from 0.1.46.
[ https://issues.apache.org/jira/browse/VFS-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-411. - Resolution: Fixed In SVN. [SFTP] Update Jsch to version 0.1.47 from 0.1.46. - Key: VFS-411 URL: https://issues.apache.org/jira/browse/VFS-411 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 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 Fix For: 2.1 [SFTP] Update Jsch to version 0.1.47 from 0.1.46. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-410) [SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
[
https://issues.apache.org/jira/browse/VFS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved VFS-410.
-
Resolution: Fixed
Martin,
Thank you for providing the patch.
It has been applied with only slight changes.
Committed revision 1328346.
Gary
[SFTP] SftpFileObject getInputStream(long) reads the whole file into memory
---
Key: VFS-410
URL: https://issues.apache.org/jira/browse/VFS-410
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Martin Stockhammer
Fix For: 2.1
Attachments: SftpFileObject.java.patch
The method {{getInputStream(long filePointer)}} in {{SftpFileObject.java}}
reads the complete file into memory to create the input stream.
Newer versions of JSch provide a method
{{channel.get(file, monitor, filePointer);}}
that is much faster.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-395) [POM] Declare maven-scm-* dependencies as optional.
[ https://issues.apache.org/jira/browse/VFS-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-395. - Resolution: Fixed Removed the offeding plugins. Committed revision 1328366. [POM] Declare maven-scm-* dependencies as optional. --- Key: VFS-395 URL: https://issues.apache.org/jira/browse/VFS-395 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Xavier Dury Fix For: 2.1 VFS2 includes weird dependencies: maven-scm-api, maven-scm-provider-svnexe. See http://commons.apache.org/vfs/commons-vfs2/dependencies.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-104) Add a function for the classical Unix crypt(3) hash
[ https://issues.apache.org/jira/browse/CODEC-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-104. --- Resolution: Duplicate Marking as duplicate of the more complete [CODEC-133] Add a function for the classical Unix crypt(3) hash --- Key: CODEC-104 URL: https://issues.apache.org/jira/browse/CODEC-104 Project: Commons Codec Issue Type: New Feature Reporter: Christian Hammers Fix For: 1.x The Sun Java APIs lack a function for the classical Unix crypt(3) hash that was used in e.g. /etc/passwd or Apache htpasswd and is still widely used dispite the availablitity of better algorithms like MD5 or SHA. Apart from me cursing Sun for producing monster crypto APIs but missing the little things that one really needs, there are already several Apache projects that implemented UnixCrypt for their own: org.apache.directory.studio.ldapbrowser.core.utils.UnixCrypt org.apache.fulcrum.crypto.impl.UnixCrypt and maybe others bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-133) Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants.
[ https://issues.apache.org/jira/browse/CODEC-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-133. --- Resolution: Fixed Fix Version/s: 1.7 In SVN. Add classes for MD5/SHA1/SHA-512-based Unix crypt(3) hash variants. --- Key: CODEC-133 URL: https://issues.apache.org/jira/browse/CODEC-133 Project: Commons Codec Issue Type: New Feature Affects Versions: 1.6 Reporter: Christian Hammers Labels: MD5, SHA-512, crypt(3), crypto, hash Fix For: 1.7 Attachments: commons-codec-crypt3.diff, crypt3-with-utexas-licence.diff The Linux libc6 crypt(3) function, which is used to generate e.g. the password hashes in /etc/shadow, is available in nearly all other programming languages (Perl, PHP, Python, C, C++, ...) and databases like MySQL and offers MD5/SHA1/SHA-512 based algorithms that were improved by adding a salt and several iterations to make rainbow table attacks harder. Thus they are widely used to store user passwords. Java, though, has due it's platform independence, no direct access to the libc functions and still lacks an proper port of the crypt(3) function. I already filed a wishlist bug (CODEC-104) for the traditional 56-bit DES based crypt(3) method but would also like to see the much stronger algorithms. There are other bug reports like DIRSTUDIO-738 that demand those crypt variants for some specific applications so there it would benefit other Apache projects as well. Java ports of most of the specific crypt variants are already existing, but they would have to be cleaned up, properly tested and license checked: ftp://ftp.arlut.utexas.edu/pub/java_hashes/ I would be willing to help here by cleaning the source code and writing unit tests etc. but I'd like to generally know if you are interested and if there's someone who can do a code review (it's security relevant after all and I'm no crypto guy) bye, -christian- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-668) Polygon difference function produces erroneous results with certain polygons
[ https://issues.apache.org/jira/browse/MATH-668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-668. Resolution: Not A Problem Fix Version/s: (was: 3.1) 3.0 I agree with Thomas analyses. Concerning the difference2 case, the two points are explained by the vertical line at x = 5.0 which comes from the outer shape. The internal representation is a BSP tree and one of this part of the outer boundary creates an hyperplane that splits the inner triangle. When the boundary representation is rebuilt, the two segments are glued together and the points appear there. There is no post-processing that simplifies the representation afterwards. Concerning the circle test, I guess you mixed the arrays. What is really in the code is that the vertices2 array is build first from outer circle and the vertices1 array is built afterwards from inner circle. So you are really subtracting a big disk from a smaller one. As Thomas explained, computing set2 minus set1 give the expected two boundaries. Another possible change is to build the circles clockwise instead of counter-clockwise, and in this case the two regions are infinite wich a whole at the center, then subtracting set2 from set1 returns a disk with a hole. Polygon difference function produces erroneous results with certain polygons Key: MATH-668 URL: https://issues.apache.org/jira/browse/MATH-668 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Curtis Jensen Assignee: Luc Maisonobe Labels: difference, math,, polygon, Fix For: 3.0 Attachments: PolygonsSetCircleTest.java, PolygonsSetTest.java Original Estimate: 168h Remaining Estimate: 168h For some polygons, the difference function produces erroneous results. This appears to happen when one polygon is completely encompassed in another, and the outer has multiple concave sections. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CHAIN-68) SNAPSHOT tomcat plugin breaks the build
[
https://issues.apache.org/jira/browse/CHAIN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved CHAIN-68.
-
Resolution: Fixed
Fix Version/s: 2.0
fixed at [r1328084|http://svn.apache.org/viewvc?rev=1328084view=rev]
SNAPSHOT tomcat plugin breaks the build
---
Key: CHAIN-68
URL: https://issues.apache.org/jira/browse/CHAIN-68
Project: Commons Chain
Issue Type: Bug
Affects Versions: 2.0
Reporter: Simone Tripodi
Assignee: Simone Tripodi
Priority: Critical
Fix For: 2.0
Attachments: tomcat_runnder.diff
the {{apps/cookbook-examples/pom.xml}} contains the {{tomcat7-maven-plugin}}
configured to version {{2.0-SNAPSHOT}} breaks the build on Continuum - see
dev@ ML.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-327) Add byteCountToDisplaySize(BigInteger)
[ https://issues.apache.org/jira/browse/IO-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-327. Resolution: Fixed In SVN. Add byteCountToDisplaySize(BigInteger) -- Key: IO-327 URL: https://issues.apache.org/jira/browse/IO-327 Project: Commons IO Issue Type: New Feature Components: Utilities 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 Fix For: 2.4 Add byteCountToDisplaySize(BigInteger), just like Add byteCountToDisplaySize(long), in fact the long version can call the BI version to avoid duplication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CHAIN-66) Updated Chain documentation to include new changes to the API
[ https://issues.apache.org/jira/browse/CHAIN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved CHAIN-66. - Resolution: Fixed Fix Version/s: 2.0 Assignee: Simone Tripodi Thanks a lot for your patch Elijah, revised and successfully applied with minor changes, see r1327509 Thanks once again for contributing! Updated Chain documentation to include new changes to the API - Key: CHAIN-66 URL: https://issues.apache.org/jira/browse/CHAIN-66 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Assignee: Simone Tripodi Labels: documentaion Fix For: 2.0 Attachments: chain-66.diff Since the chain API is getting generics in the 2.0 release, we need to update the documentation so that it reflects the API update. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-90) CSVFormat isEscaping/isEncapsulating are not public
[ https://issues.apache.org/jira/browse/CSV-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-90. - Resolution: Fixed CSVFormat isEscaping/isEncapsulating 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] [Resolved] (IO-324) Add missing Charset sister APIs to method that take a String charset name.
[ https://issues.apache.org/jira/browse/IO-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-324. Resolution: Fixed In SVN. Add missing Charset sister APIs to method that take a String charset name. -- Key: IO-324 URL: https://issues.apache.org/jira/browse/IO-324 Project: Commons IO Issue Type: New Feature Components: Utilities 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 Fix For: 2.4 Add Charset sister APIs to method that take a String charset name. This is like [IO-318] for 2.3. At least one API was missed: - org.apache.commons.io.FileUtils.writeStringToFile(File, String, Charset) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-325) Add IOUtils.toByteArray methods to work with URL and URI
[ https://issues.apache.org/jira/browse/IO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-325. Resolution: Fixed In SVN. Add IOUtils.toByteArray methods to work with URL and URI Key: IO-325 URL: https://issues.apache.org/jira/browse/IO-325 Project: Commons IO Issue Type: New Feature Components: Utilities 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 Fix For: 2.4 Add IOUtils.toByteArray methods to work with URL and URI: - IOUtils.toByteArray(URI) - IOUtils.toByteArray(URL) - IOUtils.toByteArray(URLConnection) - IOUtils.close(URLConnection) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-72) Incorrect reading TIFF file
[
https://issues.apache.org/jira/browse/SANSELAN-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-72.
--
Resolution: Fixed
Fix Version/s: 1.0
The problem with the grey background was that Sanselan was using the worst
possible algorithm described in Section 9.1 of the PNG spec. I've changed it to
use the best one as of commit 1325915.
Both issues are now gone - resolving fixed.
Incorrect reading TIFF file
---
Key: SANSELAN-72
URL: https://issues.apache.org/jira/browse/SANSELAN-72
Project: Commons Sanselan
Issue Type: Bug
Components: Format: PNG, Format: TIFF
Affects Versions: 1.x
Reporter: VVD
Fix For: 1.0
Attachments: in.png, in.tif, out-png-IM.png, out-tif.png
I found 2 bugs.
I have tif file in.tif.
1. After convert it to png (bmp, tga, etc) by Sanselan it getting horizontal
lines.
{code}
Sanselan.writeImage(Sanselan.getBufferedImage(new File(in.tif)), new
File(out-tif.png), ImageFormat.IMAGE_FORMAT_PNG, null);
{code}
gwenview, eog, kolourpaint, gimp, etc show in.tif without lines and out.png
with lines.
For example 1st line at ~860 points from top and in full width of picture.
2. After convert it to png by convert utility from ImageMagic, and then
convert it to png (bmp, tga, etc) by Sanselan it became gray - all white
pixels become gray.
{code}$ convert in.tif in.png{code}
{code}
Sanselan.writeImage(Sanselan.getBufferedImage(new File(in.png)), new
File(out-png-IM.png), ImageFormat.IMAGE_FORMAT_PNG, null);
{code}
gwenview, eog, kolourpaint, gimp, etc show in.png as black and white, but
out-png-IM.png as black and gray.
I'll attach all 4 files.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-775) In the ListPopulation constructor, the check for a negative populationLimit should occur first.
[ https://issues.apache.org/jira/browse/MATH-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-775. -- Resolution: Fixed In the ListPopulation constructor, the check for a negative populationLimit should occur first. --- Key: MATH-775 URL: https://issues.apache.org/jira/browse/MATH-775 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-775.txt Original Estimate: 1h Remaining Estimate: 1h In the ListPopulation constructor, the check to see whether the populationLimit is positive should occur before the check to see if the number of chromosomes is greater than the populationLimit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-779) ListPopulation Iterator allows you to remove chromosomes from the population.
[ https://issues.apache.org/jira/browse/MATH-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-779. -- Resolution: Fixed Fixed in r1325427 with minor modifications (updated javadoc, use getChromosomes() instead of Collections.unmodifiableList). ListPopulation Iterator allows you to remove chromosomes from the population. - Key: MATH-779 URL: https://issues.apache.org/jira/browse/MATH-779 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-779.txt Original Estimate: 1h Remaining Estimate: 1h Calling the iterator method of ListPopulation returns an iterator of the protected modifiable list. Before returning the iterator we should wrap it in an unmodifiable list. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (POOL-212) GenericObjectPool allows maxIdle minIdle
[ https://issues.apache.org/jira/browse/POOL-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-212. -- Resolution: Fixed Fixed in all current development lines. GenericObjectPool allows maxIdle minIdle -- Key: POOL-212 URL: https://issues.apache.org/jira/browse/POOL-212 Project: Commons Pool Issue Type: Bug Affects Versions: 1.4 Reporter: Sergejs Melderis Priority: Minor Fix For: 1.6.1, 2.0, 1.5.8 GenericObjectPool allows any values for minIdle and maxIdle, and performs no validation on those values. It allows maxIdle to be less than minIdle, and that creates weird behavior during eviction. After each eviction the Evictor thread calls ensureMinIdle() method which adds objects the pool using addObjectToPool() to make sure there at least minIdle objects in the pool.addObjectToPool() on another hand makes sure that there no more then maxIdle objects in the pool, and immediately destroys the newly created object. In my application we had minIdle configured to 100, but maxIdle wasn't configured and used the default value which is 8, and each eviction would create and destroy a bunch of objects. This issue can be fixed by adding checks in setMinIdle and setMaxIdle, or by adding maxIdle variable to the formula used in calculateDevicit() method. We use version 1.4, but I also tested it on latest 1.6 and observed the same behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-249) Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball
[ https://issues.apache.org/jira/browse/DAEMON-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved DAEMON-249. - Resolution: Won't Fix Fix Version/s: (was: 1.0.2) Version 1.0.2 is very much out of date; the current release is 1.0.10. In any case, it's not possible to update existing releases. Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball --- Key: DAEMON-249 URL: https://issues.apache.org/jira/browse/DAEMON-249 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.2 Environment: IBM PowerPC + IBM Java 6.0 SR10 on RHEL 6.1 Reporter: Kumar Ravi The workaround is to obtain the src. zip file from this URL: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip and to build the above tar file for PPC64 on an IBM Power system. Details: 1. Download this file: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip or the appropriate version for the build. 2. unzip the above downloaded file in a directory called /home/hadoop/commons (or any directory of your choice) 3. cd /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix 4. Run ./configure 5. Build the jsvc binary by typing make 6. Copy the jsvc binary thatr was just built to a new directory called /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 7.Copy the following text files home/hadoop/commons/commons-daemon-1.0.2-native-src directory to the /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build directory - 1. LICENSE.txt 2. NOTICE.txt 3. RELEASE-NOTES.txt 8. cd to the directory home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 9. Create the binary tar file for IBM Power by issuing the following command: tar -czvf commons-daemon-1.0.2-bin-linux-ppc64.tar.gz * 10. Copy the file to an appropriate directory where this can be accessed from the hadoop-common build: 11. For branch-1, edit the build.xml file on the build root to point to the binary tar file that was just built: property name=jsvc.location value=file:///home/hadoop/commons-daemon-1.0.2-bin-linux-ppc64.tar.gz/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-409) Update Apache Commons Compress to 1.4 from 1.3
[ https://issues.apache.org/jira/browse/VFS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-409. - Resolution: Fixed SendingC:/svn/org/apache/commons/trunks-proper/vfs/pom.xml Sending C:/svn/org/apache/commons/trunks-proper/vfs/src/changes/changes.xml Transmitting file data ... Committed revision 1324814. Update Apache Commons Compress to 1.4 from 1.3 -- Key: VFS-409 URL: https://issues.apache.org/jira/browse/VFS-409 Project: Commons VFS Issue Type: Task 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 Fix For: 2.1 Update Apache Commons Compress to 1.4 from 1.3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-68) Incorrect reading Physical Width/Height Dpi and Physical Width/Height Inch from TIFF files
[
https://issues.apache.org/jira/browse/SANSELAN-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-68.
--
Resolution: Fixed
Fix Version/s: 1.0
Patch applied to latest SVN. Thank you for your contribution!
Incorrect reading Physical Width/Height Dpi and Physical Width/Height Inch
from TIFF files
--
Key: SANSELAN-68
URL: https://issues.apache.org/jira/browse/SANSELAN-68
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0, 1.1, 1.x
Reporter: VVD
Labels: patch
Fix For: 1.0
Attachments: sanselan-tiff-dpi.diff
Width: 3509
Physical Width Dpi: 4650
Physical Width Inch: 1169.667
Height: 2481
Physical Height Dpi: 4650
Physical Height Inch: 827.00024
{code}
TiffImageParser.java (196):
-case 3: // Meter
-unitsPerInch = 0.0254;
+case 3: // Centimeter
+unitsPerInch = 2.54;
(c) http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf
TiffImageParser.java (218):
-physicalWidthDpi = (int) (XResolutionPixelsPerUnit /
unitsPerInch);
+physicalWidthDpi = (int) Math.round(XResolutionPixelsPerUnit
* unitsPerInch);
TiffImageParser.java (226):
-physicalHeightDpi = (int) (YResolutionPixelsPerUnit /
unitsPerInch);
+physicalHeightDpi = (int)
Math.round(YResolutionPixelsPerUnit * unitsPerInch);
{code}
After this patch I got correct values:
Width: 3509
Physical Width Dpi: 300
Physical Width Inch: 11.69667
Height: 2481
Physical Height Dpi: 300
Physical Height Inch: 8.2700024
May be need to patch writing of tiff image too - don't know.
P.S. GIMP show values: 300,000, 300,000, 11,697, 8,270.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-71) Software field is missing in Exif TagConstant and Changing the order of reader.getbyteorder in Tiffimage parser
[ https://issues.apache.org/jira/browse/SANSELAN-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic resolved SANSELAN-71. -- Resolution: Fixed Fix Version/s: 1.0 Patch applied, thank you! Software field is missing in Exif TagConstant and Changing the order of reader.getbyteorder in Tiffimage parser --- Key: SANSELAN-71 URL: https://issues.apache.org/jira/browse/SANSELAN-71 Project: Commons Sanselan Issue Type: Bug Environment: W-7 Reporter: Piyush Kapoor Priority: Minor Fix For: 1.0 Attachments: sanselan.patch Original Estimate: 1m Remaining Estimate: 1m Some fields like Software has been removed while modifying ExifTagConstants . In tiffimagepareser line reader.getbytereader should be below reader.readFirstDirectory. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-322) Add and use class Charsets
[ https://issues.apache.org/jira/browse/IO-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-322. Resolution: Fixed In SVN. Add and use class Charsets -- Key: IO-322 URL: https://issues.apache.org/jira/browse/IO-322 Project: Commons IO Issue Type: New Feature Components: Utilities 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 Fix For: 2.3 Add and use class Charsets, a class that defines constants the required JRE Charsets. Also includes a few util methods. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-388) Inconsistent Javadoc comment and code for prototypeFactory(T) in org.apache.commons.collections.FactoryUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-388.
-
Resolution: Fixed
Inconsistent Javadoc comment and code for prototypeFactory(T) in
org.apache.commons.collections.FactoryUtils
Key: COLLECTIONS-388
URL: https://issues.apache.org/jira/browse/COLLECTIONS-388
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.0, 4.x
Environment: Platform independent
Reporter: SHIN HWEI TAN
Labels: javadoc, null
Fix For: 4.0
Original Estimate: 2m
Remaining Estimate: 2m
The Javadoc comment below states that the method throws
IllegalArgumentException if the prototype is null:
/**
..
* @param prototype the object to clone each time in the factory
* @return the codeprototype/code factory
* @throws IllegalArgumentException if the prototype is null
* @throws IllegalArgumentException if the prototype cannot be
cloned
*/
public static T FactoryT prototypeFactory(T prototype) {
return PrototypeFactory.TprototypeFactory(prototype);
}
However, the method returns a NULL_INSTANCE object instead of throwing
IllegalArgumentException when called with null.
Suggested Fixes:
1. Change @throws IllegalArgumentException if the prototype is null and
@return to @return NULL_INSTANCE if the prototype is null.
or
2. Remove the entire throws IllegalArgumentException if the prototype is
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] [Resolved] (COLLECTIONS-389) Inconsistent Javadoc comment and code for mapTransformer(Map? super I, ? extends O) in org.apache.commons.collections.TransformerUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-389.
-
Resolution: Fixed
Fix Version/s: 4.0
Thanks for the report. It has been fixed in r1311337.
I have picked option 1.
Inconsistent Javadoc comment and code for mapTransformer(Map? super I, ?
extends O) in org.apache.commons.collections.TransformerUtils
Key: COLLECTIONS-389
URL: https://issues.apache.org/jira/browse/COLLECTIONS-389
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.0, 4.x
Environment: Platform Independent
Reporter: SHIN HWEI TAN
Labels: javadoc, null
Fix For: 4.0
Original Estimate: 2m
Remaining Estimate: 2m
The Javadoc comment below states that the method throws
IllegalArgumentException if the map is null:
/**
* @param map the map to use to transform the objects
* @return the transformer
* @throws IllegalArgumentException if the map is null
*/
public static I, O TransformerI, O mapTransformer(Map? super
I, ? extends O map) {
return MapTransformer.mapTransformer(map);
}
However, the method returns a NULL_INSTANCE object instead of throwing
IllegalArgumentException when called with null.
Suggested Fixes:
1. Change @throws IllegalArgumentException if the map is null and @return
to @return NULL_INSTANCE if the map is null.
or
2. Remove the entire throws IllegalArgumentException if the map is 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] [Resolved] (COLLECTIONS-400) Inconsistent Javadoc comment and code in addIgnoreNull(CollectionT, T) in org.apache.commons.collections.CollectionUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-400.
-
Resolution: Fixed
Fix Version/s: 4.0
Thanks for the report. I have added the missing null check in r1311344.
Inconsistent Javadoc comment and code in addIgnoreNull(CollectionT, T) in
org.apache.commons.collections.CollectionUtils
--
Key: COLLECTIONS-400
URL: https://issues.apache.org/jira/browse/COLLECTIONS-400
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2.1
Environment: Platform independent
Reporter: SHIN HWEI TAN
Labels: javadoc
Fix For: 4.0
Original Estimate: 0.05h
Remaining Estimate: 0.05h
The Javadoc comment below states that the method throws NullPointerException
if the collection is null.
/**
.
* @param collection the collection to add to, must not be null
* @param object the object to add, if null it will not be added
* @return true if the collection changed
* @throws NullPointerException if the collection is null
*/
public static T boolean addIgnoreNull(CollectionT collection, T
object) {
return (object != null collection.add(object));
}
However, when called with an null collection and a null object (i.e.,
addIgnoreNull((Collection)null, null)), the method executes normally
without throwing any exception.
Suggested Fixes:
1. Add code if (collection == null) throw NullPointerException(); at the
beginning of the method body.
or
2. Remove @throws NullPointerException if the collection is null from the
Javadoc.
or
3. Change @throws NullPointerException if the collection is null to
@throws NullPointerException if the collection is null and the object is
non-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] [Resolved] (COLLECTIONS-391) Inconsistent Javadoc comment and code for toProperties(final MapK, V) in org.apache.commons.collections.MapUtils
[
https://issues.apache.org/jira/browse/COLLECTIONS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-391.
-
Resolution: Fixed
Fix Version/s: 4.0
Thanks for the report. Fixed in r1311359.
The additional constraint about the map parameter has been removed, as the
javadoc already states that a null input will result in an empty properties
object.
Inconsistent Javadoc comment and code for toProperties(final MapK, V) in
org.apache.commons.collections.MapUtils
--
Key: COLLECTIONS-391
URL: https://issues.apache.org/jira/browse/COLLECTIONS-391
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 4.0, 4.x
Environment: Platform Indepedent
Reporter: SHIN HWEI TAN
Labels: javadoc, null
Fix For: 4.0
Original Estimate: 2m
Remaining Estimate: 2m
The Javadoc comment below states that the parameter map ..., may not be
null:
/**
..
* @param map the map to convert to a Properties object, may not
be null
* @return the properties object
*/
public static K, V Properties toProperties(final MapK, V map) {
Properties answer = new Properties();
if (map != null) {
...
}
return answer;
}
However, the method return normally without throwing any exception when
called with null.
Suggested Fixes:
1. Change @param map the map to convert to a Properties object, may not be
null to @param map the map to convert to a Properties object, may be null
or
2. Remove may not be null from @param.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-378) Incorrect links in JavaDoc
[ https://issues.apache.org/jira/browse/COLLECTIONS-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved COLLECTIONS-378. - Resolution: Fixed Fix Version/s: 4.0 Thanks for the report. This has already been fixed in r1300075. Incorrect links in JavaDoc -- Key: COLLECTIONS-378 URL: https://issues.apache.org/jira/browse/COLLECTIONS-378 Project: Commons Collections Issue Type: Bug Affects Versions: 4.0-beta-1 Reporter: Ken Dombeck Fix For: 4.0 Attachments: COLLECTIONS-378_javadoc_fixes.patch The links for several JavaDocs were not updated during the implementation of COLLECTIONS-251. Attached patch file includes the necessary changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COLLECTIONS-380) UnmodifiableBoundedCollection.unmodifiableBoundedCollection is an infinite loop
[
https://issues.apache.org/jira/browse/COLLECTIONS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved COLLECTIONS-380.
-
Resolution: Fixed
Fix Version/s: 4.0
Fixed in r1311366.
Additionally I have added a first unit test and fixed more javadoc issues in
the class.
UnmodifiableBoundedCollection.unmodifiableBoundedCollection is an infinite
loop
---
Key: COLLECTIONS-380
URL: https://issues.apache.org/jira/browse/COLLECTIONS-380
Project: Commons Collections
Issue Type: Bug
Components: Collection
Reporter: Dave Brosius
Priority: Minor
Fix For: 4.0
This method, just calls itself. As BoundedCollection extends Collection, it
would seem to me that this method should be removed:
/**
* Factory method to create an unmodifiable bounded collection.
*
* @param coll the codeBoundedCollection/code to decorate, must not
be null
* @return a new unmodifiable bounded collection
* @throws IllegalArgumentException if bag is null
*/
public static E BoundedCollectionE
unmodifiableBoundedCollection(BoundedCollectionE coll) {
return unmodifiableBoundedCollection(coll);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-321) ByteOrderMark UTF_32LE is incorrect
[
https://issues.apache.org/jira/browse/IO-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-321.
Resolution: Fixed
In SVN.
ByteOrderMark UTF_32LE is incorrect
---
Key: IO-321
URL: https://issues.apache.org/jira/browse/IO-321
Project: Commons IO
Issue Type: Bug
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
C:\svn\org\apache\commons\trunks-proper\lang\test\io-320.diff
Reporter: Gary D. Gregory
Fix For: 2.3
ByteOrderMark UTF_32LE is incorrect.
Is should be {{FF FE 00 00}} not {{FE FF 00 00}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-798) Use generics in SerializationUtils
[
https://issues.apache.org/jira/browse/LANG-798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved LANG-798.
--
Resolution: Fixed
In SVN.
Use generics in SerializationUtils
--
Key: LANG-798
URL: https://issues.apache.org/jira/browse/LANG-798
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
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
Fix For: 3.2
Use generics in SerializationUtils:
I'd like to propose the change below. This lets you get rid of type casts in
call sites. You'll still get a ClassCastException if you code it wrong of
course.
Old: {{public static Object deserialize(InputStream inputStream)}}
New: {{public static T T deserialize(InputStream inputStream)}}
Old: {{public static Object deserialize(byte[] objectData)}}
New: {{public static T T deserialize(byte[] objectData)}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-775) In the ListPopulation constructor, the check for a negative populationLimit should occur first.
[ https://issues.apache.org/jira/browse/MATH-775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-775. -- Resolution: Fixed The patch has been committed in r1310103, together with other changes that have been outlined before. Additionally, I have added two new methods: * public void addChromosomes(CollectionChromosome c) * protected ListChromosome getChromosomeList() and made setChromosomes deprecated. Rationale: The internal state of ListPopulation shall be protected, and shall not be changeable from the outside as it was possible before. When adding chromosomes, the entries are added to the internal list, instead of setting the internal list reference to the provided list. Derived classes can get access to the internal list via getChromosomeList (we could also make the internal list protected, is there a policy in CM?). The setters throw appropriate exceptions to keep the internal state consistent, and addChromosome also throws an exception if the population would exceed the population limit. In the ListPopulation constructor, the check for a negative populationLimit should occur first. --- Key: MATH-775 URL: https://issues.apache.org/jira/browse/MATH-775 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-775.txt Original Estimate: 1h Remaining Estimate: 1h In the ListPopulation constructor, the check to see whether the populationLimit is positive should occur before the check to see if the number of chromosomes is greater than the populationLimit. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-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:all-tabpanel
]
Gary D. Gregory resolved CODEC-96.
--
Resolution: Fixed
Assignee: (was: Julius Davies)
In SVN
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
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] [Resolved] (COMPRESS-183) Support for de/encoding of tar entry names other than plain 8BIT conversion.
[ https://issues.apache.org/jira/browse/COMPRESS-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-183. - Resolution: Fixed Forgot to close this, documentation has been completed about a week ago. Support for de/encoding of tar entry names other than plain 8BIT conversion. Key: COMPRESS-183 URL: https://issues.apache.org/jira/browse/COMPRESS-183 Project: Commons Compress Issue Type: Improvement Components: Archivers Affects Versions: 1.3 Reporter: Joao Schim Labels: patch Fix For: 1.4 Attachments: patch-tar-name-encoding.diff, patch-tar-name-encoding.diff, patch-tar-name-encoding.diff The names of tar entries are currently encoded/decoded by means of plain 8bit conversions of byte to char and vice-versa. This prohibits the use of encodings like UTF8 in the file names. Whether the use of UTF8 (or any other non ASCII) in file names is sensible is a chapter of its own. However tar archives that contain files which names have been encoded with UTF8 do float around. These files currently can not be read correctly by commons-compress due to the encoding being hardcoded to plain 8BIT only. The supplied patch allows to use encodings other than 8BIT using a TarArchiveCodec structure. It does not change the standard functionality, but adds to it the possibility of using a different encoding. A method was added to the TarUtilsTest junit test to test the added functionality. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
[
https://issues.apache.org/jira/browse/SANSELAN-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-70.
--
Resolution: Fixed
Fix Version/s: 1.0
I've applied the patch to the latest SVN.
Thank you for your contribution!
Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots
per millimeter
--
Key: SANSELAN-70
URL: https://issues.apache.org/jira/browse/SANSELAN-70
Project: Commons Sanselan
Issue Type: Bug
Components: Format: JPEG
Affects Versions: 0.97
Environment: N/A
Reporter: Tars Joris
Labels: patch
Fix For: 1.0
Attachments: Main.java, example_ppi.jpg, example_ppmm.jpg,
jpeg-dpi.patch.txt
The value of physical with DPI is incorrect for JPEG images, which express
their resolution in dots per millimeter.
Two images are attached:
- example_ppi.jpg: Normal image, with resolution specified in dots per inch
(72 pixels/in)
- example_ppmm.jpg: Same image, but with resolution specified in dots per
millimeter (2.8 pixels/mm)
When running the attached code, the output is
{code}
example_ppi.jpg
getPhysicalWidthDpi: 72
getPhysicalHeightDpi: 72
example_ppmm.jpg
getPhysicalWidthDpi: 11
getPhysicalHeightDpi: 71
{code}
While you'd expect the value 71 for getPhysicalWidthDpi for the second image.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCS-88) Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks.
[ https://issues.apache.org/jira/browse/JCS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-88. --- Resolution: Fixed Fix Version/s: jcs-1.4-dev Added the test contained in the patch. The problem was already fixed. Block cache fails to validate a cache file on startup when it contains elements with more than 2 blocks. Key: JCS-88 URL: https://issues.apache.org/jira/browse/JCS-88 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-1.3 Reporter: Diego Rivera Assignee: Thomas Vandahl Fix For: jcs-1.4-dev Attachments: jcs-1.3a-JCS-87-patch.patch Original Estimate: 0h Remaining Estimate: 0h The arithmetic for calculating block sizes is wrong. The code adds a term that shouldn't be considered at that point. For each block that needs to be written, the size of the block is currently calculated as: int chunkSize = Math.min( totalUsed + maxChunkSize, totalBytes - totalUsed ) The term totalUsed should not be added to maxChunkSize, since the intent is to construct a chunk that's either as big as is allowed (maxChunkSize) or as big as the remaining bytes (totalBytes - totalUsed). Thus, the correct calculation should be: int chunkSize = Math.min( maxChunkSize, totalBytes - totalUsed ) The problem occurs in src/java/org/apache/jcs/auxiliary/disk/block/BlockDisk.java, line 196, inside byte[][] getBlockChunks(byte[] complete, int numBlocksNeeded). A patch has been devised and will be submitted as a comment (since attachments aren't possible at this point). I still need to take the time to devise a unit test for this since the existing unit test passed without issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCS-90) When issuing a shutDown() command, JCS fails to clean up the Queue Processor thread. This can lead to thread leakage in an environment where webapps are hot-deployed and ho
[ https://issues.apache.org/jira/browse/JCS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-90. --- Resolution: Fixed Fix Version/s: jcs-1.4-dev Modified fix applied. When issuing a shutDown() command, JCS fails to clean up the Queue Processor thread. This can lead to thread leakage in an environment where webapps are hot-deployed and hot-undeployed. -- Key: JCS-90 URL: https://issues.apache.org/jira/browse/JCS-90 Project: Commons JCS Issue Type: Bug Affects Versions: jcs-1.3 Reporter: Diego Rivera Assignee: Thomas Vandahl Fix For: jcs-1.4-dev Attachments: jcs-90-fix.patch When a shutDown() command is issued to CompositeCacheManager, the the CompositeCache.eventProcessorQ thread is not disposed of, leading to thread leakage in environments where the JVM doesn't exit immediately after issuing the shutdown. This is the case in environments where web applications are hot-deployed or hot-undeployed. Similarly, the graceful termination implemented utilizes Thread.destroy(), which was never implemented, so there's nothing graceful about a NoSuchMethodError(). This has been changed to be a truly graceful exit (i.e. break out of the loop so that the method can return cleanly). A patch to fix will be attached shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCS-92) On shutdown .key (empty during runtime) not written and .data (not empty during runtime) deleted
[
https://issues.apache.org/jira/browse/JCS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Vandahl resolved JCS-92.
---
Resolution: Cannot Reproduce
Fix Version/s: jcs-1.3
This feature normally works if the cache is shut down properly.
On shutdown .key (empty during runtime) not written and .data (not empty
during runtime) deleted
Key: JCS-92
URL: https://issues.apache.org/jira/browse/JCS-92
Project: Commons JCS
Issue Type: Bug
Components: Composite Cache
Affects Versions: jcs-1.3
Environment: win 7x64; jvm 1.6
Reporter: Karl Klinge
Fix For: jcs-1.3
On shutdown .key (which is empty during runtime) is not written from memory
and .data (not empty during runtime) is deleted.
cache ccf:
#
## Default Region Configuration
jcs.default=DC2
jcs.default.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.default.cacheattributes.MaxObjects=50
jcs.default.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
#
## CACHE REGIONS
jcs.region.sac=DC2
jcs.region.sac.cacheattributes=org.apache.jcs.engine.CompositeCacheAttributes
jcs.region.sac.cacheattributes.MaxObjects=10
jcs.region.sac.cacheattributes.MemoryCacheName=org.apache.jcs.engine.memory.lru.LRUMemoryCache
jcs.region.sac.elementattributes.IsEternal=true
##jcs.region.sac.elementattributes.MaxLifeSeconds=172800 ## 2 Tage
jcs.region.sac.cacheattributes.DiskUsagePatternName=UPDATE
### AUXILIARY CACHES
# Indexed Disk Cache
jcs.auxiliary.DC2=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheFactory
jcs.auxiliary.DC2.attributes=org.apache.jcs.auxiliary.disk.indexed.IndexedDiskCacheAttributes
jcs.auxiliary.DC2.attributes.DiskPath=c:/cache/status
jcs.auxiliary.DC2.attributes.MaxPurgatorySize=1000
jcs.auxiliary.DC2.attributes.MaxKeySize=10
jcs.auxiliary.DC2.attributes.OptimizeAtRemoveCount=3
jcs.auxiliary.DC2.attributes.OptimizeOnShutdown=true
jcs.auxiliary.DC2.attributes.MaxRecycleBinSize=1000
Object to write to cache:
key: string
value (all used classes in import implement Serializable):
package de.spektra.rtd.sdb.condition;
import de.spektra.rtd.model.event.Event;
import de.spektra.rtd.model.event.StatusAlarmCondition;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.Collection;
import java.util.HashMap;
import java.util.Map;
/**
*
* @author Klinge
*/
public class DistrictConditions implements Serializable{
//private static final java.util.logging.Logger logger =
Logger.getLogger(DistrictCondition);
private MapString, DistrictObjectTypeConditions objectTypesConditions;
public DistrictConditions() {
this.objectTypesConditions = new HashMapString,
DistrictObjectTypeConditions();
}
public ObjectCondition setEvent(Event event) {
String objectType = event.getIdentification().getObjectType();
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions == null) {
objectTypeConditions = new DistrictObjectTypeConditions();
this.objectTypesConditions.put(objectType, objectTypeConditions);
}
return objectTypeConditions.setEvent(event);
}
public ObjectCondition getObjectCondtion(String objectType, String
identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
//logger.log(Level.INFO, objectTypeConditions: {0},
objectTypeConditions);
return objectTypeConditions.getObjectCondition(identification);
}
public CollectionObjectCondition getObjectConditions(CollectionString
objectTypes) {
ArrayListObjectCondition objectConditions = new
ArrayListObjectCondition();
for (String objectType: objectTypes) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
if (objectTypeConditions!=null) {
objectConditions.addAll(objectTypeConditions.getObjectConditions());
}
}
return objectConditions;
}
public StatusAlarmCondition getCurrentStatusAlarmCondtition(String
objectType, String identification) {
DistrictObjectTypeConditions objectTypeConditions =
this.objectTypesConditions.get(objectType);
return
objectTypeConditions.getCurrentStatusAlarmCondition(identification
[jira] [Resolved] (MATH-776) Need range checks for elitismRate in ElitisticListPopulation constructors.
[ https://issues.apache.org/jira/browse/MATH-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-776. -- Resolution: Fixed Patch applied with minor modification in r1308454. Thanks for the contribution! Need range checks for elitismRate in ElitisticListPopulation constructors. -- Key: MATH-776 URL: https://issues.apache.org/jira/browse/MATH-776 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-776.txt Original Estimate: 1h Remaining Estimate: 1h There is a range check for setting the elitismRate via ElitisticListPopulation's setElitismRate method, but not via the constructors. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
[ https://issues.apache.org/jira/browse/MATH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-773. -- Resolution: Fixed You should be able to run evolution simulation for a certain amount of time. Key: MATH-773 URL: https://issues.apache.org/jira/browse/MATH-773 Project: Commons Math Issue Type: Improvement Reporter: Reid Hochstedler Labels: genetics Fix For: 3.1 Attachments: MATH-773.r2.txt, MATH-773.txt Original Estimate: 2h Remaining Estimate: 2h You should be able to run your GeneticAlgorithm for a fixed amount of time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
[ https://issues.apache.org/jira/browse/CODEC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-138. Resolution: Fixed Fix Version/s: 1.7 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] [Resolved] (JCS-89) UDP Discovery fails to report correct IP address to peers for back-connect when InetAddress.getLocalHost() fails to return an externally-visible address (i.e. returns a loca
[ https://issues.apache.org/jira/browse/JCS-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-89. --- Resolution: Fixed Fix Version/s: jcs-1.4-dev Patch applied. UDP Discovery fails to report correct IP address to peers for back-connect when InetAddress.getLocalHost() fails to return an externally-visible address (i.e. returns a local address) --- Key: JCS-89 URL: https://issues.apache.org/jira/browse/JCS-89 Project: Commons JCS Issue Type: Bug Reporter: Diego Rivera Assignee: Thomas Vandahl Fix For: jcs-1.4-dev Attachments: jcs-89-fix.patch Original Estimate: 1h Remaining Estimate: 1h On certain environments where reverse-lookup of the machine's IP address isn't available, or other IP configurations restrict the ability of the JVM to determine its own canonical local address, it's impossible to determine ahead of time what address should be sent into the UDP multicast in order for lateral peers to establish the back-connection. The fix for this is simple: when the packet is received with the discovery message, determine the source host address of the packet that was received and set that to the discovery message's host property (setHost(packet.getAddress().getHostAddress()). This way, it's 100% for certain we'll be back-connecting to the correct instance. A patch will be uploaded shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-767) Unbalanced code usage in javadoc
[
https://issues.apache.org/jira/browse/MATH-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Neidhart resolved MATH-767.
--
Resolution: Fixed
Unbalanced code usage in javadoc
--
Key: MATH-767
URL: https://issues.apache.org/jira/browse/MATH-767
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0
Environment: n/a
Reporter: Dennis Hendriks
Labels: javadoc
Fix For: 3.1
See http://commons.apache.org/math/apidocs/index-all.html and scroll to the
section 'D'. Observe how in method discardMostRecentElements(int) in class
org.apache.commons.math3.util.ResizableDoubleArray, the style changes to
larger font. As we can see in the source code for that method:
{code}
* Discards the codeicode last elements of the array. For example,
{code}
this should become:
{code}
* Discards the codei/code last elements of the array. For example,
{code}
as then the code.../code is balanced. Or even better, it could become:
{code}
* Discards the {@code i} last elements of the array. For example,
{code}
This applies elsewhere as well, for instance the isSame(Chromosome) method in
the org.apache.commons.math3.genetics.BinaryChromosome class.
We should probably check all javadoc, to make sure this is correct
everywhere. Since it is way too much to do manually, maybe a script or other
automated check could detect such cases?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-318) Add Charset sister APIs to method that take a String charset name.
[ https://issues.apache.org/jira/browse/IO-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-318. Resolution: Fixed In SVN. Add Charset sister APIs to method that take a String charset name. -- Key: IO-318 URL: https://issues.apache.org/jira/browse/IO-318 Project: Commons IO Issue Type: New Feature 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.7.0_03, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_03\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary D. Gregory Fix For: 2.3 Add Charset sister APIs to method that take a String charset name (aka encoding). For example: foo(..., String charsetName) - foo(..., Charset charset). Refactor such that we do not have code duplication of the algorithms. Known issue: Source compatibility. Now there are APIs that change only with the last type, String vs. Charset, you will get a compile error if you pass null to the old String API because the target method will be ambiguous: do you want to call the String or Charset version? You must type-cast to one type or the other. Known issue: checked java.io.UnsupportedEncodingException vs. unchecked java.nio.charset.UnsupportedCharsetException The JRE API Charset.forName throws the unchecked UnsupportedCharsetException. The Commons IO 2.2 String APIs throw the checked UnsupportedEncodingException, a subclass of IOException, when an charset is not available. The refactored String APIs throw UnsupportedCharsetException from Charset.forName, an unchecked IllegalArgumentException. The String APIs throw IOException, so there is no source compatibility issue. If you somehow relied on catching the checked UnsupportedEncodingException instead of IOException, its superclass, you should catch the unchecked java.nio.charset.UnsupportedCharsetException to act on the fact that the charset is not available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
[
https://issues.apache.org/jira/browse/COMPRESS-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-185.
-
Resolution: Duplicate
This is COMPRESS-146 which has already been fixed in trunk (and thus will be
fixed in 1.4).
BZip2CompressorInputStream truncates files compressed with pbzip2
-
Key: COMPRESS-185
URL: https://issues.apache.org/jira/browse/COMPRESS-185
Project: Commons Compress
Issue Type: Bug
Components: Compressors
Affects Versions: 1.3
Reporter: Karsten Loesing
Fix For: 1.4
I'm using BZip2CompressorInputStream in Compress 1.3 to decompress a file
that was created with pbzip2 1.1.6 (http://compression.ca/pbzip2/). The
stream ends early after 90 bytes, truncating the rest of the
pbzip2-compressed file. Decompressing the file with bunzip2 or compressing
the original file with bzip2 both fix the issue. I think both pbzip2 and
Compress are to blame here: pbzip2 apparently does something non-standard
when compressing files, and Compress should handle the non-standard format
rather than pretending to be done decompressing. Another option is that I'm
doing something wrong; in that case please let me know! :)
Here's how the problem can be reproduced:
1. Generate a file that's 90+ bytes large: dd if=/dev/zero of=1mbfile
count=1 bs=1M
2. Compress with pbzip2: pbzip2 1mbfile
3. Decompress with Bunzip2 class below
4. Notice how the resulting 1mbfile is 90 bytes large, not 1M.
Now compare to using bunzip2/bzip2:
- Do the steps above, but instead of 2, compress with bzip2: bzip2 1mbfile
- Do the steps above, but instead of 3, decompress with bunzip2: bunzip2
1mbfile.bz2
import java.io.*;
import org.apache.commons.compress.compressors.bzip2.*;
public class Bunzip2 {
public static void main(String[] args) throws Exception {
File inFile = new File(args[0]);
File outFile = new File(args[0].substring(0, args[0].length() - 4));
FileInputStream fis = new FileInputStream(inFile);
BZip2CompressorInputStream bz2cis =
new BZip2CompressorInputStream(fis);
BufferedInputStream bis = new BufferedInputStream(bz2cis);
BufferedOutputStream bos = new BufferedOutputStream(
new FileOutputStream(outFile));
int len;
byte[] data = new byte[1024];
while ((len = bis.read(data, 0, 1024)) = 0) {
bos.write(data, 0, len);
}
bos.close();
bis.close();
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-69) Eliminate CSVPrinterTest.equals(String[][], String[][]) by using Assert.assertArrayEquals
[ https://issues.apache.org/jira/browse/CSV-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-69. - Resolution: Fixed Eliminate CSVPrinterTest.equals(String[][], String[][]) by using Assert.assertArrayEquals - Key: CSV-69 URL: https://issues.apache.org/jira/browse/CSV-69 Project: Commons CSV Issue Type: Test Reporter: Benedikt Ritter Attachments: CSV-69.patch CSVPrinterTest uses an equals method to compare two dimensional String arrays. Since the project has been updated to JUnit 4, Assert.assertArrayEquals() can be used instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-57) CSVParser.getRecords() contract is confusing
[
https://issues.apache.org/jira/browse/CSV-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-57.
-
Resolution: Fixed
Patch no longer applies, because getRecords() now returns a list.
Added test case to show that the list is empty for an empty file.
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] [Resolved] (CSV-65) Header support
[
https://issues.apache.org/jira/browse/CSV-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-65.
-
Resolution: Fixed
This seems to be complete
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] [Resolved] (CSV-85) Allow comments to be returned in CSVRecord
[ https://issues.apache.org/jira/browse/CSV-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-85. - Resolution: Fixed 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] [Resolved] (CSV-89) Rename withLineSeparator as withOutputLineSeparator
[ https://issues.apache.org/jira/browse/CSV-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-89. - Resolution: Won't Fix Rename withLineSeparator as withOutputLineSeparator --- Key: CSV-89 URL: https://issues.apache.org/jira/browse/CSV-89 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The name withLineSeparator is misleading, as it could be taken to mean that the separator applies to input as well as output. The Javadoc tries to make this clear, but it would be better if the name reflected the function/purpose as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-43) CSVFormat fluent API is rather inefficient
[ https://issues.apache.org/jira/browse/CSV-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-43. - Resolution: Unresolved No longer using volatile, so nothing to do here. See CSV-68 for alternative. 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] [Resolved] (CSV-70) Improve readability of CSVLexer
[ https://issues.apache.org/jira/browse/CSV-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-70. - Resolution: Fixed I think this is now complete. 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() (x) this makes lexer slower * 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] [Resolved] (SANDBOX-416) Improve DFS/BFS visit detecting multiple states and related actions instead of just stop/continue
[
https://issues.apache.org/jira/browse/SANDBOX-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved SANDBOX-416.
Resolution: Fixed
issue resolved according to
[r1306016|http://svn.apache.org/viewvc?view=revisionrevision=1306016] by
Claudio - well done, mate!
Improve DFS/BFS visit detecting multiple states and related actions instead
of just stop/continue
-
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Claudio Squarcella
As discussed in
[ML|http://mail-archives.apache.org/mod_mbox/commons-dev/201203.mbox/%3CCAAqLGLOhZYC8qvT4TLugsnqCgw9BQ-%2BkYoGXVrKASy7PDZdeoQ%40mail.gmail.com%3E],
{{org.apache.commons.graph.visit.GraphVisitHandler}} methods that return
{{boolean}} flags can be sometimes not so intuitive.
The proposal is replacing {{boolean}} flags return statements with an
enumeration values {{ABORT}}, {{CONTINUE}}, {{SKIP}} to identify
* visit has to be immediately terminated
* visit can continue;
* current node children visit can be skipped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-84) Clarify comment handling
[ https://issues.apache.org/jira/browse/CSV-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-84. - Resolution: Fixed Fixed test case, docs and code 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] [Resolved] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CODEC-136. --- Resolution: Fixed In svn. Use Charset objects when possible, create Charsets class for required character encodings - Key: CODEC-136 URL: https://issues.apache.org/jira/browse/CODEC-136 Project: Commons Codec Issue Type: New Feature 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 Assignee: Gary D. Gregory Fix For: 1.7 Use Charset objects when possible, create Charsets for required character encodings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
[ https://issues.apache.org/jira/browse/DBCP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ortwin Glück resolved DBCP-378. --- Resolution: Invalid ManagedDataSource behaves correctly. The test is wrong (it compares null with null) ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (CollectionString) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame(Pool must NOT use identical connection across tx, ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
[
https://issues.apache.org/jira/browse/NET-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-455.
--
Resolution: Not A Problem
Thanks for confirming that it is not a problem in NET
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] [Resolved] (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:all-tabpanel ] Sebb resolved CSV-86. - Resolution: Fixed 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] [Resolved] (MATH-755) On the contract of FieldElementT.divide(T)
[
https://issues.apache.org/jira/browse/MATH-755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-755.
Resolution: Fixed
Actually fixed prior to the release of 3.0.
On the contract of FieldElementT.divide(T)
Key: MATH-755
URL: https://issues.apache.org/jira/browse/MATH-755
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.0, 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Labels: exception, field
Fix For: 3.1
As discussed on the mailing list:
{quote}
The contract of {{FieldElementT.divide(T)}} states that an
{{ArithmeticException}} should be thrown if the parameter is zero. However,
for this boundary case
* {{BigFraction}} throws {{ZeroException}}
* {{BigReal}} throws {{ArithmeticException}}
* {{Complex}} uses NaNs instead of exceptions
* {{Dfp}}, {{DfpDec}} use flags instead of exceptions
* {{Fraction}} throws {{MathArithmeticException}}.
{quote}
There is a need for some cleaning up, which will proceed in two steps
# in the {{FieldElement}} interface the statement that an exception must be
thrown will be removed. The rationale for this is that sometimes, an
exception is actually not wanted. For example, I'm using a wrapper around
primitive {{double}}, and I want all boundary cases to be handled _exactly_
the same way as the primitive operation /).
# the _same_ exception (if any) will be thrown by all implementations. This
will require to chose between {{ArithmeticException}},
{{MathArithmeticException}} and {{ZeroException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-771) Improve javadoc for iterative linear solvers with preconditioners
[
https://issues.apache.org/jira/browse/MATH-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-771.
Resolution: Fixed
Fixed in {{r1306150}}.
Improve javadoc for iterative linear solvers with preconditioners
-
Key: MATH-771
URL: https://issues.apache.org/jira/browse/MATH-771
Project: Commons Math
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Labels: javadoc, linear, solver
Preconditioning is the replacement of the linear system {{A * x = b}} with
{{A * M^(-1) * y = b}}, followed by {{x = M^(-1) * y}}, where {{M}}
approximates in some sense {{A}}. There is no consensus in the literature as
to whether {{M}} of {{M^(-1)}} should be called the preconditioner.
In {{o.a.c.m3.linear}}, the Javadoc currently states that {{M}} is the
preconditioner. However, following MATH-735, the solver must be passed
{{M^(-1)}} (not {{M}}!) as a {{RealLinearOperator}}. This makes the whole
Javadoc a bit obscure. It would be logical to call preconditioning the
replacement of the initial system with {{A * M * y = b}}, where {{M}}
approximates in some sense {{A^(-1)}} and will be called the preconditioner.
Such a change will make the javadoc more readable. However, it requires
careful review of the existing Javadoc for the following classes
* {{PreconditionedIterativeLinearSolver}},
* {{ConjugateGradient}},
* {{SymmLQ}},
* {{JacobiPreconditioner}},
Also, in {{PreconditionedIterativeLinearSolver}} (and its concrete
implementations), the parameter {{minv}} in {{solve()}} should be renamed
{{m}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-756) double as FieldElement
[
https://issues.apache.org/jira/browse/MATH-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-756.
Resolution: Fixed
Fix Version/s: 3.1
New feature added in {{r1306177}}.
double as FieldElement
--
Key: MATH-756
URL: https://issues.apache.org/jira/browse/MATH-756
Project: Commons Math
Issue Type: New Feature
Affects Versions: 3.1
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Priority: Minor
Labels: double, field
Fix For: 3.1
As discussed on the mailing-list, it is proposed to develop a wrapper class
around the {{double}} primitive type. This wrapper class should implement
{{FieldElement}}. This would allow generic calculations on exchangeable
number types (big fractions, big decimals, fractions, decimals). This class
will be called {{Decimal64}} (together with the corresponding
{{Decimal64Field}}).
Similarly, to the {{BigReal}} class, the newly created {{Decimal64}} class
could go to the {{o.a.c.m3.util}} package.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-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:all-tabpanel
]
Sebb resolved CSV-77.
-
Resolution: Fixed
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] [Resolved] (CSV-72) CSVFormat.DEFAULT should be renamed as RFC4180
[ https://issues.apache.org/jira/browse/CSV-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-72. - Resolution: Fixed Added new RFC4180 constant 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] [Resolved] (CSV-54) Confusing semantic of the ignore leading/trailing spaces parameters
[
https://issues.apache.org/jira/browse/CSV-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-54.
-
Resolution: Fixed
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] [Resolved] (CSV-87) CSVParser.getRecords() returns null rather than empty List at EOF
[ https://issues.apache.org/jira/browse/CSV-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-87. - Resolution: Fixed CSVParser.getRecords() returns null rather than empty List at EOF - Key: CSV-87 URL: https://issues.apache.org/jira/browse/CSV-87 Project: Commons CSV Issue Type: Bug Reporter: Sebb CSVParser.getRecords() returns null rather than empty List at EOF. It's usually easier for applications to deal with empty lists than to have to check for null after every invocation of the method. If the application really does need to know if the list is emty, then it can use a method such as isEmpty(). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-75) ExtendedBufferReader does not handle EOL consistently
[ https://issues.apache.org/jira/browse/CSV-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-75. - Resolution: Fixed 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] [Resolved] (CSV-83) Provide a header encapsulator class
[ https://issues.apache.org/jira/browse/CSV-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-83. - Resolution: Won't Fix 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] [Resolved] (DBUTILS-88) Make AsyncQueryRunner be a decorator around a QueryRunner
[ https://issues.apache.org/jira/browse/DBUTILS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William R. Speirs resolved DBUTILS-88. -- Resolution: Fixed Fix Version/s: 1.5 Patch applied in r1305706 Make AsyncQueryRunner be a decorator around a QueryRunner - Key: DBUTILS-88 URL: https://issues.apache.org/jira/browse/DBUTILS-88 Project: Commons DbUtils Issue Type: Task Reporter: Moandji Ezana Priority: Minor Fix For: 1.5 Attachments: AsyncQueryRunner_wraps_QueryRunner.txt, DBUTILS-88v1.patch, DBUTILS-88v2.patch AsyncQueryRunner duplicates much of the code in QueryRunner. Would it be possible for AsyncQueryRunner to simply decorate a QueryRunner with async functionality, in the same way a BufferedInputStream might decorate an InputStream? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-184) PAX header parser fails for non-ASCII values
[
https://issues.apache.org/jira/browse/COMPRESS-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-184.
-
Resolution: Fixed
fixed with svn revision 1304345
PAX header parser fails for non-ASCII values
Key: COMPRESS-184
URL: https://issues.apache.org/jira/browse/COMPRESS-184
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.3
Reporter: Stefan Bodewig
Assignee: Stefan Bodewig
Fix For: 1.4
The current logic parsing PAX extension headers fails if the number of bytes
used to encode an entry is different from the number of characters - i.e. for
any character outside of the ASCII range as the headers are UTF-8 encoded.
E.g.
{noformat}
11 path=ä
{noformat}
takes 11 bytes (one has to account for the trailing newline) for 10
characters and the parser fails with Expected 3 chars, read 2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-450) Bug in documentation for FTPClient
[ https://issues.apache.org/jira/browse/NET-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-450. -- Resolution: Fixed Fix Version/s: 3.2 Bug in documentation for FTPClient -- Key: NET-450 URL: https://issues.apache.org/jira/browse/NET-450 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1 Environment: Documentation on Apache web site Reporter: Roger Hardiman Priority: Minor Fix For: 3.2 Original Estimate: 5m Remaining Estimate: 5m In the Documentation for FTPClient there are some examples One is FTPClient f = new FTPClient(); f.connect(server); f.login(username, password); FTPFile[] files = listFiles(directory); There is a typo on the last line. It should be f.listFiles(directory); Rating this as Minior as any decent Java programmer should work it out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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:all-tabpanel ] Sebb resolved NET-451. -- Resolution: Incomplete Insufficient info 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] [Resolved] (CODEC-135) Null Pointer Exception
[
https://issues.apache.org/jira/browse/CODEC-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CODEC-135.
Resolution: Invalid
This is not an Apache Commons issue.
Appears to be an Android issue.
Null Pointer Exception
--
Key: CODEC-135
URL: https://issues.apache.org/jira/browse/CODEC-135
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.5
Environment: Android Application Development
Reporter: john
Original Estimate: 12h
Remaining Estimate: 12h
I am trying to parse a certificate(.pfx).But I am getting following exception
while parsing the certificate.
CertificateException:org.apache.harmony.security.asn1.ASN1Exception: DER:
only definite length encoding MUST be user.
{code}
package com.ams;
import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.Enumeration;
import javax.security.cert.Certificate;
import android.content.Context;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.Toast;
public class CertificateComponent {
private static final String TAG = CertificateParser;
public static final String PFX = sdcard/AC350.pfx;
public static final String CER = sdcard/test.cer;
X509Certificate cert;
FileInputStream in;
Context ctx;
private Button Pkcs12Button;
private Button CertButton;
public void click(View v) {
try {
if (v.getId() == R.id.pkcs12_button) {
String password = TZ96dtbx;
KeyStore ks = KeyStore.getInstance(PKCS12);
in= new FileInputStream(PFX);
// byte[] p12 = readFile(PFX);
in.close();
ks.load(in, password.toCharArray());
EnumerationString aliasesEnum = ks.aliases();
// Log.i(TAG, certificate details: +
aliasesEnum);
String alias = (String)
aliasesEnum.nextElement();
// System.out.println(Alias: + alias);
cert = (X509Certificate)
ks.getCertificate(alias);
while (aliasesEnum.hasMoreElements()) {
Log.i(TAG, Type: + cert.getType());
Log.i(TAG, Key Algorithm:
+
cert.getPublicKey().getAlgorithm());
Log.i(TAG, Version: +
cert.getVersion());
Log.i(TAG, Issuer DN: +
cert.getIssuerDN());
Log.i(TAG, Subject: +
cert.getSubjectDN());
Log.i(TAG, Valid From: +
cert.getNotBefore());
Log.i(TAG, Valid Till: +
cert.getNotAfter());
Log.i(TAG, Public Key: +
cert.getPublicKey());
Log.i(TAG, Serial Number: +
cert.getSerialNumber());
Log.i(TAG, Signature: +
cert.getSignature());
String message = Check Logcat For
Certificate Details;
Toast.makeText(ctx, message,
Toast.LENGTH_SHORT).show();
}
} else if (v.getId() == R.id.cert_button) {
// String filename = sdcard/test_b64.cer;
in = new FileInputStream(CER);
BufferedInputStream bf = new
BufferedInputStream(in);
CertificateFactory cf =
CertificateFactory.getInstance(X.509);
cert = (X509Certificate)
cf.generateCertificate(bf);
while (bf.available() 0) {
Log.i(TAG, Type: + cert.getType());
Log.i(TAG, Key Algorithm:
+
cert.getPublicKey().getAlgorithm());
Log.i(TAG, Version: +
cert.getVersion
[jira] [Resolved] (COMMONSSITE-70) org.apache.harmony.security.asn1 throwing null pointer exception
[
https://issues.apache.org/jira/browse/COMMONSSITE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved COMMONSSITE-70.
-
Resolution: Invalid
Fix Version/s: (was: 19)
This is definitely not a COMMONSSITE issue, and does not appear to be an Apache
Commons issue.
There is no sign of any Apache Commons packages being used here.
It seems to be an Android issue; please post on the appropriate Android forum
and ask there.
org.apache.harmony.security.asn1 throwing null pointer exception
Key: COMMONSSITE-70
URL: https://issues.apache.org/jira/browse/COMMONSSITE-70
Project: Commons All
Issue Type: Bug
Components: Commons Build
Affects Versions: 19
Environment: Android application development.
Reporter: Srijan Basu
Labels: mentor
Original Estimate: 12h
Remaining Estimate: 12h
I am trying to parse a .cer certificate issued by Thwate(find it attacthed).I
am getting a null pointer exception while parsing the certificate.But I am
able to parse other .cer certificates without any problem.
package com.ams;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import com.ams.certparser.CertificateParserUtil;
public class CertificateParserTestActivity extends Activity {
/** Called when the activity is first created. */
private static String TAG = CertificateParserTestActivity;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
CertificateParserUtil certParserUtil = new
CertificateParserUtil(
sdcard/Thwate.cer,null);
certParserUtil.parse();
// Log.i(TAG, Type: + certParserUtil.getCertType());
Log.i(TAG, Version: + certParserUtil.getVersion());
Log.i(TAG, Basic Constraint Extensions: +
certParserUtil.getBasicConstraints());
Log.i(TAG, IssuerUniqueID: +
certParserUtil.getIssuerUniqueID());
Log.i(TAG, IssuerName: +
certParserUtil.getIssuerX500Principal());
Log.i(TAG, Public Key:+ certParserUtil.getPublicKey());
Log.i(TAG, Issuer DN: + certParserUtil.getIssuerDN());
Log.i(TAG, Subject: + certParserUtil.getSubjectDN());
Log.i(TAG, Valid From: + certParserUtil.getValidFrom());
Log.i(TAG, Valid Till: + certParserUtil.getValidTill());
Log.i(TAG, Public Key: +
certParserUtil.getPublicKey().getAlgorithm());
Log.i(TAG, Serial Number: + certParserUtil.getSerialNumber());
Log.i(TAG, Key: + certParserUtil.getKeyUsage());
Log.i(TAG, Signature: + certParserUtil.getSignature());
Log.i(TAG, SignSlgoName: + certParserUtil.getSigAlgName());
//Log.i(TAG, Signature: +
certParserUtil.getTBSCertificate());
}
}
package com.ams.certparser;
import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.math.BigInteger;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
import java.security.PublicKey;
import java.security.cert.CertificateEncodingException;
import java.security.cert.CertificateException;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.Date;
import java.util.Enumeration;
import javax.security.auth.x500.X500Principal;
import android.os.Environment;
import android.util.Log;
public class CertificateParserUtil {
private static final String TAG = CertificateParserUtil;
public static final String PFX = PFX;
public static final String CER = CER;
FileInputStream fin = null;
private String filePath;
private String password;
X509Certificate cert;
public CertificateParserUtil(String filePath, String password) {
this.filePath = filePath;
this.password = password;
}
private String getExtension() {
String ext = ;
int mid = filePath.lastIndexOf(.);
ext = filePath.substring(mid + 1, filePath.length());
return ext;
}
public void parse() {
String ext = getExtension();
File file = new File(filePath);
if (PFX.equalsIgnoreCase(ext)) {
KeyStore ks = null;
try {
ks
[jira] [Resolved] (VFS-407) [RAM] Reading a RAM FileSystem file fails because it never returns EOF -1.
[
https://issues.apache.org/jira/browse/VFS-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved VFS-407.
-
Resolution: Fixed
Patch applied, in SVN, thank you!
[RAM] Reading a RAM FileSystem file fails because it never returns EOF -1.
--
Key: VFS-407
URL: https://issues.apache.org/jira/browse/VFS-407
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Miroslav Pokorny
Fix For: 2.1
Attachments: CustomRamProviderTest.java,
EmptyRamProviderFileBugTests-from-miroslav.pokorny-20120322.patch
Original Estimate: 5m
Remaining Estimate: 5m
RamFileRandomAccessContent
ORIGINAL
@Override
public int read(byte[] b, int off, int len) throws IOException
{
int retLen = Math.min(len, getLeftBytes());
RamFileRandomAccessContent.this.readFully(b, off, retLen);
return retLen;
}
// getLeftBytes() returns 0 when empty. retLen is 0 when empty and never -1.
FIXED
// HACK Patched to return -1 when empty previously it returned 0
@Override
public int read(final byte[] b, final int off, final int len)
throws IOException {
int retLen = InputStreams.END;
final int left =
RamFileRandomAccessContent.this.getLeftBytes();
if (left 0) {
retLen = Math.min(len, left);
RamFileRandomAccessContent.this.readFully(b, off, retLen);
}
return retLen;
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-71) Add convenience Methods to CSVLexer
[
https://issues.apache.org/jira/browse/CSV-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-71.
-
Resolution: Fixed
Fixed. In my testing, the new CSVLexer is about 4% faster than the old one
(kept temporarily as CSVServer1 in the test tree).
To test:
{code}
set classpath=target/classes;target/test-classes
java -server org.apache.commons.csv.PerformanceTest 10 CSVServer CSVServer1
{code}
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] [Resolved] (CSV-80) CSVLexer.nextToken does not need wsBuf
[ https://issues.apache.org/jira/browse/CSV-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-80. - Resolution: Fixed Removal of the buffer improves performance by about 25% CSVLexer.nextToken does not need wsBuf -- Key: CSV-80 URL: https://issues.apache.org/jira/browse/CSV-80 Project: Commons CSV Issue Type: Bug Reporter: Sebb CSVLexer.nextToken carefully saves leading whitespace in wsBuf if leadingSpacesIgnored is *true*. Later on, if leadingSpacesIgnored is *false*, it adds the contents of wsBuf to the token content field. It's not entirely clear what this was intended to do, but at present it achieves nothing; tests pass without it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-81) Token.Type.isReady could perhaps be removed
[ https://issues.apache.org/jira/browse/CSV-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-81. - Resolution: Fixed Token.Type.isReady could perhaps be removed --- Key: CSV-81 URL: https://issues.apache.org/jira/browse/CSV-81 Project: Commons CSV Issue Type: Improvement Reporter: Sebb The isReady field is written in lots of places, but only read in 2 places: 1) CSVParser.getRecord() uses it to determine if there was any data found at EOF 2) CSVLexer.nextToken uses it to determine when to exit the loop, but could equally probably check for type == INVALID It ought to be possible to simplify this considerably since the only usage external to the Lexer is to distinguish the EOF case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-312) CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) ignores bufferSize
[ https://issues.apache.org/jira/browse/IO-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-312. - Resolution: Fixed Fix Version/s: 2.2 CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) ignores bufferSize --- Key: IO-312 URL: https://issues.apache.org/jira/browse/IO-312 Project: Commons IO Issue Type: Bug Reporter: Sebb Fix For: 2.2 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-311) IOUtils.read(InputStream/Reader) ignores the offset parameter
[ https://issues.apache.org/jira/browse/IO-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-311. - Resolution: Fixed Fix Version/s: 2.2 Thanks! IOUtils.read(InputStream/Reader) ignores the offset parameter - Key: IO-311 URL: https://issues.apache.org/jira/browse/IO-311 Project: Commons IO Issue Type: Bug Components: Utilities Reporter: Robert Muir Fix For: 2.2 Attachments: IO-311.patch IOUtils.read(InputStream input, byte[] buffer, int offset, int length) and read(Reader input, char[] buffer, int offset, int length) don't take the offset parameter into account... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-308) Allow applications to provide buffer (or size) for copyLarge methods?
[ https://issues.apache.org/jira/browse/IO-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-308. - Resolution: Fixed Fix Version/s: 2.2 @Manoj Thanks for the test data provided in IO-305. Allow applications to provide buffer (or size) for copyLarge methods? - Key: IO-308 URL: https://issues.apache.org/jira/browse/IO-308 Project: Commons IO Issue Type: New Feature Reporter: Sebb Priority: Minor Fix For: 2.2 Unlike the skip buffer, the copyLarge buffers cannot be shared between threads. The methods allocate their own buffers as local variables (current size 4096) It might be worth allowing applications to provide their own buffers, and/or specifying the buffer size to be used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-313) Add IOUTils.toBufferedReader(Reader)
[ https://issues.apache.org/jira/browse/IO-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-313. Resolution: Fixed Assignee: Gary D. Gregory In SVN. Add IOUTils.toBufferedReader(Reader) Key: IO-313 URL: https://issues.apache.org/jira/browse/IO-313 Project: Commons IO Issue Type: New Feature Reporter: Gary D. Gregory Assignee: Gary D. Gregory Fix For: 2.2 Add IOUTils.toBufferedReader(Reader) to return a new BufferedReader unless the given Reader is already a BufferedReader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-79) CSVFormat.isCommentingDisabled() is confusing/confused
[
https://issues.apache.org/jira/browse/CSV-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CSV-79.
-
Resolution: Fixed
Renamed method to isCommentingEnabled
CSVFormat.isCommentingDisabled() is confusing/confused
--
Key: CSV-79
URL: https://issues.apache.org/jira/browse/CSV-79
Project: Commons CSV
Issue Type: Bug
Reporter: Sebb
The Javadoc for CSVFormat.isCommentingDisabled() says:
{code}
/**
* Specifies whether comments are supported by this format.
*
* @return tttrue/tt is comments are supported, ttfalse/tt otherwise
*/
{code}
however the method actually does the opposite, as the name suggests.
Now we could just fix the Javadoc, but given that the other isXXX methods
return a positive result this would be inconsistent.
Also, it's generally better to return positive setting.
So I think renaming the method as isCommentingEnabled - and fixing the
method code - would be better.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-74) CSVFormat definitions are difficult to read and maintain
[ https://issues.apache.org/jira/browse/CSV-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-74. - Resolution: Fixed Applied with minor change - renamed NEW as PRISTINE CSVFormat definitions are difficult to read and maintain Key: CSV-74 URL: https://issues.apache.org/jira/browse/CSV-74 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Attachments: CSV-74.patch The CSVFormat definitions (DEFAULT, EXCEL etc) are very difficult to read because the ctor has so many parameters. Also, any change to the ctor parameters means all the definitions have to be changed. It would be much easier if the constants were defined using the standard API. This can be done by defining a base format (with everything disabled or null) and generating the constants from 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] [Resolved] (DIGESTER-163) ConcurrentModificationException creating a new Digester via loaderInstance.newDigester()
[
https://issues.apache.org/jira/browse/DIGESTER-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Tripodi resolved DIGESTER-163.
-
Resolution: Fixed
Assignee: Simone Tripodi
Thanks Torsten for the feedbacks and thanks Thomas for having a look at it!
I mark the issue as resolved and Torsten has to feel free to reopen it if
needed.
ConcurrentModificationException creating a new Digester via
loaderInstance.newDigester()
Key: DIGESTER-163
URL: https://issues.apache.org/jira/browse/DIGESTER-163
Project: Commons Digester
Issue Type: Bug
Affects Versions: 3.2
Environment: Linux, JDK 6
Reporter: Torsten Krah
Assignee: Simone Tripodi
Attachments: 163-2.patch, 163.patch, Digester163TestCase.java,
cli-mvn-test-withfix.txt, stack-afterfix.txt, stack-mvn.txt, stack-next.txt,
stack-next2.txt
I am gettig a ConcurrentModificationException when trying to create new
Digester instance from a configured loader:
Trace is:
{code}
java.util.ConcurrentModificationException: null
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:761)
~[na:1.6.0_27]
at java.util.LinkedList$ListItr.next(LinkedList.java:696) ~[na:1.6.0_27]
at
org.apache.commons.digester3.binder.FromBinderRuleSet.addRuleInstances(FromBinderRuleSet.java:130)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.addRules(DigesterLoader.java:581)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:568)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:516)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:475)
~[commons-digester3-3.2.jar:3.2]
at
org.apache.commons.digester3.binder.DigesterLoader.newDigester(DigesterLoader.java:462)
~[commons-digester3-3.2.jar:3.2]
{code}
The binder documentation (employee servlet) and the mailing list did confirm
to me, that the loader should be safe to be shared, so this should not happen.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CODEC-130) Base64InputStream.skip skips underlying stream, not output
[
https://issues.apache.org/jira/browse/CODEC-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved CODEC-130.
---
Resolution: Fixed
In SVN.
Base64InputStream.skip skips underlying stream, not output
--
Key: CODEC-130
URL: https://issues.apache.org/jira/browse/CODEC-130
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.5
Reporter: James Pickering
Priority: Minor
Fix For: 1.7
Attachments: base64snippet.java
Base64InputStream.skip() skips within underlying stream, leading to
unexpected behaviour.
The following code will reproduce the issue:
@Test
public void testSkip() throws Throwable {
InputStream ins =
new
ByteArrayInputStream(.getBytes(ISO-8859-1));//should decode to
{0, 0, 0, 255, 255, 255}
Base64InputStream instance = new Base64InputStream(ins);
assertEquals(3L, instance.skip(3L)); //should skip 3 decoded characters,
or 4 encoded characters
assertEquals(255, instance.read()); //Currently returns 3, as it is
decoding A/, not //
}
The following code, if added to Base64InputStream, or (BaseNCodecInputStream
in the dev build) would resolve the issue:
@Override
public long skip(long n) throws IOException {
//delegate to read()
long bytesRead = 0;
while ((bytesRead n) (read() != -1)) {
bytesRead++;
}
return bytesRead;
}
More efficient code may be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-67) Possibility to set DPI for PNG
[
https://issues.apache.org/jira/browse/SANSELAN-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-67.
--
Resolution: Fixed
Fix Version/s: 1.0
Fixed by commit 1301892, resolving fixed.
Possibility to set DPI for PNG
--
Key: SANSELAN-67
URL: https://issues.apache.org/jira/browse/SANSELAN-67
Project: Commons Sanselan
Issue Type: Improvement
Components: Format: PNG
Affects Versions: 0.97, 1.0, 1.1, 1.x
Environment: Any
Reporter: VVD
Fix For: 1.0
How I can to set DPI for PNG image?
{code}
File inImgFile = new File(in.png);
File outImgFile = new File(out.png);
BufferedImage image = Sanselan.getBufferedImage(inImgFile);
// ImageInfo imageinfo = Sanselan.getImageInfo(inImgFile);
// imageinfo.getPhysicalHeightDpi(): returned 300
// imageinfo.getPhysicalWidthDpi(): returned 300
// Sanselan.getMetadata(inImgFile): returned null
ImageFormat format = ImageFormat.IMAGE_FORMAT_PNG;
Sanselan.writeImage(image, outImgFile, format, params);
// imageinfo = Sanselan.getImageInfo(outImgFile);
// imageinfo.getPhysicalHeightDpi(): returned -1
// imageinfo.getPhysicalWidthDpi(): returned -1
{code}
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] [Resolved] (SANSELAN-66) Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
[
https://issues.apache.org/jira/browse/SANSELAN-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-66.
--
Resolution: Fixed
Fix Version/s: 1.0
Patch is committed, resolving fixed.
Thank you for your contribution!
Sanselan can't render 48 bit pixel Tiff image (bit per samples ={16,16,16})
---
Key: SANSELAN-66
URL: https://issues.apache.org/jira/browse/SANSELAN-66
Project: Commons Sanselan
Issue Type: Bug
Components: Format: TIFF
Environment: Windows 7 64 bit
Reporter: Piyush Kapoor
Labels: patch
Fix For: 1.0
Attachments: BinaryFileParser.java.patch, tiffimage.patch
Original Estimate: 1h
Remaining Estimate: 1h
We have a very large Tiff image tha uses 16 bits for each pixel (bits per
sample total = 48) . The class
org.apache.commons.sanselan.common.Bitinputstream didn't have support for
Endianness of the Tiff format . I added that support in the patch and image
worked absolutely fine.
The image is very large . If you want i can upload it (140 mb).Otherwise here
is the patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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:all-tabpanel ] Sebb resolved CSV-61. - Resolution: Won't Fix 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] [Resolved] (CSV-67) UnicodeUnescapeReader should not be applied before parsing
[ https://issues.apache.org/jira/browse/CSV-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-67. - Resolution: Fixed 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] [Resolved] (CONFIGURATION-487) DataConfiguration.get() cannot handle a trivial conversion
[
https://issues.apache.org/jira/browse/CONFIGURATION-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-487.
Resolution: Fixed
Fix Version/s: 1.9
Fixed in subversion in revision 1301990.
DataConfiguration.get() cannot handle a trivial conversion
--
Key: CONFIGURATION-487
URL: https://issues.apache.org/jira/browse/CONFIGURATION-487
Project: Commons Configuration
Issue Type: Bug
Components: Type conversion
Affects Versions: 1.8
Reporter: Oliver Heger
Assignee: Oliver Heger
Fix For: 1.9
A call to {{DataConfiguration.get()}} eventually invokes the
{{PropertyConverter.to()}} method. Here a number of supported data types are
checked and corresponding conversions are done.
However, the case that the value does not need to be converted at all -
because it already has the expected type - is not taken into account. This is
especially a problem for string values: there is not conversion to string, so
the get() method fails even if the value is already a string.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-491) XMLConfiguration.XMLBuilderVisitor.listDelimiter initial value is always overridden
[ https://issues.apache.org/jira/browse/CONFIGURATION-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CONFIGURATION-491. Resolution: Fixed XMLConfiguration.XMLBuilderVisitor.listDelimiter initial value is always overridden --- Key: CONFIGURATION-491 URL: https://issues.apache.org/jira/browse/CONFIGURATION-491 Project: Commons Configuration Issue Type: Bug Reporter: Sebb The private class field XMLConfiguration.XMLBuilderVisitor.listDelimiter is initialised to AbstractConfiguration.getDefaultListDelimiter(); However, the only constructor overwrites the field. So the default init could be removed, and the field could be made final. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-477) PropertyListConfiguration cannot deal with comments
[
https://issues.apache.org/jira/browse/CONFIGURATION-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-477.
Resolution: Fixed
Fix Version/s: 1.9
Fixed in subversion in revision 1301722.
PropertyListConfiguration cannot deal with comments
---
Key: CONFIGURATION-477
URL: https://issues.apache.org/jira/browse/CONFIGURATION-477
Project: Commons Configuration
Issue Type: Bug
Components: Format
Affects Versions: 1.7
Reporter: Oliver Heger
Assignee: Oliver Heger
Fix For: 1.9
According to http://code.google.com/p/networkpx/wiki/PlistSpec a plist file
can contain C-style comments. These are currently not recognized by
{{PropertyListConfiguration}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (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:all-tabpanel ] Sebb resolved IO-305. - Resolution: Fixed Fix Version/s: 2.2 Added methods for bytes and chars based on copyLarge. Dropped buffer size parameter as not essential. 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] [Resolved] (SANDBOX-401) [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable
[ https://issues.apache.org/jira/browse/SANDBOX-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-401. Resolution: Fixed Assignee: Simone Tripodi patch applied on [r1300916|http://svn.apache.org/viewvc?rev=1300916view=rev], thanks [BeanUtils2] Performance improvement: store hash code of AccessibleObjectDescriptor as member variable -- Key: SANDBOX-401 URL: https://issues.apache.org/jira/browse/SANDBOX-401 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-401.txt, SANDBOX-401v2.txt As discussed on the ML, we should store the hash code of AccessibleObjectDescriptor in a private member variable after it has been computed the first time. The computed value can be returned on subsequent invocations. Since AccessibleObjectDescriptor is immutable (all of its fields are final) the hash code can never change, once an AccessibleObjectDescriptor has been initialized. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-369) Move logic for type compatibility checking from AccessibleObjectsRegistry to TypeUtils
[ https://issues.apache.org/jira/browse/SANDBOX-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-369. Resolution: Fixed Assignee: Simone Tripodi patch revised and applied, see r1300940 please pay attention on keeping out trailing spaces and empty lines ;) Move logic for type compatibility checking from AccessibleObjectsRegistry to TypeUtils -- Key: SANDBOX-369 URL: https://issues.apache.org/jira/browse/SANDBOX-369 Project: Commons Sandbox Issue Type: Improvement Components: BeanUtils2 Affects Versions: Nightly Builds Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-369.txt As discussed on the ML, the logic for checking if two arrays of class objects are compatible, should be extracted from AccessibleObjectsRegistry.ConstructorsRegistry.resolve(...) and AccessibleObjectsRegistry.MethodsRegistry.resolve(...) to TypeUtils. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-398) [BeanUtils2] Implement unit tests for BeanUtils.onClassName()
[ https://issues.apache.org/jira/browse/SANDBOX-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-398. Resolution: Fixed Assignee: Simone Tripodi charming patch, applied without any problem, see [r1300947|http://svn.apache.org/viewvc?rev=1300947view=rev] [BeanUtils2] Implement unit tests for BeanUtils.onClassName() - Key: SANDBOX-398 URL: https://issues.apache.org/jira/browse/SANDBOX-398 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-398.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-403) [BeanUtils2] Refactor Unit tests for better readability
[ https://issues.apache.org/jira/browse/SANDBOX-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved SANDBOX-403. Resolution: Fixed Assignee: Simone Tripodi patch applied, see [r1300952|http://svn.apache.org/viewvc?rev=1300952view=rev], thanks. please don't reorganize imports using wildcards, nobody uses it here, TIA. [BeanUtils2] Refactor Unit tests for better readability --- Key: SANDBOX-403 URL: https://issues.apache.org/jira/browse/SANDBOX-403 Project: Commons Sandbox Issue Type: Sub-task Components: BeanUtils2 Reporter: Benedikt Ritter Assignee: Simone Tripodi Attachments: SANDBOX-403.txt, SANDBOX-403v2.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-59) Is CharBuffer really needed, now that StringBuilder is available?
[ https://issues.apache.org/jira/browse/CSV-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-59. --- Resolution: Fixed Is CharBuffer really needed, now that StringBuilder is available? - Key: CSV-59 URL: https://issues.apache.org/jira/browse/CSV-59 Project: Commons CSV Issue Type: Improvement Reporter: Sebb Fix For: 1.0 Seems to me that StringBuilder could be used instead of CharBuffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-60) CSVParser.iterator().remove() should throw throw new UnsupportedOperationException()
[ https://issues.apache.org/jira/browse/CSV-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-60. - Resolution: Fixed CSVParser.iterator().remove() should throw throw new UnsupportedOperationException() Key: CSV-60 URL: https://issues.apache.org/jira/browse/CSV-60 Project: Commons CSV Issue Type: Bug Reporter: Sebb The remove() method currently does nothing; it should throw new UnsupportedOperationException() for consistency with other read-only iterators. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-62) Should CSVFormat.lineSeparator default to \r\n even on Unix systems?
[ https://issues.apache.org/jira/browse/CSV-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-62. --- Resolution: Won't Fix Should CSVFormat.lineSeparator default to \r\n even on Unix systems? -- Key: CSV-62 URL: https://issues.apache.org/jira/browse/CSV-62 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVFormat lineSeparator field defaults to \r\n which is OK for Windows, but probably not suitable for Un*x systems. It should probably default to the local 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] [Resolved] (CSV-44) Merging OpenCSV
[ https://issues.apache.org/jira/browse/CSV-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-44. --- Resolution: Later Merging OpenCSV Key: CSV-44 URL: https://issues.apache.org/jira/browse/CSV-44 Project: Commons CSV Issue Type: Improvement Reporter: Alexander Chmyr Attachments: merged-opencsv-diff.tar.gz Add header support and bean instantiation for CSV row. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-306) ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0
[ https://issues.apache.org/jira/browse/IO-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved IO-306. - Resolution: Fixed ReaderInputStream#read(byte[] b, int off, int len) should always return 0 for length == 0 - Key: IO-306 URL: https://issues.apache.org/jira/browse/IO-306 Project: Commons IO Issue Type: Bug Affects Versions: 2.1 Reporter: Sebb Fix For: 2.2 The method read(byte[] b, int off, int len) should always return 0 if the requested length == 0, even if the stream is empty or at EOF, as that is how the overridden java.io.InputStream method is documented to behave. -- 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
