[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
