[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] (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] (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] (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] (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-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] (DIGESTER-164) RulesBase performance optimization
[ https://issues.apache.org/jira/browse/DIGESTER-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi resolved DIGESTER-164. - Resolution: Fixed Fix Version/s: 3.3 Assignee: Simone Tripodi Patch applied at [r1328103|http://svn.apache.org/viewvc?rev=1328103&view=rev], thanks for contributing Frank! > RulesBase performance optimization > -- > > Key: DIGESTER-164 > URL: https://issues.apache.org/jira/browse/DIGESTER-164 > Project: Commons Digester > Issue Type: Improvement >Affects Versions: 3.2 >Reporter: Frank David Martinez >Assignee: Simone Tripodi >Priority: Minor > Labels: patch > Fix For: 3.3 > > Attachments: rulesbase.patch, rulesbase2.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > RulesBase iterates over all patterns looking for the longest key. It could be > optimized with a separate cache of wildcards. -- 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=1328084&view=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] (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] (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] (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] (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] (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-319) FileUtils.sizeOfDirectory follows symbolic links.
[
https://issues.apache.org/jira/browse/IO-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved IO-319.
Resolution: Fixed
Fix Version/s: 2.4
In SVN.
> FileUtils.sizeOfDirectory follows symbolic links.
> -
>
> Key: IO-319
> URL: https://issues.apache.org/jira/browse/IO-319
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Ravi Prakash
>Priority: Critical
> Fix For: 2.4
>
> Attachments: commons-io-319.patch, commons-io-319.patch
>
>
> First of all Thanks tons Apache Commons folks for all the amazing work! :) My
> first JIRA. Yayyy. I contributed B-)
> A symbolic link may create a cycle and so sizeOfDirectory crashes with an
> IllegalArgumentException. e.g.
> {noformat}
> $ tree test
> test
> ├── file
> └── ravi
> ├── cycle -> ../../test
> └── file
> {noformat}
> causes FileUtils.sizeOfDirectory to crash like so
> {noformat}
> java TestJAVA
> Exception in thread "main" java.lang.IllegalArgumentException:
> /test/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle
> does not exist
> at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2053)
> at
> org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
> at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
> at
> org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
> at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
> at
> org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
> at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
> at
> org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
> {noformat}
> We faced the same issue in Hadoop :(. Checkout
> https://issues.apache.org/jira/browse/HADOOP-6963 for our solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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] (NET-458) MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/NET-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-458.
--
Resolution: Fixed
Thanks for the report. Fixed in SVN, and a new SNAPSHOT has been uploaded to
the ASF snapshots repo [1].
[1] http://repository.apache.org/snapshots/
> MVSFTPEntryParser.parseSimpleEntry - ArrayIndexOutOfBoundsException
> ---
>
> Key: NET-458
> URL: https://issues.apache.org/jira/browse/NET-458
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: zOS
>Reporter: Denis Molony
>
> Line 360 in MVSFTPEntryParser.parseSimpleEntry :
> String name = entry.split(" ")[0];
> gives an ArrayIndexOutOfBoundsException: 0
> It appears to be caused by a partitioned dataset whose members only contain
> names. No other details (creation date, file type etc).
> This is the method, if it helps:
> {code}
> private boolean parseSimpleEntry(FTPFile file, String entry) {
> if (entry != null && entry.length() > 0) {
> file.setRawListing(entry);
> String name = entry.split(" ")[0]; // <--- error occurs here
> file.setName(name);
> file.setType(FTPFile.FILE_TYPE);
> return true;
> }
> return false;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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: > 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] (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] (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] (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] (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] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
[
https://issues.apache.org/jira/browse/SANSELAN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damjan Jovanovic resolved SANSELAN-69.
--
Resolution: Fixed
Fix Version/s: 1.0
Applied, resolving fixed. Thank you for your patch!
> Incorrect reading Physical Width/Height Inch from PNG files
> ---
>
> Key: SANSELAN-69
> URL: https://issues.apache.org/jira/browse/SANSELAN-69
> Project: Commons Sanselan
> Issue Type: Bug
> Components: Format: PNG
>Affects Versions: 0.97, 1.0, 1.1, 1.x
>Reporter: VVD
> Labels: patch
> Fix For: 1.0
>
> Attachments: sanselan-png-dpi.diff
>
>
> Width: 3509
> Physical Width Dpi: 300
> Physical Width Inch: 1052697.9
> Height: 2481
> Physical Height Dpi: 300
> Physical Height Inch: 744298.5
> {code}
> PngImageParser.java (620):
> PhysicalWidthInch = (float) ((double) Width
> -* (double) pngChunkpHYs.PixelsPerUnitXAxis *
> meters_per_inch);
> +/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
> meters_per_inch));
> PngImageParser.java (625):
> PhysicalHeightInch = (float) ((double) Height
> -* (double) pngChunkpHYs.PixelsPerUnitYAxis *
> meters_per_inch);
> +/ ((double) pngChunkpHYs.PixelsPerUnitYAxis *
> meters_per_inch));
> {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
--
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] (POOL-131) Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log errors about passivation/destroying
[ https://issues.apache.org/jira/browse/POOL-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved POOL-131. -- Resolution: Fixed This has been fixed for POOL2 via exposing the swallowed exceptions via a getter (accessible via JMX) and JMX notifications. > Make org.apache.commons.pool.impl.GenericObjectPool.returnObject(Object) log > errors about passivation/destroying > > > Key: POOL-131 > URL: https://issues.apache.org/jira/browse/POOL-131 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 1.4 > Environment: Spring Framework JTA transaction Manager + jBossTS + DBCP >Reporter: Mauro Molinari > Fix For: 2.0 > > > In our environment it happens the following. Suppose our code has a bug and > does not release a connection previously obtained from DBCP. > Suppose a JTA transaction is in progress when this happens. > When trying to commit this transaction, Spring has a guard that realizes that > the owner of that transaction is in some way "dead", so it tries to close the > connection before committing (I think this is a problem, however, let's go > on). Closing the connection makes DBCP/Pool call returnObject on the > GenericObjectPool, then addObjectToPool and, at last, passivateObject. As the > connection is neither in auto-commit mode nor read-only, passivateObject > issues a rollback on the connection but then jBossTS throws a SQLException > saying that it is not allowed to issue a rollback on an underlying connection > while a higher level JTA transaction is in progress. This exception is caught > by returnObject and it is completely lost, because returnObject does not log > it, nor it forwards it upward. > The final result is that: > - the connection is not given back to the Pool, because of the exception > - however, the physical underlying connection to the DBMS remains open > => we have a connection leak, without any proof of it (no exceptions are > logged in any way) > To get to these results I had to carefully debug my code. It would have been > very easier if Pool logged exceptions thrown during passivation. -- 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] (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-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 BoundedCollection to decorate, must not
> be null
> * @return a new unmodifiable bounded collection
> * @throws IllegalArgumentException if bag is null
> */
> public static BoundedCollection
> unmodifiableBoundedCollection(BoundedCollection 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] (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-391) Inconsistent Javadoc comment and code for toProperties(final Map) 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 Map) 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 Properties toProperties(final Map 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-400) Inconsistent Javadoc comment and code in addIgnoreNull(Collection, 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(Collection, 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 boolean addIgnoreNull(Collection 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-389) Inconsistent Javadoc comment and code for mapTransformer(Map) 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 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 Transformer mapTransformer(Map 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-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 prototype factory
>* @throws IllegalArgumentException if the prototype is null
>* @throws IllegalArgumentException if the prototype cannot be
> cloned
>*/
> public static Factory prototypeFactory(T prototype) {
> return PrototypeFactory.prototypeFactory(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] (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] (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(Collection c) * protected List 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] (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 deserialize(InputStream inputStream)}}
> Old: {{public static Object deserialize(byte[] objectData)}}
> New: {{public static 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] (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] (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] (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] (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] (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] (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] (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 Map objectTypesConditions;
>
> public DistrictConditions() {
> this.objectTypesConditions = new HashMap 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 Collection getObjectConditions(Collection
> objectTypes) {
> ArrayList objectConditions = new
> ArrayList();
> for (String objectType: objectTypes) {
> DistrictObjectTypeConditions objectTypeConditions =
> this.objectTypesConditions.get(objectType);
> if (objectTypeConditions!=null) {
>
> objectConditions.addAll(objectTypeConditions.getObjectConditions());
> }
&g
[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-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] (MATH-767) Unbalanced 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 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 i last elements of the array. For example,
> {code}
> this should become:
> {code}
> * Discards the i last elements of the array. For example,
> {code}
> as then the ... 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] (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] (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] (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] (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-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-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-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);
> Iterator it = parser.iterator();
> // read the header
> String[] header = it.next();
> // build a name to index mapping
> Map 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-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-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] (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] (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,
> (Collection) 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] (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] (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] (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=revision&revision=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] (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] (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-755) On the contract of FieldElement.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 FieldElement.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 {{FieldElement.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] (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] (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 []) {
> ArrayList listOfFTPFiles = new ArrayList();
> 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] (MATH-761) Improve encapsulation of data in the nested classes of SymmLQ
[
https://issues.apache.org/jira/browse/MATH-761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-761.
Resolution: Fixed
Fix Version/s: 3.1
> Improve encapsulation of data in the nested classes of SymmLQ
> -
>
> Key: MATH-761
> URL: https://issues.apache.org/jira/browse/MATH-761
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: linear
> Fix For: 3.1
>
>
> In order to limit object creation, the current implementation of the
> {{SymmLQ}} solver makes heavy use of references accross nested classes in
> {{SymmLQ}}. This makes the code difficult to read, and should be modified,
> keeping the public API.
--
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] (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] (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-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-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-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-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] (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] (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-447) Commons-net version 2.0 jar unable to download files of time stamp 29th February.
[ https://issues.apache.org/jira/browse/NET-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-447. -- Resolution: Cannot Reproduce No response, assuming fixed by current release > Commons-net version 2.0 jar unable to download files of time stamp 29th > February. > -- > > Key: NET-447 > URL: https://issues.apache.org/jira/browse/NET-447 > Project: Commons Net > Issue Type: Bug > Components: FTP >Affects Versions: 2.0 > Environment: Windows Server 2003. >Reporter: Jeevesh Mishra > Labels: patch > Fix For: 2.0 > > Original Estimate: 1,304h > Remaining Estimate: 1,304h > > When FTP Client of commons-net.jar (version 2.0) tries to get the list of > files on FTP server then for the files of time stamp date 29th Feb 2012 it > returns null value and in turn throws Null pointer Exception. > Because the files are read in date viz sequence, thus it reads the file names > correctly till 28th Feb but as soon as it gets a file of time-stamp date 29th > it throws Null Pointer Exception and all the files after that are not read. > Also its been mentioned in the case mentioned at following url that this > issue has been resolved in version 1.5 : > https://issues.apache.org/jira/browse/NET-188 > Thus ideally such solution would have been included in all later versions. We > would require a patch to resolve this. > Also for your information we are using Wicket frame work. Do you forsee any > Jar conflict with commons-net version 2.0 in such scenario. > We are also attaching the Exceptions trace as follows: > ERROR [01 Mar 2012 13:37:33] > com.nordea.npdb.datafeed.sp.timertasks.DataFeedSpUsStockReportFtpImpl.execute(DataFeedSpUsStockReportFtpImpl.java:48) > : Timer_DataFeedSpUsStockReportFtp [FAILED] > java.lang.NullPointerException > at > com.nordea.npdb.bl.facade.DataFeedServiceImpl.saveFtpFetcherFiles(DataFeedServiceImpl.java:108)[NPDB-core-0-SNAPSHOT.jar:] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method)[:1.6.0_24] > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)[:1.6.0_24] > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[:1.6.0_24] > at java.lang.reflect.Method.invoke(Method.java:597)[:1.6.0_24] > at > org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:309)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:110)[spring-tx-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)[spring-aop-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at $Proxy105.saveFtpFetcherFiles(Unknown Source)[:] > at > com.nordea.npdb.datafeed.sp.timertasks.DataFeedSpUsStockReportFtpImpl.execute(DataFeedSpUsStockReportFtpImpl.java:32)[NPDB-core-0-SNAPSHOT.jar:] > at > com.nordea.npdb.infrastructure.batch.OldBatchJob.execute(OldBatchJob.java:12)[NPDB-core-0-SNAPSHOT.jar:] > at > org.springframework.batch.core.step.tasklet.TaskletStep$ChunkTransactionCallback.doInTransaction(TaskletStep.java:386)[spring-batch-core-2.1.7.RELEASE.jar:] > at > org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:130)[spring-tx-3.0.3.RELEASE.jar:3.0.3.RELEASE] > at > org.springframework.batch.core.step.tasklet.TaskletStep$2.doInChunkContext(TaskletStep.java:264)[spring-batch-core-2.1.7.RELEASE.jar:] > at > org.springframework.batch.core.scope.context.StepContextRepeatCallback.doInIteration(StepContextRepeatCallback.java:76)[spring-batch-core-2.1.7.RELEASE.jar:] > at > org.springframework.batch.repeat.support.RepeatTemplate.getNextResult(RepeatTemplate.java:367)[spring-batch-infrastructure-2.1.7.RELEASE.jar:] > at > org.springframework.batch.repeat.support.RepeatTemplate.executeInternal(RepeatTempla
[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] (MATH-770) SymmLQ not tested in SymmLQTest
[
https://issues.apache.org/jira/browse/MATH-770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sébastien Brisard resolved MATH-770.
Resolution: Fixed
There is a follow-up to this ticket in MATH-771.
> SymmLQ not tested in SymmLQTest
> ---
>
> Key: MATH-770
> URL: https://issues.apache.org/jira/browse/MATH-770
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.0, 3.1
>Reporter: Sébastien Brisard
>Assignee: Sébastien Brisard
> Labels: linear, solver
> Fix For: 3.1
>
>
> In {{SymmLQTest}}, two test actually create instances of
> {{ConjugateGradient}} instead of {{SymmLQ}}. These tests are
> * {{testUnpreconditionedNormOfResidual()}}
> * {{testPreconditionedNormOfResidual()}}.
--
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] (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-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-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] (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] (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-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] (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] (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) {
>
[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());
> Enumeration 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);
>
[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] (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 true is comments are supported, false 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] (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] (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] (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-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] (NET-454) paths with spaces result in inaccurate file information
[
https://issues.apache.org/jira/browse/NET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-454.
--
Resolution: Not A Problem
Not a problem in NET; JIRA is not a support forum.
If you want further advice, please subscribe to the Commons User mailing list
and ask there.
> paths with spaces result in inaccurate file information
> ---
>
> Key: NET-454
> URL: https://issues.apache.org/jira/browse/NET-454
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 3.0.1, 3.1
> Environment: Mac OS X 10.7.3, FTP server is Pure-FTPd on Linux CentOS
> 5
>Reporter: Shane Witbeck
> Labels: ftp, path
> Attachments: FTPClientTest.java
>
>
> Calling FTPClient.listFiles(String pathname) results in an inaccurate file
> list being returned. The following test illustrates the issue:
> {code:java}
> @Test
> public void remoteListFilesFailure() throws Exception {
> FTPClient client = new FTPClient();
> client.connect(REMOTE_SERVER);
> client.enterLocalPassiveMode();
> client.login(REMOTE_USERNAME, REMOTE_PASSWORD);
> client.setFileType(FTP.BINARY_FILE_TYPE);
> int reply = client.getReplyCode();
> if (!FTPReply.isPositiveCompletion(reply)) {
> client.disconnect();
> log.error("FTP server refused connection. reply=" + reply);
> }
> FTPFile[] rootFiles =
> client.listFiles("78/1295213/0/476312ca9c653ffc6cc8fb6e1649dae6/ModComp PO #
> 1054.pdf");
> Assert.assertEquals(1, rootFiles.length); // <-- fails with
> rootFiles.length = 0
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [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 rn 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] (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] (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] (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] (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] (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
