[jira] Resolved: (MATH-544) Exceptions classes pertaining to matrices move back to package linear
[ https://issues.apache.org/jira/browse/MATH-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-544. - Resolution: Fixed Done in revision 1079350. Exceptions classes pertaining to matrices move back to package linear --- Key: MATH-544 URL: https://issues.apache.org/jira/browse/MATH-544 Project: Commons Math Issue Type: Task Reporter: Gilles Assignee: Gilles Priority: Minor Labels: api-change Fix For: 3.0 Under the assumption that no exception related to matrices should ever be thrown by classes other than those in package linear, these exception classes will be relocated in that package. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-314) The FTP client should autodetect the control encoding.
[ https://issues.apache.org/jira/browse/NET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-314: -- Attachment: ftp-autodetect-utf.diff I believe the only non-ASCII encoding permitted is UTF-8 (http://tools.ietf.org/html/rfc2640), this is detected by sending the FEAT command and looking for UTF8 in the response. The attached file does exactly this, right after the connection (original server greeting saved restored later). The autodetection is user-controlled. The FTP client should autodetect the control encoding. -- Key: NET-314 URL: https://issues.apache.org/jira/browse/NET-314 Project: Commons Net Issue Type: Improvement Components: FTP Affects Versions: 1.4 Environment: Java client using FTP through VFS to connect to a Java (Alfresco's) FTP server Reporter: Tom Attachments: ftp-autodetect-utf.diff The Alfresco FTP server uses UTF8 for the control encoding. FTPClient can be set to use UTF8, but VFS does not expose that (https://issues.apache.org/jira/browse/VFS-305) and needs to be modified to fix this. But that is not the issue here; FileZilla is able to automatically detect that Alfresco's FTP server is using UTF8. So apparantly the server is somehow communicating this to the client. Being able to automatically set the encoding, would greately improve the out-of-the-box quality of the FTP component. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-314) The FTP client should autodetect the control encoding.
[ https://issues.apache.org/jira/browse/NET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-314. -- Resolution: Fixed Thanks very much! Patch applied with one trivial change - renamed the boolean as __autodetectEncoding to agree with the other private fields. The FTP client should autodetect the control encoding. -- Key: NET-314 URL: https://issues.apache.org/jira/browse/NET-314 Project: Commons Net Issue Type: Improvement Components: FTP Affects Versions: 1.4 Environment: Java client using FTP through VFS to connect to a Java (Alfresco's) FTP server Reporter: Tom Attachments: ftp-autodetect-utf.diff The Alfresco FTP server uses UTF8 for the control encoding. FTPClient can be set to use UTF8, but VFS does not expose that (https://issues.apache.org/jira/browse/VFS-305) and needs to be modified to fix this. But that is not the issue here; FileZilla is able to automatically detect that Alfresco's FTP server is using UTF8. So apparantly the server is somehow communicating this to the client. Being able to automatically set the encoding, would greately improve the out-of-the-box quality of the FTP component. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-403) Never propagate a NullPointerException resulting from bad usage of the API
[ https://issues.apache.org/jira/browse/MATH-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004192#comment-13004192 ] Gilles commented on MATH-403: - checkNotNull added in revision 1079519. Never propagate a NullPointerException resulting from bad usage of the API Key: MATH-403 URL: https://issues.apache.org/jira/browse/MATH-403 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor Fix For: 3.0 Package exception contains a class named NullArgumentException meant to signal that an argument was null where it shouldn't have been. For consistency, every method of the API should be checked for null arguments and throw NullArgumentException appropriately. This means hunting down all unchecked uses of references. Is there a tool that will report those? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COLLECTIONS-332) ListOrderedMap not respecting underlying list
[ https://issues.apache.org/jira/browse/COLLECTIONS-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved COLLECTIONS-332. - Resolution: Fixed Fix Version/s: 3.2.2 Added the following comment on ListOrderedMap: *Note* that ListOrderedMap doesn't work with {{IdentityMap}}, {{CaseInsensitiveMap}}, or similar maps that violate the general contract of {{Map}}. The {{ListOrderedMap}} (or, more precisely, the underlying {{List}}) is relying on {{equals()}}. This is fine, as long as the decorated {{Map}} is also based on {{equals()}}, and {{hashCode()}}, which {{IdentityMap}}, and {{CaseInsensitiveMap}} don't: The former uses {{==}}, and the latter uses {{equals()}} on a lowercased key. Added the following to IdentityMap, and CaseInsensitiveMap: *Note* This map will violate the detail of various Map and map view contracts. As a general rule, don't compare this map to other maps. In particular, you can't use decorators like {{ListOrderedMap}} on it, which silently assume that these contracts are fulfilled. ListOrderedMap not respecting underlying list - Key: COLLECTIONS-332 URL: https://issues.apache.org/jira/browse/COLLECTIONS-332 Project: Commons Collections Issue Type: Bug Components: Map Reporter: Tom Parker Priority: Minor Fix For: 3.2.2 Attachments: ListOrderedMapTest.java When decorating either CaseInsensitiveMap or IdentityMap (and I believe this will impact any java.util.TreeMap built with a non-.equals() Comparator), ListOrderedMap responds inconsistently with the underlying map. The ordering seems to be operating off .equals() rather than the actual contents of the underlying map. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FILEUPLOAD-130) Add ability to get any header from the FileItem and FileItemStream interfaces
[ https://issues.apache.org/jira/browse/FILEUPLOAD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13004236#comment-13004236 ] Jen commented on FILEUPLOAD-130: Using commons-fileupload-1.2.2 and having same problem as Guillaume's post above regarding retrieving the Content-Transfer-Encoding to detect base64 encoding. DiskFileItem getHeaders() is returned as null Add ability to get any header from the FileItem and FileItemStream interfaces - Key: FILEUPLOAD-130 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-130 Project: Commons FileUpload Issue Type: Improvement Affects Versions: 1.2 Reporter: Michael Macaluso Priority: Minor Fix For: 1.2.1 Attachments: FILEUPLOAD-130.patch, FileUpload-130_1.patch, FileUpload-130_2.patch, commons-fileupload-1.2.1-items-headers-issue.patch The FileItem and FileItemStream interfaces should have a way to return back any header that was encountered during the header parsing for an Item. Currently, from the FileItemStatus you can only get information from the 2 pre-defined headers Content-Type and Content-Disposition (Sort-of because the header can not be accessed raw). Other than the interface changes (including the change to pass them along in the FileItemFactory interface), it appears that all changes can be made within the FileUploadBase.java file. FileUploadBase.java:859 (as of 1.2) has the headers, but the call to create the FileItemStreamImpl on lines 877 and 887 do not include the headers map. Further, the parseRequest method uses the FileItemStream interface to build the FileItem, so you should always have the headers in question. The reason for this request is that we have an application that is sending per-part headers (not precluded by the specs as far as we know of) to provide more information than name and content-type and using the FileUpload project means that we can no longer find out those header values. [Also, not completely sure, but I believe FileUploadBase.createItem(Map, boolean) on line 480 is not referenced anymore in this project.] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-364) Article is very inefficient and incorrect
Article is very inefficient and incorrect - Key: NET-364 URL: https://issues.apache.org/jira/browse/NET-364 Project: Commons Net Issue Type: Bug Components: NNTP Affects Versions: 2.2 Reporter: Sebb References are currently stored as tab-separated strings in a string buffer, which is then parsed to return the list. Also, the article information may contain several space-separated references. Article.isReply() is also incorrect, as it depends on the subject containing Re;, rather than whether there are any references. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COLLECTIONS-331) CollatingIterator NPE when Comparator is null
[ https://issues.apache.org/jira/browse/COLLECTIONS-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved COLLECTIONS-331. - Resolution: Fixed Fix Version/s: (was: 4.0-beta-1) 3.2.2 Assignee: Jochen Wiedmann Agree with Hen's assessment that the use of Comparable.compareTo might likely cause a bunch of other problems. I have verified, that this bug exists in every revision since CollatingIterator was verified. In other words, we don't need to care for upwards compatibility, there can't be any code floating around that depends on the use of natural sort order. Consequently I decided to * throw an NPE in least() with a message describing the problem, if no Comparator is present. (This meets the current behaviour, so it is upwards compatible.) * change the documentation of the default constructor to require a call to setComparator * remove all references to natural sort order and replace them with the recommendation to use ComparableComparator, if required CollatingIterator NPE when Comparator is null - Key: COLLECTIONS-331 URL: https://issues.apache.org/jira/browse/COLLECTIONS-331 Project: Commons Collections Issue Type: Bug Components: Iterator Affects Versions: 3.2 Reporter: Michael Krkoska Assignee: Jochen Wiedmann Priority: Minor Fix For: 3.2.2 Attachments: COLLECTIONS-331.patch, CollatingIteratorTest.java Original Estimate: 5m Remaining Estimate: 5m Run the attached Test against commons-collections-3.2.1. While the JavaDoc for CollatingIterator claims {{@param comp the comparator to use to sort, or null to use natural sort order}} the test fails, because the comparator is null. Fixing this requires a change in {{org.apache.commons.collections.iterators.CollatingIterator.least()}}: {code} if (comparator.compare(curObject,leastObject) 0) { ... {code} could be replaced with {code} int c = comparator==null?((Comparable)curObject).compareTo(leastObject):comparator.compare(curObject,leastObject); if (c 0) { ... {code} The workaround is to provide a comparator, of course. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-364) Article is very inefficient and incorrect
[ https://issues.apache.org/jira/browse/NET-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-364. -- Resolution: Fixed Fix Version/s: 3.0 Article is very inefficient and incorrect - Key: NET-364 URL: https://issues.apache.org/jira/browse/NET-364 Project: Commons Net Issue Type: Bug Components: NNTP Affects Versions: 2.2 Reporter: Sebb Fix For: 3.0 References are currently stored as tab-separated strings in a string buffer, which is then parsed to return the list. Also, the article information may contain several space-separated references. Article.isReply() is also incorrect, as it depends on the subject containing Re;, rather than whether there are any references. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-318) Article.references field is never updated; extremely inefficient implementation
[ https://issues.apache.org/jira/browse/NET-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-318. -- Resolution: Fixed Fix Version/s: 3.0 Fixed as part of NET-364 Article.references field is never updated; extremely inefficient implementation --- Key: NET-318 URL: https://issues.apache.org/jira/browse/NET-318 Project: Commons Net Issue Type: Bug Components: NNTP Affects Versions: 2.0 Reporter: Sebb Priority: Minor Fix For: 3.0 Article.references is a private StringBuffer instance. The method addReference(String) inserts the reference into the buffer followed by a tab. However, as far as I can tell, this is never called. The method getReferences() - which is used - has to parse the StringBuffer in order to find the references. Since the buffer is only used in the add and get methods, it does not make sense to handle the references this way. Even if the buffer were used (e.g. as part of a toString() method) it would still be better to store the references as a List or Array. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-185) Possible NPE in Threader.java
[ https://issues.apache.org/jira/browse/NET-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-185. -- Resolution: Fixed Added a check just in case Possible NPE in Threader.java - Key: NET-185 URL: https://issues.apache.org/jira/browse/NET-185 Project: Commons Net Issue Type: Bug Components: NNTP Environment: Fortify Reporter: Henri Yandell Priority: Minor In Threader.gatherSubjects, it appears to be possible for tail.next = c.child; to be null [line 356]: 349 if (old.threadable == null c.threadable == null) { 350 // both dummies - merge them 351 ThreadContainer tail; 352 for (tail = old.child; 353 tail != null tail.next != null; 354 tail = tail.next); 355 356 tail.next = c.child; It also seems kind of pointless, given that the subsequent line immediately resets tail to c.child. Perhaps the ; is not intended there? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (COLLECTIONS-323) Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Wiedmann resolved COLLECTIONS-323. - Resolution: Fixed Fix Version/s: (was: 4.x) 3.2.2 Assignee: Jochen Wiedmann Applied for all classes mentioned by Hen, except for LRUMap, In the case of LRUMap, this would mean to silently increase the capacity, which is most likely not what the user would expect. Behavior of constructors CaseInsensitiveMap inconsistent with standard Java HashMap --- Key: COLLECTIONS-323 URL: https://issues.apache.org/jira/browse/COLLECTIONS-323 Project: Commons Collections Issue Type: Bug Components: Map Affects Versions: 3.2 Environment: Any Reporter: Maarten Brak Assignee: Jochen Wiedmann Priority: Minor Fix For: 3.2.2 Attachments: patch.tar.gz Original Estimate: 24h Remaining Estimate: 24h The constructor CaseInsensitiveMap(int initialCapacity) throws an IllegalArgumentException if the initial capacity is less than one. This is inconsistent with the standard Java HashMap constructor HashMap(int initialCapacity), which throws an if IllegalArgumentException if the initial capacity is negative. Thus: new HashMap(0) == no exception new CaseInsensitiveMap(0) == IllegalArgumentException. This inconsistency is confusing. Actions: - Change Javadoc (this shouldn't be a problem in practice since surely there is no code around depending on the fact that the constructor throws an IllegalArgumentException :-)) - Change code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-276) NNTPClient has problems with group listings for large groups.
[ https://issues.apache.org/jira/browse/NET-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-276. -- Resolution: Fixed Fixed, and examples updated and working AFAICT NNTPClient has problems with group listings for large groups. - Key: NET-276 URL: https://issues.apache.org/jira/browse/NET-276 Project: Commons Net Issue Type: Bug Components: NNTP Affects Versions: 2.0 Reporter: Erik Fix For: 3.0 The following command causes a MalformedServerReplyException on my usenet server (astraweb): client.listNewsgroups(); Root Cause: Caused by: org.apache.commons.net.MalformedServerReplyException: alt.binaries.boneless 2230918506 1662764743 y at org.apache.commons.net.nntp.NNTPClient.__readNewsgroupListing(NNTPClient.java:255) at org.apache.commons.net.nntp.NNTPClient.listNewsgroups(NNTPClient.java:930) at org.lievaart.jleecher.protocol.CommandFactory$2.doOnServer(CommandFactory.java:27) at org.lievaart.jleecher.protocol.NNTPProtocol.callServer(NNTPProtocol.java:33) ... 2 more My hypothesis is that NNTP cannot parse the response, because one of the numbers exceeds the Integer range. Locally I have applied the following quick fix to get it to work: public class NNTPClient extends NNTP { ... ... ... private NewsgroupInfo __parseNewsgroupListEntry(final String entry) { NewsgroupInfo result; StringTokenizer tokenizer; int lastNum, firstNum; String last, first, permission; result = new NewsgroupInfo(); tokenizer = new StringTokenizer(entry); if (tokenizer.countTokens() 4) { return null; } result._setNewsgroup(tokenizer.nextToken()); last = tokenizer.nextToken(); first = tokenizer.nextToken(); permission = tokenizer.nextToken(); try { try { lastNum = Integer.parseInt(last); } catch (NumberFormatException nfe) { if (last.matches(\\d++)) { lastNum = Integer.MAX_VALUE; } else { throw nfe; } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CODEC-105) ArrayIndexOutOfBoundsException when doing multiple reads() on encoding Base64InputStream
[ https://issues.apache.org/jira/browse/CODEC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CODEC-105: --- Summary: ArrayIndexOutOfBoundsException when doing multiple reads() on encoding Base64InputStream (was: ArrayIndexOutOfBoundsException when doing multiple reads() on encoding b64InputStream) ArrayIndexOutOfBoundsException when doing multiple reads() on encoding Base64InputStream Key: CODEC-105 URL: https://issues.apache.org/jira/browse/CODEC-105 Project: Commons Codec Issue Type: Bug Affects Versions: 1.4 Environment: 64-bit Linux Reporter: ZAK Magnus Assignee: Julius Davies Fix For: 1.5 Attachments: codec-105-junit-including-ASL2-license.patch, codec-105.patch When encoding a sizable stream byte by byte (so, just calling Base64InputStream.read()), after 10920 successful read()s, this happens: java.lang.ArrayIndexOutOfBoundsException: 2 at org.apache.commons.codec.binary.Base64.encode(Base64.java:502) at org.apache.commons.codec.binary.Base64InputStream.read(Base64InputStream.java:157) at org.apache.commons.codec.binary.Base64InputStream.read(Base64InputStream.java:109) Based on this, the necessary conditions seem to be that buffer = null and modulus = 2. Then, if a read() is done, a single-byte buffer is used, whose length is doubled by resizeBuffer(), but that still doesn't make it big enough to hold the 4 bytes written to it because modulus was just incremented to 0. Here's some sample code: import org.apache.commons.codec.binary.Base64InputStream; public class TestReads { public static void main(String[] args) { Base64InputStream b64stream = new Base64InputStream(System.in, true, 0, null); int n = 0; try { while (b64stream.read() != -1) n++; } catch (Exception x) { System.out.println(n); x.printStackTrace(); } } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira