[jira] [Created] (OGNL-48) Converting string values to boolean
Converting string values to boolean --- Key: OGNL-48 URL: https://issues.apache.org/jira/browse/OGNL-48 Project: Commons OGNL Issue Type: Bug Reporter: Pål Oliver Kristiansen Maybe I misunderstand how to use OGNL, but this seems a bit wierd to me (test case below) DefaultTypeConverter converter = new DefaultTypeConverter(); Object o = converter.convertValue(null, false, Boolean.class); assertEquals(false, o); // fails. Object is Boolean == true -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-459) FTPClient.storeFile never returns in active mode if data channel cannot be established
FTPClient.storeFile never returns in active mode if data channel cannot be established -- Key: NET-459 URL: https://issues.apache.org/jira/browse/NET-459 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.1, 3.0.1 Reporter: Jaroslav Chmurny FTPClient.storeFile(String, InputStream) method is used to upload a file to the FTP server. Before the upload, active mode is chosen via the FTPClient.enterLocalActiveMode() method. However, the FTP server is not able to establish the data channel to the FTP client (for instance because of firewall). The storeFile method blocks and never returns. When I capture the network traffic with Wireshark, I see that there are two responses to the STOR command: the first one indicates that the data channel is going to be established, the second one indicates that the FTP server cannot establish the data channel. However, the storeFile method remains blocked forever, even if I play around with the various timeouts (setSoTimeout, setDefaultTimeout, setControlKeepAliveTimeout, setControlKeepAliveReplyTimeout). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CHAIN-68) SNAPSHOT tomcat plugin breaks the build
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
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] [Created] (VFS-411) [SFTP] Update Jsch to version 0.1.47
[SFTP] Update Jsch to version 0.1.47 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] [Created] (SANSELAN-73) JpegImageMetada fails if exif is null
JpegImageMetada fails if exif is null -- Key: SANSELAN-73 URL: https://issues.apache.org/jira/browse/SANSELAN-73 Project: Commons Sanselan Issue Type: Bug Reporter: Piyush Kapoor if exif field is null in jpegimagemetadata.java fails with Np . Added the null check. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-74) Tiffreader fails if rows per strip and imageheight bothe are absent
Tiffreader fails if rows per strip and imageheight bothe are absent Key: SANSELAN-74 URL: https://issues.apache.org/jira/browse/SANSELAN-74 Project: Commons Sanselan Issue Type: Bug Reporter: Piyush Kapoor Priority: Minor If rowsperstrip is not present in Tiff files , we take imageHeigth value as rows per strip value. Currently is imageheight is not present then Np occurs , Added some checks to safely run the process . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-382) Could not set flag accessToUnderlyingConnectionAllowed in context.xml for DriverAdapterCPDS/PerUserPoolDataSource
Could not set flag accessToUnderlyingConnectionAllowed in context.xml for
DriverAdapterCPDS/PerUserPoolDataSource
-
Key: DBCP-382
URL: https://issues.apache.org/jira/browse/DBCP-382
Project: Commons Dbcp
Issue Type: Bug
Affects Versions: 1.3
Environment: Apache Tomcat 6.0.32 / DBCP 1.3
Reporter: Stefan Rempfer
Could not set flag accessToUnderlyingConnectionAllowed in context.xml for
DriverAdapterCPDS/PerUserPoolDataSource because the property is not considered
from the factory.
A possible solution is to add following lines to class DriverAdapterCPDS on
the end of method getObjectInstance
{code}
ra = ref.get(accessToUnderlyingConnectionAllowed);
if (ra != null ra.getContent() != null) {
setAccessToUnderlyingConnectionAllowed(Boolean.valueOf(ra.getContent().toString()).booleanValue());
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-327) Add byteCountToDisplaySize(BigInteger)
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] [Created] (DIGESTER-164) RulesBase performance optimization
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 Priority: Minor Attachments: rulesbase.patch 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] [Created] (COMPRESS-186) The example should be much easier to read
The example should be much easier to read - Key: COMPRESS-186 URL: https://issues.apache.org/jira/browse/COMPRESS-186 Project: Commons Compress Issue Type: Improvement Components: Documentation Reporter: Yang Hua Jie The example should be much easier to read。 I read it for a long time and copy the code to my favorite IDE. But no lucky, I can not make it work. There should have a quick start page, and the page should be very easy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-324) Add missing Charset sister APIs to method that take a String charset name.
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] [Created] (IO-325) Add IOUtils.toByteArray methods to work with URL and URI
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] [Created] (IO-326) Add or change FileUtils.sizeOfDirectory API that does not overflow
Add or change FileUtils.sizeOfDirectory API that does not overflow -- Key: IO-326 URL: https://issues.apache.org/jira/browse/IO-326 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.3 Reporter: Gary D. Gregory FileUtils.sizeOfDirectory will return a negative number when the size count goes past Long.MAX_VALUE. Counting with a BigInteger will solve this issue. Options: - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. This will obviously break BC. - Create a new API to return a BigInteger. What would this new API be called? -- sizeOfDirectoryAsBigInteger -- bigIntegerSizeOfDirectory -- largeSizeOfDirectory -- ...? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-494) tool or script to setup a website with apache?
tool or script to setup a website with apache? -- Key: CONFIGURATION-494 URL: https://issues.apache.org/jira/browse/CONFIGURATION-494 Project: Commons Configuration Issue Type: Wish Affects Versions: 1.4 Environment: (Debian)Linux and/or Windows vista / 7 Reporter: André Verwijs feature request: would it be possible to make some kind of tool or script to setup a website with apache? a tool/script that does: - all the work for you - run checks to see if everything runs correctly - install additional packages required for the website (linux, with apt) - ask questions to setup a website the way you want. (more idea's are welcome) with something like this its: - easy - everyone can use it - technical knowledge with apache not required - less chance to have mistakes or typos witch make the website fail to run please give this idea a serious thought, it would be a breakthrough... Thank you André -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-380) DelegatingConnection isWrapperFor dies on older JDBC drivers
DelegatingConnection isWrapperFor dies on older JDBC drivers Key: DBCP-380 URL: https://issues.apache.org/jira/browse/DBCP-380 Project: Commons Dbcp Issue Type: Bug Reporter: Balazs Zsoldos The isWrapperFor function simply calls towards to the delegated connection iswrappedfor function instead of checking the result first by hand like in the unwrap function. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-493) Incorrect backslash handling in windows environment variable
Incorrect backslash handling in windows environment variable
Key: CONFIGURATION-493
URL: https://issues.apache.org/jira/browse/CONFIGURATION-493
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.8
Reporter: Patrick Vanhuyse
Fix For: 1.7
Windows environment variable :
DFSROOT=\\DFSROOT\BEG
Properties file :
Personnel.jdbc.url = jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=${DFSROOT}/databases/personnel.mdb
Value returned...
...using 1.8 (incorrect) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\DFSROOT\BEG/databases/personnel.mdb
...using 1.7 (correct) :
jdbc:odbc:Driver={Microsoft Access Driver
(*.mdb)};DBQ=\\DFSROOT\BEG/databases/personnel.mdb
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-249) Ref: HADOOP-8273 Update url for commons daemon ppc64 binary tarball
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 Fix For: 1.0.2 The workaround is to obtain the src. zip file from this URL: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip and to build the above tar file for PPC64 on an IBM Power system. Details: 1. Download this file: http://archive.apache.org/dist/commons/daemon/source/commons-daemon-1.0.2-native-src.zip or the appropriate version for the build. 2. unzip the above downloaded file in a directory called /home/hadoop/commons (or any directory of your choice) 3. cd /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix 4. Run ./configure 5. Build the jsvc binary by typing make 6. Copy the jsvc binary thatr was just built to a new directory called /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 7.Copy the following text files home/hadoop/commons/commons-daemon-1.0.2-native-src directory to the /home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build directory - 1. LICENSE.txt 2. NOTICE.txt 3. RELEASE-NOTES.txt 8. cd to the directory home/hadoop/commons/commons-daemon-1.0.2-native-src/unix/build 9. Create the binary tar file for IBM Power by issuing the following command: tar -czvf commons-daemon-1.0.2-bin-linux-ppc64.tar.gz * 10. Copy the file to an appropriate directory where this can be accessed from the hadoop-common build: 11. For branch-1, edit the build.xml file on the build root to point to the binary tar file that was just built: property name=jsvc.location value=file:///home/hadoop/commons-daemon-1.0.2-bin-linux-ppc64.tar.gz/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-799) DateUtils#parseDate uses default locale instead of US (or trying both default locale and Locale.English)
DateUtils#parseDate uses default locale instead of US (or trying both default
locale and Locale.English)
Key: LANG-799
URL: https://issues.apache.org/jira/browse/LANG-799
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 3.1
Reporter: Oliver Kopp
Priority: Minor
Similar issue as https://issues.apache.org/jira/browse/HTTPCLIENT-471
Following line throws an ParseException on a German system:
d = DateUtils.parseDate(Wed, 09 Apr 2008 23:55:38 GMT, new String[] {EEE, dd
MMM HH:mm:ss zzz});
Reason: parseDate internally calls SimpleDateFormat without providing a locale.
This causes MMM to be interpreted using the system locale. If the system is
German, the date is trying to be interpreted as German date.
I see following solutions:
A) Always instantiate SimpleDateFormat with Locale.ENGLISH
B) Make two instances of SimpleDateFormat. One without providing a locale and
one with Locale.ENGLISH. Try two parsings
C) Make as many SimpleDateFormat instances as locales are availble iterate
over all instances at the parsing attempts.
D) provide an additional (optional) parameter to parseDate for providing a
Locale
I would prefer B) as this seems the best trade-off between internationalization
and local usage.
What do you think?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBUTILS-89) Add method in BeanProcessor to populate an existing bean
Add method in BeanProcessor to populate an existing bean - Key: DBUTILS-89 URL: https://issues.apache.org/jira/browse/DBUTILS-89 Project: Commons DbUtils Issue Type: New Feature Affects Versions: 1.4 Reporter: Adam Dyga I really miss a method in BeanProcessor that would populate an *existing* bean with data from ResultSet, eg: BeanProcessor.populateBean(ResultSet resultSet, Object bean) . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-405) Add ListUtils.select()
Add ListUtils.select() -- Key: COLLECTIONS-405 URL: https://issues.apache.org/jira/browse/COLLECTIONS-405 Project: Commons Collections Issue Type: Wish Affects Versions: 3.2.1 Reporter: Adam Dyga It would be nice to have ListUtils.select() method, similar to CollectionUtils.select(). The main difference would be the type returned (List vs Collection). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-409) Update Apache Commons Compress to 1.4 from 1.3
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] [Created] (MATH-779) ListPopulation Iterator allows you to remove chromosomes from the population.
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 Fix For: 3.1 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] [Created] (MATH-778) Dfp Dfp.multiply(int x) does not comply with the general contract FieldElement.multiply(int n)
Dfp Dfp.multiply(int x) does not comply with the general contract
FieldElement.multiply(int n)
--
Key: MATH-778
URL: https://issues.apache.org/jira/browse/MATH-778
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
Assignee: Sébastien Brisard
Fix For: 3.1
In class {{org.apache.commons.math3.Dfp}}, the method {{multiply(int n)}} is
limited to {{0 = n = }}. This is not consistent with the general contract
of {{FieldElement.multiply(int n)}}, where there should be no limitation on the
values of {{n}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-322) Add and use class Charsets
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] [Created] (FUNCTOR-15) Distribute tests from TestAlgorithms into several test classes under algorithm test package
Distribute tests from TestAlgorithms into several test classes under algorithm test package --- Key: FUNCTOR-15 URL: https://issues.apache.org/jira/browse/FUNCTOR-15 Project: Commons Functor Issue Type: Improvement Environment: debian lenny, eclipse indigo, sun java 6 Reporter: Bruno P. Kinoshita Priority: Minor Several algorithms are tested in o.a.c.functor.TestAlgorithms. This test class has too many methods, and this way it's harder to include new tests or manage existing ones. We will create separate test classes for each algorithm under o.a.c.functor.algorithm, and will include generics too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-71) Software field is missing in Exif TagConstant and Changing the order of reader.getbhyteorder in Tiffimage parser
Software field is missing in Exif TagConstant and Changing the order of reader.getbhyteorder 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 Some fields like Software has been removed while modifying ExifTagConstants . In tiffimagepareser line reader.getbytereater 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] [Created] (COLLECTIONS-404) Adding an implementation of Eugene Myers difference algorithm
Adding an implementation of Eugene Myers difference algorithm - Key: COLLECTIONS-404 URL: https://issues.apache.org/jira/browse/COLLECTIONS-404 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2.1 Environment: all Reporter: Luc Maisonobe Assignee: Luc Maisonobe Priority: Minor The difference algorithm aims at comparing two sequences of objects and return an edit script which represents how one can transform the first sequence into the second sequence. The script describes the various insert object, delete object and keep object commands. The script is guaranteed to be the shortest possible in terms of number of commands. From the script, one can either extract longest common sub-sequences (i.e. how similar the sequences are) or on the contrary the needed changes (i.e. how different the sequences are). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-72) Incorrect reading TIFF file
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
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] [Created] (IO-320) Add XmlStreamReader support for UTF-32
Add XmlStreamReader support for UTF-32 -- Key: IO-320 URL: https://issues.apache.org/jira/browse/IO-320 Project: Commons IO Issue Type: Improvement Components: Streams/Writers 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 Add XmlStreamReader support for UTF-32, UTF-32BE, UTF-32LE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-321) ByteOrderMark UTF_32LE is incorrect
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] [Created] (LANG-798) Use generics in SerializationUtils
Use generics in SerializationUtils
--
Key: LANG-798
URL: https://issues.apache.org/jira/browse/LANG-798
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500)
Maven home: C:\Java\apache-maven-3.0.4\bin\..
Java version: 1.6.0_31, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.6.0_31\jre
Default locale: en_US, platform encoding: Cp1252
OS name: windows 7, version: 6.1, arch: amd64, family: windows
Reporter: Gary D. Gregory
Fix For: 3.2
Use generics in SerializationUtils:
I'd like to propose the change below. This lets you get rid of type casts in
call sites. You'll still get a ClassCastException if you code it wrong of
course.
Old: {{public static Object deserialize(InputStream inputStream)}}
New: {{public static T T deserialize(InputStream inputStream)}}
Old: {{public static Object deserialize(byte[] objectData)}}
New: {{public static T T deserialize(byte[] objectData)}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-139) DigestUtils: additional utility methods
DigestUtils: additional utility methods --- Key: CODEC-139 URL: https://issues.apache.org/jira/browse/CODEC-139 Project: Commons Codec Issue Type: Improvement Reporter: Sebastien Dubois Priority: Trivial Attachments: DigestUtils-patch.txt I've slightly modified the DigestUtils class: - changed the visibility (protected -- public) of a few methods: these methods are generally useful if one just wants to get a MessageDigest instance for a given algorithm - added two 'updateDigest' methods which can be used to add more data to digest to the provided MessageDigest. The advantage for the one that accepts a String argument is that it keeps the same logic as the rest of DigestUtils (uses getBytesUtf8). The second one which accepts a byte array is there for consistency -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JXPATH-156) iteratePointers on relative context returns incorrect values for multidimensional arrays
iteratePointers on relative context returns incorrect values for
multidimensional arrays
Key: JXPATH-156
URL: https://issues.apache.org/jira/browse/JXPATH-156
Project: Commons JXPath
Issue Type: Bug
Reporter: Lukas Krejci
Let's have multidimensional array/collection as an input.
I would like to iterate through both inner and outer list. iteration through
the inner list is relative to iteration of outer list, so I'm using relative
context for that:
{code}
ListString array1 = Arrays.asList(what, is);
ListString array2 = Arrays.asList(wrong, ?);
ListListString strings = Arrays.asList(array1, array2);
JXPathContext context = JXPathContext.newContext(strings);
Iterator it = context.iteratePointers(.);
while (it.hasNext()) {
Pointer p = (Pointer) it.next();
JXPathContext context2 = context.getRelativeContext(p);
Iterator it2 = context2.iteratePointers(.);
while (it2.hasNext()) {
Pointer p2 = (Pointer) it2.next();
System.out.println(p2.getValue());
}
}
{code}
Unfortunately the inner iteration returns the inner collection instead of it's
items. So the output is following:
{code:xml}
[what, is]
[wrong, ?]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-403) Make AndPredicate, AnyPredicate etc. not final
Make AndPredicate, AnyPredicate etc. not final -- Key: COLLECTIONS-403 URL: https://issues.apache.org/jira/browse/COLLECTIONS-403 Project: Commons Collections Issue Type: Improvement Components: Collection Affects Versions: 3.2.1 Reporter: david cogen Priority: Minor If there is no good reason for these (and similar classes) to not be final, they would be much more useful to me if they were not final. I have a class that I wanted to have an is a relation to AnyPredicate, but, AnyPredicate being declared final, I cannot and instead have to design it with a has a relation to AnyPredicate, which for my purpose is much less clear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-777) More CrossoverPolicy's are needed.
More CrossoverPolicy's are needed. -- Key: MATH-777 URL: https://issues.apache.org/jira/browse/MATH-777 Project: Commons Math Issue Type: Improvement Affects Versions: 3.1 Reporter: Reid Hochstedler Attachments: Crossover.txt Currently only OnePointCrossover is available. There are no CrossoverPolicy's for Ordered Chromosomes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-775) In the ListPopulation constructor, the check for a negative populationLimit should occur first.
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 Fix For: 3.1 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] [Created] (MATH-776) Need range checks for elitismRate in ElitisticListPopulation constructors.
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 Fix For: 3.1 Attachments: MATH-776.txt 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] [Created] (EXEC-66) Speed up .DefaultExecutorTest.testExec_60()
Speed up .DefaultExecutorTest.testExec_60() Key: EXEC-66 URL: https://issues.apache.org/jira/browse/EXEC-66 Project: Commons Exec Issue Type: Improvement Reporter: Sebb Priority: Minor The test tries to use the watchdog to kill the process at the same time as it is exitting. This requires adjusting the watchdog timer so it eventually occurs after the process completes. Some hosts are slower to run the process, so the max retry count has to be quite large. It might be worth running the ping test a few times to determine the min/max elapsed times. The range of watchdog times could then be adjusted accordingly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-138) Complete FilterInputStream interface for BaseNCodecInputStream
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 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] [Created] (IO-318) Add Charset sister APIs to method that take a String charset name.
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 by the last type, String vs. Charset, you will get a compile error if you pass null to the API because the target method will be ambiguous, so you have to type cast to one type or the other. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-319) FileUtils.sizeOfDirectory follows symbolic links.
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
First of all Thanks tons Apache Commons folks for all the amazing work! :) My
first JIRA. Yayyy. I contributed B-)
A symbolic link may create a cycle and so sizeOfDirectory crashes with an
IllegalArgumentException. e.g.
{noformat}
$ tree test
test
├── file
└── ravi
├── cycle - ../../test
└── file
{noformat}
causes FileUtils.sizeOfDirectory to crash like so
{noformat}
java TestJAVA
Exception in thread main java.lang.IllegalArgumentException:
somepath/test/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle/ravi/cycle
does not exist
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2053)
at org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
at org.apache.commons.io.FileUtils.sizeOf(FileUtils.java:2057)
at org.apache.commons.io.FileUtils.sizeOfDirectory(FileUtils.java:2089)
{noformat}
We faced the same issue in Hadoop :(. Checkout
https://issues.apache.org/jira/browse/HADOOP-6963 for our solution
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-185) BZip2CompressorInputStream truncates files compressed with pbzip2
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] [Created] (MATH-774) Gamma Distribution override inversion sampling with nextGamma-implementation from oacm.random
Gamma Distribution override inversion sampling with nextGamma-implementation from oacm.random - Key: MATH-774 URL: https://issues.apache.org/jira/browse/MATH-774 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Mikkel Meyer Andersen Assignee: Mikkel Meyer Andersen Priority: Minor Fix For: 3.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-90) CSVFormat isEscaping/isEscaping are not public
CSVFormat isEscaping/isEscaping are not public -- Key: CSV-90 URL: https://issues.apache.org/jira/browse/CSV-90 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVFormat methods isEscaping() and isEncapsulating() are package protected, whereas the other 3 isXXX() methods are public. There seems no reason for this difference. These are external settings - they are defined by the user - so I don't see why the methods should not be public. AFAICT making them public would not commit the API to anything new. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-317) Need a way to extract parsed headers, e.g. for use in formatting output
Need a way to extract parsed headers, e.g. for use in formatting output --- Key: IO-317 URL: https://issues.apache.org/jira/browse/IO-317 Project: Commons IO Issue Type: New Feature Reporter: Sebb Parsed header names are currently not accessible except as field key names, but these have to be known in advance. It would be useful to be able to have access to the header names: * to use in printing a header for a new CSV file. E.g. to read a CSV file and produce a new one with some changes made. * to write generic CSV applications The headers could be made available as a String array (in column number order) from the CSVParser class. The simplest would be to store the parsed (or provided) headers and return a clone of the array. If headers were not provided or requested, the method should probably return null rather than an empty array - to be decided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-91) Distinguish quoted tokens?
Distinguish quoted tokens? -- Key: CSV-91 URL: https://issues.apache.org/jira/browse/CSV-91 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Priority: Minor Might be useful to be able to distinguish which tokens were quoted and which were not. This would need to apply more that one token type, so would be best as a separate flag. Not sure how this might be stored in the CSVRecord class; perhaps a separate boolean array? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-400) Inconsistent Javadoc comment and code in addIgnoreNull(CollectionT, T) in org.apache.commons.collections.CollectionUtils
Inconsistent Javadoc comment and code in addIgnoreNull(CollectionT, T) in
org.apache.commons.collections.CollectionUtils
--
Key: COLLECTIONS-400
URL: https://issues.apache.org/jira/browse/COLLECTIONS-400
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2.1
Environment: Platform independent
Reporter: SHIN HWEI TAN
The Javadoc comment below states that the method throws NullPointerException
if the collection is null.
/**
.
* @param collection the collection to add to, must not be null
* @param object the object to add, if null it will not be added
* @return true if the collection changed
* @throws NullPointerException if the collection is null
*/
public static T boolean addIgnoreNull(CollectionT collection, T
object) {
return (object != null collection.add(object));
}
However, when called with an null collection and a null object (i.e.,
addIgnoreNull((Collection)null, null)), the method executes normally without
throwing any exception.
Suggested Fixes:
1. Add code if (collection == null) throw NullPointerException(); at the
beginning of the method body.
or
2. Remove @throws NullPointerException if the collection is null from the
Javadoc.
or
3. Change @throws NullPointerException if the collection is null to @throws
NullPointerException if the collection is null and the object is non-null).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COLLECTIONS-401) Inconsistent Javadoc comment and code in removeAll(CollectionE, Collection?) in org.apache.commons.collections.ListUtils
Inconsistent Javadoc comment and code in removeAll(CollectionE,
Collection?) in org.apache.commons.collections.ListUtils
Key: COLLECTIONS-401
URL: https://issues.apache.org/jira/browse/COLLECTIONS-401
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2.1
Reporter: SHIN HWEI TAN
The Javadoc comment below states that the method throws NullPointerException
if either parameter is null.
/*..
*
* @throws NullPointerException if either parameter is null
*/
public static E ListE removeAll(CollectionE collection,
Collection? remove) {
..
}
However, when called with two null collections (i.e.,
removeAll((Collection)null, (Collection)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 either parameter is null from the
Javadoc.
or
3. Change @throws NullPointerException if either parameter is null to
@throws NullPointerException if the first collection is null or (the first
collection is non-empty and the second collection 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] [Created] (COLLECTIONS-402) Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils
Inconsistent Javadoc comment and code in intersection(List list1,List list2)in org.apache.commons.collections.ListUtils --- Key: COLLECTIONS-402 URL: https://issues.apache.org/jira/browse/COLLECTIONS-402 Project: Commons Collections Issue Type: Bug Components: Collection Affects Versions: 3.2.1 Environment: Platform Independent Reporter: SHIN HWEI TAN Fix For: 4.0 The Javadoc comment below states that the method throws NullPointerException if either list is null. /*.. * * @throws NullPointerException if either list is null */ public static List intersection(final List list1, final List list2) .. } However, when called with a null list1 and an empty list2(i.e., intersection((List)null, new ArrayList())), the method executes normally without throwing any exception. Suggested Fixes: 1. Add code if (list1 == null) throw NullPointerException(); at the beginning of the method body. or 2. Remove @throws NullPointerException if either list is null from the Javadoc. or 3. Change @throws NullPointerException if either list is null to @throws NullPointerException if list2 is null or (the list2 is non-empty and the list1 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] [Created] (JXPATH-155) iteratePointers give the wrong pointers
iteratePointers give the wrong pointers
---
Key: JXPATH-155
URL: https://issues.apache.org/jira/browse/JXPATH-155
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Environment: jdk 1.5
Reporter: Martin Busch
I have a xml structur like these:
Request
Tarifierung
Verkaufsprodukt
Produkt
Kondition
Wert2/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert3/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert6/Wert
Werteinheit10/Werteinheit
/Kondition
Kondition
Wert16/Wert
Werteinheit10/Werteinheit
/Kondition
/Produkt
/Verkaufsprodukt
/Tarifierung
/Request
I get an iterator for the Kondtion tags:
JXPathContext context = JXPathContext.newContext(in);
IteratorPointer it_konditionen = (IteratorPointer)
context.iteratePointers(/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition);
while (it_konditionen != null it_konditionen.hasNext()) {
Pointer p = it_konditionen.next();
System.out.println(p);
}
The output to System.out looks like:
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[1]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[2]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[3]
/request/tarifierung/verkaufsprodukt[1]/produkt[1]/kondition[4]
As we can see it start with [2] (which is not the problem) but it iterates over
2-4 twice! And this IS a problem.
Very strange is that the call of it_konditionen.hasNext() increase the
iterator one step.
Best regards
Martin Busch
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-137) Main documentation page links wrong javadocs
Main documentation page links wrong javadocs Key: CODEC-137 URL: https://issues.apache.org/jira/browse/CODEC-137 Project: Commons Codec Issue Type: Bug Affects Versions: 1.5 Environment: Chrome 18, but I guess any browser Reporter: Karsten Tinnefeld Priority: Minor http://commons.apache.org/codec/ prominently says it links 1.5 javadocs, but in fact links 1.4 javadocs. Thus, some prominent new features are not properly documented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DBCP-378) ManagedDataSource returns uses the same underlying DB connection across JTA tx
ManagedDataSource returns uses the same underlying DB connection across JTA tx -- Key: DBCP-378 URL: https://issues.apache.org/jira/browse/DBCP-378 Project: Commons Dbcp Issue Type: Bug Affects Versions: 1.4 Reporter: Ortwin Glück Priority: Critical It seems that when more than one JTA transaction is used within the same thread (suspend/resume transaction), the ManagedDataSource always uses the same underlying DB connection. This scenario is common in EJB containers! If the same DB connection is used the JTA suspend/resume actions have no effect. The JTA semantics is violated this behaviour. Use the following code to setup a unit test that works in your environment // DS setup XADataSource ods = new oracle.jdbc.xa.client.OracleXADataSource(); ... TransactionManager tm = ... DataSourceXAConnectionFactory cf = new DataSourceXAConnectionFactory(tm, ods); AbandonedConfig ab = new AbandonedConfig(); ab.setLogAbandoned(false); ab.setRemoveAbandoned(true); ab.setRemoveAbandonedTimeout(15*60); connPool = new GenericObjectPool(null); // registers itself on the pool KeyedObjectPoolFactory stmtPool = = new StackKeyedObjectPoolFactory(5); new PoolableManagedConnectionFactory(cf, connPool, stmtPool, null, 5, (CollectionString) null, // init sql false, // read-only false, // auto-commit Connection.TRANSACTION_READ_COMMITTED, (String) null, // catalog ab); ds = new ManagedDataSource(connPool, cf.getTransactionRegistry()); // Unit test tm.begin(); Connection c1 = source.getConnection(); Connection ic1 = ((ManagedConnection) c1).getInnermostDelegate(); c1.close(); Transaction tx = tm.suspend(); tm.begin(); c2 = source.getConnection(); ic2 = ((ManagedConnection) c2).getInnermostDelegate(); c2.close(); assertNotSame(Pool must NOT use identical connection across tx, ic1, ic2); tm.commit(); tm.resume(tx); tm.commit(); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-797) StringEscapeUtils.escapeJson
StringEscapeUtils.escapeJson Key: LANG-797 URL: https://issues.apache.org/jira/browse/LANG-797 Project: Commons Lang Issue Type: New Feature Components: lang.* Affects Versions: 2.6 Reporter: Joe Littlejohn Priority: Minor It would be great to offer a StringEscapeUtils.escapeJson method which is similar to StringEscapeUtils.escapeJavaScript but will not escape apostrophe (single-quote) chars. The current escapeJavaScript method does escape single-quote chars, but this produces invalid JSON. A good description of the problem can be found here: http://stackoverflow.com/questions/2275359/jquery-single-quote-in-json-response -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (POOL-213) _numActive can go negative
_numActive can go negative -- Key: POOL-213 URL: https://issues.apache.org/jira/browse/POOL-213 Project: Commons Pool Issue Type: Bug Affects Versions: 1.5.4 Reporter: Mark Mindenhall I'm working on a project that uses Hector (Cassandra client). Hector uses commons-pool (we're using 1.5.4) to pool connections to hosts within a Cassandra cluster. Hector provides a JMX MBean that exposes a NumActive property, which is the cumulative call to retrieve numActive from all of the individual connection pools. When querying this property via JMS on our production servers, we often see negative values. For example, on a server that has three connection pools, the NumActive property reported was -3899. I know this issue has been reported before (POOL-29), and was supposedly fixed. The fix discussed there was to merely check the value of _numActive to prevent it from going negative. However, that does not fix the real problem here, which is that it is possible to decrement _numActive more than once for each activated object. For example, from a quick look at the code (GenericObjectPool.java, v1.5.4), it would be possible to do the following: 1) Create a pool with 10 objects. 2) Borrow all 10 objects from the pool. 3) Call getNumActive (returns 10). 4) Call invalidateObject for ONE of the objects 11 times. 5) Call getNumActive (returns -1). The invalidateObject method calls the _factory to destroy the object, and subsequent calls to destroy the same object may or may not result in an exception. Regardless, _numActive is decremented within a finally block, and therefore would always be decremented even if the object had already been invalidated and destroyed. I'd like to suggest using a HashSet instead of a counter to keep track of active objects. If borrowing an object added it to a HashSet, and returning or invaliding the object removed it from the HashSet (subsequent removes would be no-ops), the example given above would not result in an incorrect value when getNumActive is called (it would just return the current size of the HashSet). Note that although unrelated to this bug, it might also be wise to use a HashSet instead of the int counter _numInternalProcessing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DAEMON-248) jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
jsvc does not expose java.rt.vmArgs monitor information for Java Attach API
---
Key: DAEMON-248
URL: https://issues.apache.org/jira/browse/DAEMON-248
Project: Commons Daemon
Issue Type: Bug
Components: Jsvc
Affects Versions: 1.0.2
Reporter: Elias Ross
Run a process using jsvc.exec
Then use the Attach API to locate the process.
Note that java.rt.vmArgs are not available. See the attached program.
monitoredhost = MonitoredHost.getMonitoredHost(new
HostIdentifier((String) null));
set = monitoredhost.activeVms();
... iterate
MonitoredVm monitoredvm = monitoredhost.getMonitoredVm(new
VmIdentifier(s));
ListMonitor l = monitoredvm.findByPattern(.*);
for (Monitor m : l) {
System.out.println( + m.getName() + +
m.getValue());
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (JELLY-290) Links to source code in tutorial page are broken
Links to source code in tutorial page are broken Key: JELLY-290 URL: https://issues.apache.org/jira/browse/JELLY-290 Project: Commons Jelly Issue Type: Improvement Components: documentation Reporter: Vigneshwaran Raveendran Priority: Minor The links to demo source codes in this page: http://commons.apache.org/jelly/tutorial.html are dead. They return 404 Not Found error. Please fix the links. Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-89) Rename withLineSeparator as withOutputLineSeparator
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] [Created] (NET-457) Does commonsnet ftp component connect to a Secure Stratus site?
Does commonsnet ftp component connect to a Secure Stratus site? --- Key: NET-457 URL: https://issues.apache.org/jira/browse/NET-457 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1 Environment: I am connecting from a Windows 2003 Server environment, JDK 1.6 to a Stratus FTP secure site. Reporter: Ramya Rajendiran Priority: Minor This is not a bug. Just a support question. I am connecting from a Windows 2003 Server environment, JDK 1.6, commons net 301 to a Stratus FTP secure site. The stratus box, supports a directory delimiter of ''. I think this is the problem. Does the commons net FTP component support FTP server delimiter of '' -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-796) DateUtils.addDays does not work properly with daylight saving time (DST)
DateUtils.addDays does not work properly with daylight saving time (DST)
Key: LANG-796
URL: https://issues.apache.org/jira/browse/LANG-796
Project: Commons Lang
Issue Type: Bug
Components: lang.time.*
Affects Versions: 2.6
Reporter: Nicola Barbiero
DateUtils.addDays does not work properly with daylight saving time.
The signature of the method is
Date addDays(Date date, int amount)
and the javadocs says Adds a number of days to a date returning a new object.
The original date object is unchanged,
so if X=date.getTime() is the number of milliseconds of the date in input,
the expected behaviour is that the returned Date has a number of milliseconds
equal to X+amount*(8640), where 8640 is the number of milliseconds in
one day.
But when the calculation goes across the DST change date, the number of
milliseconds added does not correspond to whole days.
For example, here in Brussels, this code fragment:
Date input = DateUtils.parseDateStrictly(25-03-2012_00:00, new String[] {
dd-MM-_HH:mm });
Date output = DateUtils.addDays(input, 1);
will give:
'input' equals to Sun Mar 25 00:00:00 CET 2012== input.getTime() equals
to 133263000
'output' equals to Mon Mar 26 00:00:00 CEST 2012 == output.getTime() equals
to 133271280
where 133271280-133263000=8280 8640
(in fact 8280 is equivalent to 23h).
Since addDays is working with objects Date, it should not be influenced by
events like the DST.
Proposed solution: replace the current implementation
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(calendarField, amount);
return c.getTime();
}
based on Calendar with an implementation that works only with Date objects, for
example:
public static Date add(Date date, int calendarField, int amount) {
if (date == null) {
throw new IllegalArgumentException(The date must not be null);
}
return new Date(input.getTime() + amount * 8640l);
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-136) Use Charset objects when possible, create Charsets for required character encodings
Use Charset objects when possible, create Charsets 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 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] [Created] (IO-314) Deprecate and then remove all methods that use the default encoding
Deprecate and then remove all methods that use the default encoding --- Key: IO-314 URL: https://issues.apache.org/jira/browse/IO-314 Project: Commons IO Issue Type: Improvement Components: Streams/Writers Affects Versions: 2.1 Reporter: Aaron Digulla Priority: Minor On Stackoverflow.com, I often see this kind of question: When I read my text on a different computer, it's all garbled. The underlying issue is that people don't understand the concept of encoding and therefore, they use the default encoding which breaks their code when they least expect it. Worse, it often causes data corruption without throwing exceptions. Therefore my suggestion: Deprecate and then remove all methods that use the default encoding. Users should always specify an encoding when doing text I/O, to make sure that data cannot be corrupted even when they don't know what they're doing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-315) Replace all String encoding parameters with a value type
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-316) New API: BackupFileWriter
New API: BackupFileWriter
-
Key: IO-316
URL: https://issues.apache.org/jira/browse/IO-316
Project: Commons IO
Issue Type: Bug
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Priority: Minor
Add the new file based I/O class {{BackupFileWriter}} with the following
properties:
- Saves the file to a temporary name
- Creates backup of existing file on {{close()}}
- Renames temp file to desired name on {{close()}}
The backup strategy (number of backups, backup file name) should be pluggable.
There should also be a hook to compare the temporary and the existing file and
do the rename only when they are different. The default hook should always
replace the file.
It should also be possible to override the temporary file name (including the
path, so the temp file can be in the same directory or a different one or even
on a different disk).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-795) Replace all String encoding parameters with Charset
Replace all String encoding parameters with Charset
-
Key: LANG-795
URL: https://issues.apache.org/jira/browse/LANG-795
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.1
Reporter: Aaron Digulla
In several places, String constants are used to specify an encoding for data.
Please add methods that accept {{Charset}} instead, and deprecate the existing
methods.
The goal of this change is to reduce code smell (using String constants instead
of a real value type).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-87) CSVParser.getRecords() returns null rather than empty List at EOF
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] [Created] (CSV-88) Not possible to create a CSVFormat from scratch
Not possible to create a CSVFormat from scratch --- Key: CSV-88 URL: https://issues.apache.org/jira/browse/CSV-88 Project: Commons CSV Issue Type: Bug Reporter: Sebb It's not possible to create a CSVFormat except by modifying an existing format. Could either make the PRISTINE format public, or provide a constructor with a single parameter (the delimiter). Could provide a no-args ctor instead, but there seems little point in that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-86) Remove current character input parameter from Lexer methods
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 Reporter: Benedikt Ritter -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-414) Implement the Google PageRank algorithm
Implement the Google PageRank algorithm --- Key: SANDBOX-414 URL: https://issues.apache.org/jira/browse/SANDBOX-414 Project: Commons Sandbox Issue Type: New Feature Components: Graph Reporter: Simone Tripodi Google [PageRank|http://en.wikipedia.org/wiki/PageRank] algorithm can be modeled and resolved via a Graph algo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-415) Add the Elo rating system algorithm
Add the Elo rating system algorithm --- Key: SANDBOX-415 URL: https://issues.apache.org/jira/browse/SANDBOX-415 Project: Commons Sandbox Issue Type: New Feature Reporter: Simone Tripodi Assignee: Simone Tripodi The [ELO|http://en.wikipedia.org/wiki/Elo_rating_system] rating algorithm can be modeled and resolved via a Graph algo. I already started working on [OpenELO|https://svn.apache.org/repos/asf/labs/openelo/] Lab at ASF that I intend migrate to commons-graph -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-416) Improve DFS/BFS visit states
Improve DFS/BFS visit states
Key: SANDBOX-416
URL: https://issues.apache.org/jira/browse/SANDBOX-416
Project: Commons Sandbox
Issue Type: Improvement
Components: Graph
Reporter: Simone Tripodi
Assignee: Simone Tripodi
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] [Created] (CSV-84) Comment handling
Comment handling Key: CSV-84 URL: https://issues.apache.org/jira/browse/CSV-84 Project: Commons CSV Issue Type: New Feature Reporter: Sebb Comment handling is not currently fully documented / tested. There are several possible situations: 1) trailing comment following one or more values 2) comment marker starts in the first column 3) comment marker starts in the first non-whitespace column How should these be handled? 1) The trailing comment should be ignored 2) Entire line should be ignored, i.e. don't treat it as a blank line 3) This is trickier: if whitespace is being trimmed, treat as 2, else treat as 1, i.e. there is a single value containing whitespace It might also be useful to consider returning comments to the application program as part of CSVRecord. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-85) Allow comments to be returned in CSVRecord
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] [Created] (MATH-770) SymmLQ not tested in SymmLQTest
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
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] [Created] (MATH-771) Improve javadoc for iterative linear solvers with preconditioners
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
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] [Created] (COMPRESS-184) PAX header parser fails for non-ASCII values
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] [Created] (CSV-82) CSVRecord inconsistent behaviour when header mapping is not found
CSVRecord inconsistent behaviour when header mapping is not found - Key: CSV-82 URL: https://issues.apache.org/jira/browse/CSV-82 Project: Commons CSV Issue Type: Bug Reporter: Sebb The CSVRecord#get(String) method has inconsistent behaviour. If no header mapping was provided, then it throws IllegalStateException. If the header name is not found, null is returned. Apart from being inconsistent, it might be useful in the future to be able to return null as a column value (as distinct from the empty string). It should throw IllegalArgumentException for a missing header name, instead of returning null. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-83) Provide a header encapsulator class
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] [Created] (MATH-772) Change genetics component API to allow for different types of CrossoverPolicys and SelectionPolicys.
Change genetics component API to allow for different types of CrossoverPolicys and SelectionPolicys. Key: MATH-772 URL: https://issues.apache.org/jira/browse/MATH-772 Project: Commons Math Issue Type: Improvement Affects Versions: Nightly Builds Reporter: Reid Hochstedler -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-773) You should be able to run evolution simulation for a certain amount of time.
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 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] [Created] (JCI-68) FilesystemAlterationMonitor NullPointerException when directory not readable
FilesystemAlterationMonitor NullPointerException when directory not readable Key: JCI-68 URL: https://issues.apache.org/jira/browse/JCI-68 Project: Commons JCI Issue Type: Bug Components: fam Affects Versions: 1.1 Environment: Linux Reporter: Jan When one of the directories monitored by the FilesystemAlterationMonitor is not readable by the proess, the monitoring crashes with a NullPointerException -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMMONSSITE-70) org.apache.harmony.security.asn1 throwing null pointer exception
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
Fix For: 19
I am trying to parse a .cer certificate issued by Thwate(find it attacthed).I
am getting a null pointer exception while parsing the certificate.But I am able
to parse other .cer certificates without any problem.
package com.ams;
import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import com.ams.certparser.CertificateParserUtil;
public class CertificateParserTestActivity extends Activity {
/** Called when the activity is first created. */
private static String TAG = CertificateParserTestActivity;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
CertificateParserUtil certParserUtil = new
CertificateParserUtil(
sdcard/Thwate.cer,null);
certParserUtil.parse();
// Log.i(TAG, Type: + certParserUtil.getCertType());
Log.i(TAG, Version: + certParserUtil.getVersion());
Log.i(TAG, Basic Constraint Extensions: +
certParserUtil.getBasicConstraints());
Log.i(TAG, IssuerUniqueID: +
certParserUtil.getIssuerUniqueID());
Log.i(TAG, IssuerName: +
certParserUtil.getIssuerX500Principal());
Log.i(TAG, Public Key:+ certParserUtil.getPublicKey());
Log.i(TAG, Issuer DN: + certParserUtil.getIssuerDN());
Log.i(TAG, Subject: + certParserUtil.getSubjectDN());
Log.i(TAG, Valid From: + certParserUtil.getValidFrom());
Log.i(TAG, Valid Till: + certParserUtil.getValidTill());
Log.i(TAG, Public Key: +
certParserUtil.getPublicKey().getAlgorithm());
Log.i(TAG, Serial Number: + certParserUtil.getSerialNumber());
Log.i(TAG, Key: + certParserUtil.getKeyUsage());
Log.i(TAG, Signature: + certParserUtil.getSignature());
Log.i(TAG, SignSlgoName: + certParserUtil.getSigAlgName());
//Log.i(TAG, Signature: +
certParserUtil.getTBSCertificate());
}
}
package com.ams.certparser;
import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.math.BigInteger;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.NoSuchAlgorithmException;
import java.security.Principal;
import java.security.PublicKey;
import java.security.cert.CertificateEncodingException;
import java.security.cert.CertificateException;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.Date;
import java.util.Enumeration;
import javax.security.auth.x500.X500Principal;
import android.os.Environment;
import android.util.Log;
public class CertificateParserUtil {
private static final String TAG = CertificateParserUtil;
public static final String PFX = PFX;
public static final String CER = CER;
FileInputStream fin = null;
private String filePath;
private String password;
X509Certificate cert;
public CertificateParserUtil(String filePath, String password) {
this.filePath = filePath;
this.password = password;
}
private String getExtension() {
String ext = ;
int mid = filePath.lastIndexOf(.);
ext = filePath.substring(mid + 1, filePath.length());
return ext;
}
public void parse() {
String ext = getExtension();
File file = new File(filePath);
if (PFX.equalsIgnoreCase(ext)) {
KeyStore ks = null;
try {
ks = KeyStore.getInstance(PKCS12);
//fin = new FileInputStream(file);
ks.load(fin, password.toCharArray());
EnumerationString aliasesEnum = null;
aliasesEnum = ks.aliases();
while (aliasesEnum.hasMoreElements()) {
String alias = (String)
aliasesEnum.nextElement();
cert = (X509Certificate
[jira] [Created] (CSV-80) CSVLexer.nextToken does not need wsBuf
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] [Created] (CSV-81) Token.Type.isReady could perhaps be removed
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] [Created] (VFS-408) CompressedFileFileObject Exception thrown when container file has no extension
CompressedFileFileObject Exception thrown when container file has no extension
--
Key: VFS-408
URL: https://issues.apache.org/jira/browse/VFS-408
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Anil Mahajan
Priority: Minor
CompressedFileFileObject blindly performs a substring operation on an unchecked
String index lookup value. If that value happens to be -1 (lookup not found),
then an Index Out Of Bounds error is thrown. The lookup is for a . to find
the base file name.
This happens when trying to decompress a file with no file extension.
subversion revision: 1159220 for CompressedFileFileObject.java
code in repository: line 42:
// todo, add getBaseName(String) to FileName
String basename = container.getName().getBaseName();
int pos = basename.lastIndexOf('.');
basename = basename.substring(0, pos);
should alter that last line to something like:
if (pos 0)
basename = basename.substring(0, pos);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-312) CharSequenceInputStream(CharSequence s, Charset charset, int bufferSize) ignores bufferSize
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 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-313) Add IOUTils.toBufferedReader(Reader)
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 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] [Created] (NET-456) [net] TelnetClient hangs when reader-thread startup delays
[net] TelnetClient hangs when reader-thread startup delays -- Key: NET-456 URL: https://issues.apache.org/jira/browse/NET-456 Project: Commons Net Issue Type: Bug Components: Telnet Affects Versions: 3.1 Reporter: MarikoSekiguchi I'm trying to use TelnetClient(commons-net-3.1) with the reader-thread enabled, but it sometimes hangs. I tracked __receiveState, and found that the state sometimes changes to invalid ones. In threaded-mode, TelnetInputStream.__read(boolean mayBlock) is normally called only by TelnetInputStream.run(). But if the read-thread startup delays, it may also called by TelnetInputStream.read() beacues the value of __threaded is still false. example of hang-up pattern 1. // user-thread telnetClient._connectAction() TelnetInputStream._start() __thread.start(); ... try to start read-thread 2. // user-thread TelnetInputStream.read() ... __threaded is still false, so TelnetInputStream.__read() is called. 3. // read-thread starts (before __read() above dosen't end ) TelnetInputStream.run( ) ... sets __threaded to true, and calls TelnetInputStream.__read() I think __threaded flag should be set to true just after __thread.start(), not at the begining of run(). __thread.start(); __threaded = true; // add This problem may related to NET-73 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CODEC-135) Null Pointer Exception
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
Fix For: 1.x
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.
package com.ams;
import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.security.KeyStore;
import java.security.KeyStoreException;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.Enumeration;
import javax.security.cert.Certificate;
import android.content.Context;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.Toast;
public class CertificateComponent {
private static final String TAG = CertificateParser;
public static final String PFX = sdcard/AC350.pfx;
public static final String CER = sdcard/test.cer;
X509Certificate cert;
FileInputStream in;
Context ctx;
private Button Pkcs12Button;
private Button CertButton;
public void click(View v) {
try {
if (v.getId() == R.id.pkcs12_button) {
String password = TZ96dtbx;
KeyStore ks = KeyStore.getInstance(PKCS12);
in= new FileInputStream(PFX);
// byte[] p12 = readFile(PFX);
in.close();
ks.load(in, password.toCharArray());
EnumerationString aliasesEnum = ks.aliases();
// Log.i(TAG, certificate details: +
aliasesEnum);
String alias = (String)
aliasesEnum.nextElement();
// System.out.println(Alias: + alias);
cert = (X509Certificate)
ks.getCertificate(alias);
while (aliasesEnum.hasMoreElements()) {
Log.i(TAG, Type: + cert.getType());
Log.i(TAG, Key Algorithm:
+
cert.getPublicKey().getAlgorithm());
Log.i(TAG, Version: +
cert.getVersion());
Log.i(TAG, Issuer DN: +
cert.getIssuerDN());
Log.i(TAG, Subject: +
cert.getSubjectDN());
Log.i(TAG, Valid From: +
cert.getNotBefore());
Log.i(TAG, Valid Till: +
cert.getNotAfter());
Log.i(TAG, Public Key: +
cert.getPublicKey());
Log.i(TAG, Serial Number: +
cert.getSerialNumber());
Log.i(TAG, Signature: +
cert.getSignature());
String message = Check Logcat For
Certificate Details;
Toast.makeText(ctx, message,
Toast.LENGTH_SHORT).show();
}
} else if (v.getId() == R.id.cert_button) {
// String filename = sdcard/test_b64.cer;
in = new FileInputStream(CER);
BufferedInputStream bf = new
BufferedInputStream(in);
CertificateFactory cf =
CertificateFactory.getInstance(X.509);
cert = (X509Certificate)
cf.generateCertificate(bf);
while (bf.available() 0) {
Log.i(TAG, Type: + cert.getType());
Log.i(TAG, Key Algorithm:
+
cert.getPublicKey().getAlgorithm());
Log.i(TAG, Version: +
cert.getVersion());
Log.i(TAG, Issuer DN: +
cert.getIssuerDN());
Log.i(TAG, Subject: +
cert.getSubjectDN());
Log.i(TAG, Valid From: +
cert.getNotBefore());
[jira] [Created] (CONFIGURATION-492) XMLConfiguration.getStringArray does not parse OS Environment Variables
XMLConfiguration.getStringArray does not parse OS Environment Variables
---
Key: CONFIGURATION-492
URL: https://issues.apache.org/jira/browse/CONFIGURATION-492
Project: Commons Configuration
Issue Type: Bug
Components: Interpolation
Affects Versions: 1.8
Environment: Windows XP, Commons Configuration 1.8
Reporter: Chris Jackson
Priority: Minor
When using a OS environment variable in an XMLConfiguration file, the
getStringArray() method does not correctly parse multiple items in the same
entry.
XML:
...
items{$env:items}/items
...
Windows Environment variable %items% is set to item1,item2.
Code:
...
String[] items = config.getStringArray(items)
for (Sting item : items) {
System.out.println(Item: + item);
}
...
Output:
Item: item1,item2
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CSV-79) CSVFormat.isCommentingDisabled() is very confused
CSVFormat.isCommentingDisabled() is very confused
-
Key: CSV-79
URL: https://issues.apache.org/jira/browse/CSV-79
Project: Commons CSV
Issue Type: Bug
Reporter: Sebb
The Javadoc for CSVFormat.isCommentingDisabled() says:
{code}
/**
* Specifies whether comments are supported by this format.
*
* @return tttrue/tt is comments are supported, ttfalse/tt otherwise
*/
{code}
however the method actually does the opposite, as the name suggests.
Now we could just fix the Javadoc, but given that the other isXXX methods
return a positive result this would be inconsistent.
Also, it's generally better to return positive setting.
So I think renaming the method as isCommentingEnabled - and fixing the method
code - would be better.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANSELAN-70) Incorrect PhysicalWidthDpi for JPEG image with resolution specified in dots per millimeter
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
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] [Created] (BEANUTILS-411) BeanUtilsBean.setProperty throws IllegalArgumentException if getter of nested property returns null
BeanUtilsBean.setProperty throws IllegalArgumentException if getter of nested
property returns null
---
Key: BEANUTILS-411
URL: https://issues.apache.org/jira/browse/BEANUTILS-411
Project: Commons BeanUtils
Issue Type: Bug
Components: Bean / Property Utils
Affects Versions: 1.8.3, 1.8.2, 1.8.1, 1.8.0
Environment: Apache Struts 1.3.10 (latest) uses commons-beanutils 1.8.0
Reporter: Marcus Zander
The issue is like #BEANUTILS-331, BEANUTILS-339 where BeanUtils.populate() -
BeanUtilsBean.setProperty throws an IllegalArgumentException when it should not.
error situation (see attached JUnitTest):
BeanUtilsBean.setProperty(bean,foo.bar, value) with a nested property
foo.bar where bean.getFoo() returns null.
Line 903 (in 1.8.0 -1.8.3) getPropertyUtils().getProperty(target,
resolver.next(name));
returns null (because bean.getFoo() returns null) which is not handled
correctly.
The Exception is thrown in line 963 because target == null.
expected:
SetProperty should silently return like in the case the property does not exist.
background:
BeanUtils.populate(), BeanUtilsBean.setProperty are used by Struts to populate
HTTP-Request-Parameters to form beans (form backing objects). The request sent
by a browser when clicking a input type=image name=imgLink... contains
parameters imgLink.x and imgLink.y. These request parameters should not let
to an error when populating to a bean which has the property imgLink.
The application should be able to process these parameters after bean
populating, which is not possible now because populate fails.
Test case to reproduce:
public class BeanUtilsBeanTest extends TestCase
{
public void testSetProperty()
throws Exception
{
DummyBean testBean = new DummyBean(); // nested==null
BeanUtilsBean instance = new BeanUtilsBean();
/* fails with java.lang.IllegalArgumentException: No bean specified
* Reason: getPropertyUtils().getProperty(target,
resolver.next(name)); returnes null
* because DummyBean.getImgLink() returns null
*/
instance.setProperty(testBean, imgLink.x, 1);
}
public class DummyBean
{
private String imgLink = null; // stays null
public String getImgLink ()
{
return imgLink;
}
public void setImgLink(String imgLink)
{
this.imgLink = imgLink;
}
}
}
suggestion for a fix:
Return after line 903 if getProperty returns null and therefor target becomes
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] [Created] (NET-455) FTPClient listFiles(FTPFileFilter) can be faster...
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
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 = files = ftpClient.listFiles(./,
ftpFileFilter);
It takes about 90 seconds ...
the second one is ... nearly as simple as the first one :
FTPFile [] allFilesListed = ftpClient.listFiles();
files = FTPFileFilterWithExtension.fastFilter(ftpFileFilter, allFilesListed);
The function FTPFileFilterWithExtension.fastFilter() call the same
ftpFileFilter :
public static FTPFile [] fastFilter(FTPFileFilter filter, FTPFile
ftpFileArray []) {
ArrayListFTPFile listOfFTPFiles = new ArrayListFTPFile();
for (FTPFile ftpf : ftpFileArray) {
boolean accepted = filter.accept(ftpf);
if (accepted) {
listOfFTPFiles.add(ftpf);
}
}
FTPFile resultArray [] = new FTPFile[listOfFTPFiles.size()];
return listOfFTPFiles.toArray(resultArray);
}
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] [Created] (IO-311) IOUtils.read(InputStream/Reader) ignores the offset parameter
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 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] [Created] (IO-310) Add ByteOrderMark constants for UTF-32 little and big endian.
Add ByteOrderMark constants for UTF-32 little and big endian. - Key: IO-310 URL: https://issues.apache.org/jira/browse/IO-310 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.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 Add ByteOrderMark constants for UTF-32. This is useful for XML processing. See http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-406) RAM FileSystem resize throws ArrayOOBE when shrinking in size.
RAM FileSystem resize throws ArrayOOBE when shrinking in size.
--
Key: VFS-406
URL: https://issues.apache.org/jira/browse/VFS-406
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Miroslav Pokorny
Im targetting 2.0 as it is the official download.
The fix is quite simple.
FILE: RamFileObject
ORIGINAL
void resize(int newSize)
{
int size = this.size();
byte[] newBuf = new byte[newSize];
System.arraycopy(this.buffer, 0, newBuf, 0, size);
this.buffer = newBuf;
updateLastModified();
}
// when shrinking size newSize thus an AOOBE will be thrown.
FIXED
void resize(final int newSize) {
final int size = this.size();
final byte[] newBuf = new byte[newSize];
// HACK fixed error which prevented resizing to a small buffer.
System.arraycopy(this.buffer, 0, newBuf, 0, Math.min(newSize, size));
this.buffer = newBuf;
this.updateLastModified();
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-407) reading a RAM FileSystem file fails because it never returns EOF -1.
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
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] [Created] (SANSELAN-68) Incorrect reading Physical Width/Height Dpi and Physical Width/Height from TIFF files
Incorrect reading Physical Width/Height Dpi and Physical Width/Height 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
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] [Created] (SANSELAN-69) Incorrect reading Physical Width/Height Inch from PNG files
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
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);
PhysicalWidthInch = (float) ((double) Width
+/ ((double) pngChunkpHYs.PixelsPerUnitXAxis *
meters_per_inch));
PngImageParser.java (625):
PhysicalHeightInch = (float) ((double) Height
-* (double) pngChunkpHYs.PixelsPerUnitYAxis *
meters_per_inch);
PhysicalHeightInch = (float) ((double) Height
+/ ((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] [Created] (EXEC-64) DefaultExecutor line 372 swallows IOException cause instead of propagating it
DefaultExecutor line 372 swallows IOException cause instead of propagating it
-
Key: EXEC-64
URL: https://issues.apache.org/jira/browse/EXEC-64
Project: Commons Exec
Issue Type: Bug
Affects Versions: 1.1
Reporter: Michael Vorburger
Priority: Trivial
DefaultExecutor line 372 does:
{noformat}
} catch (Exception e) {
throw new IOException(e.getMessage());
}
{noformat}
when it may be better to do:
{noformat}
} catch (Exception e) {
throw new IOException(e.getMessage(), e);
}
{noformat}
This didn't cause any real issues for me - I just came across it as I was
browsing the Commons Exec source, in the context of implementing a launch
helper (BTW: see
https://github.com/vorburger/MariaDB4j/blob/master/src/main/java/ch/vorburger/exec/ManagedProcess.java
- would that, once further cleaned-up, potentially be something of any
interest to you for integration into Commons Exec?).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
