[jira] Commented: (SANDBOX-161) CSVPrinter#escapeAndQuote(String) doesn't adhere to CSV standard
[ https://issues.apache.org/jira/browse/SANDBOX-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988686#comment-12988686 ] Jacopo Cappellato commented on SANDBOX-161: --- Sebb, I have added the test cases in rev. 1065519 Thanks for the reminder. CSVPrinter#escapeAndQuote(String) doesn't adhere to CSV standard Key: SANDBOX-161 URL: https://issues.apache.org/jira/browse/SANDBOX-161 Project: Commons Sandbox Issue Type: Bug Components: CSV Affects Versions: Nightly Builds Reporter: Daniel Gredler Fix For: CSV 1.0 Attachments: commons-csv-patch-standard-escaping.txt All the descriptions of the CSV format that I've seen state that: - Double quotes () are escaped using two double quotes (), rather than a backslash (\). - Embedded line breaks are allowed and don't need to be escaped... just enclose the field in double quotes. - Because backslashes are not used to escape double quotes or line breaks, the backslashes themselves do not need to be escaped. CSVPrinter#escapeAndQuote(String) breaks these rules. Why? http://www.creativyst.com/Doc/Articles/CSV/CSV01.htm http://en.wikipedia.org/wiki/Comma-separated_values -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SANDBOX-219) ExtendedBufferedReader does too much
[ https://issues.apache.org/jira/browse/SANDBOX-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988694#comment-12988694 ] Jacopo Cappellato commented on SANDBOX-219: --- Is it ok if I commit Henri's patch? ExtendedBufferedReader does too much Key: SANDBOX-219 URL: https://issues.apache.org/jira/browse/SANDBOX-219 Project: Commons Sandbox Issue Type: Task Components: CSV Reporter: Henri Yandell Fix For: CSV 1.0 Attachments: SANDBOX-219.patch There is unnecessary work in ExtendedBufferedReader. It offers: skip(long) skipUntil(char) readUntil(char) none are ever called. skip(long) is required to fulfill the superclass, but could be stubbed out as it's never called. The class is also unnecessarily public for CSV's uses. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MATH-504) LOESS interpolation tricube fonction
[
https://issues.apache.org/jira/browse/MATH-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
X. B. updated MATH-504:
---
Description:
the doc for tricube fonction used in LOESS smooth() says :
* @return code(1 - |x|sup3/sup)sup3/sup/code.
But I'dont see the absolute value for x.
Also, the classical tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs( x )1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
was:
the doc for tricube fonction used in LOESS smooth() says :
* @return code(1 - |x|sup3/sup)sup3/sup/code.
But I'dont see the absolute value for x.
Also, the classical tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs(x)1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
LOESS interpolation tricube fonction
--
Key: MATH-504
URL: https://issues.apache.org/jira/browse/MATH-504
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Environment: Win XP
Reporter: X. B.
Priority: Trivial
Labels: loess
Original Estimate: 1h
Remaining Estimate: 1h
the doc for tricube fonction used in LOESS smooth() says :
* @return code(1 - |x|sup3/sup)sup3/sup/code.
But I'dont see the absolute value for x.
Also, the classical tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs( x )1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MATH-504) LOESS interpolation tricube fonction
LOESS interpolation tricube fonction
--
Key: MATH-504
URL: https://issues.apache.org/jira/browse/MATH-504
Project: Commons Math
Issue Type: Bug
Affects Versions: 2.1
Environment: Win XP
Reporter: X. B.
Priority: Trivial
the doc for tricube fonction used in LOESS smooth() says :
* @return code(1 - |x|sup3/sup)sup3/sup/code.
But I'dont see the absolute value for x.
Also, the classical tricube fonction (see
http://www.itl.nist.gov/div898/handbook/pmd/section1/pmd144.htm)
seems to return 0 if abs(x)1.
In the code of the tricube method, It is apparently not the case...
private static double tricube(final double x) {
final double tmp = 1 - x * x * x;
return tmp * tmp * tmp;
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-351) [POP3] [PATCH] APOP authentication fails most of the time
[POP3] [PATCH] APOP authentication fails most of the time - Key: NET-351 URL: https://issues.apache.org/jira/browse/NET-351 Project: Commons Net Issue Type: Bug Reporter: Bogdan Drozdowski The APOP authentication fails most of the time. Server replying -ERR Incorrect parameters and puts no authentication data in the log. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-352) [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication
[POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication --- Key: NET-352 URL: https://issues.apache.org/jira/browse/NET-352 Project: Commons Net Issue Type: New Feature Reporter: Bogdan Drozdowski Priority: Minor The POP3Client does not suppport the SASL PLAIN CRAM-MD5 authentication mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-352) [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication
[ https://issues.apache.org/jira/browse/NET-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-352: -- Attachment: ExtendedPOP3Client.java pop3-ex.diff The patch introduces new elements required by SASL. The java file should be put in the right place, if this patch is accepted. The class in the file extends the existing POP3Client class. [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication --- Key: NET-352 URL: https://issues.apache.org/jira/browse/NET-352 Project: Commons Net Issue Type: New Feature Reporter: Bogdan Drozdowski Priority: Minor Attachments: ExtendedPOP3Client.java, pop3-ex.diff Original Estimate: 0h Remaining Estimate: 0h The POP3Client does not suppport the SASL PLAIN CRAM-MD5 authentication mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NET-353) [SMTP] [PATCH] The SMTPClient does not support authentication
[SMTP] [PATCH] The SMTPClient does not support authentication - Key: NET-353 URL: https://issues.apache.org/jira/browse/NET-353 Project: Commons Net Issue Type: New Feature Reporter: Bogdan Drozdowski Priority: Minor The SMTPClient java class doesn't support any kind of client authentication. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-353) [SMTP] [PATCH] The SMTPClient does not support authentication
[ https://issues.apache.org/jira/browse/NET-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bogdan Drozdowski updated NET-353: -- Attachment: AuthenticatingSMTPClient.java This class implements the SASL PLAIN CRAM-MD5 and Microsoft LOGIN authentication mechanisms. It also provides the AUTH and EHLO commands and parsing enhanced status codes. [SMTP] [PATCH] The SMTPClient does not support authentication - Key: NET-353 URL: https://issues.apache.org/jira/browse/NET-353 Project: Commons Net Issue Type: New Feature Reporter: Bogdan Drozdowski Priority: Minor Attachments: AuthenticatingSMTPClient.java Original Estimate: 0h Remaining Estimate: 0h The SMTPClient java class doesn't support any kind of client authentication. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-351) [POP3] [PATCH] APOP authentication fails most of the time
[ https://issues.apache.org/jira/browse/NET-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-351. -- Resolution: Fixed Thanks very much for the report and patch. [POP3] [PATCH] APOP authentication fails most of the time - Key: NET-351 URL: https://issues.apache.org/jira/browse/NET-351 Project: Commons Net Issue Type: Bug Reporter: Bogdan Drozdowski Assignee: Sebb Attachments: pop3-apop.diff Original Estimate: 0h Remaining Estimate: 0h The APOP authentication fails most of the time. Server replying -ERR Incorrect parameters and puts no authentication data in the log. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-351) [POP3] [PATCH] APOP authentication fails most of the time
[ https://issues.apache.org/jira/browse/NET-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-351: - Affects Version/s: 2.2 [POP3] [PATCH] APOP authentication fails most of the time - Key: NET-351 URL: https://issues.apache.org/jira/browse/NET-351 Project: Commons Net Issue Type: Bug Affects Versions: 2.2 Reporter: Bogdan Drozdowski Assignee: Sebb Attachments: pop3-apop.diff Original Estimate: 0h Remaining Estimate: 0h The APOP authentication fails most of the time. Server replying -ERR Incorrect parameters and puts no authentication data in the log. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (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 updated NET-276:
-
Component/s: NNTP
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] Closed: (NET-336) Avoid releasing version 2.1 of commons-net. Use 2.1.1 or other instead
[ https://issues.apache.org/jira/browse/NET-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb closed NET-336. Avoid releasing version 2.1 of commons-net. Use 2.1.1 or other instead -- Key: NET-336 URL: https://issues.apache.org/jira/browse/NET-336 Project: Commons Net Issue Type: Task Affects Versions: 2.1 Reporter: John Casey Fix For: 2.2 I've been tracking some problems building jboss drools 5.1.0, specifically where Maven can't locate commons-net 2.1. http://anonsvn.jboss.org/repos/labs/labs/jbossrules/tags/5.1.0.34406.FINAL/pom.xml (search for commons-net) Looking in Maven central (http://repo1.maven.org/maven2/commons-net/commons-net/) I cannot find commons-net 2.1. Looking in the Maven-Central proxies from repository.sonatype.org and repository.jboss.org, however, I *did* find it. When I looked at the SVN tags for commons-net, I see that a 2.1 release was rolled back in July 2010. It appears that this release, while rolled back in SVN and on Maven central, has escaped into the wild before it could be un-released. Maven and most Maven repository managers will NOT re-check a non-snapshot version of an artifact once it's been downloaded. This is somewhat like trying to un-send an email... What this means is, if you release a real commons-net 2.1 sometime in the future, you're going to have a ton of confusion over which version of that artifact is in a user's Maven local repository and ultimately, his build classpath. I strongly urge you to change the next release version to 2.1.1 or something beyond 2.1, and simply write off that 2.1 version altogether. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-336) Avoid releasing version 2.1 of commons-net. Use 2.1.1 or other instead
[ https://issues.apache.org/jira/browse/NET-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-336. -- Resolution: Fixed We released 2.2 Avoid releasing version 2.1 of commons-net. Use 2.1.1 or other instead -- Key: NET-336 URL: https://issues.apache.org/jira/browse/NET-336 Project: Commons Net Issue Type: Task Affects Versions: 2.1 Reporter: John Casey Fix For: 2.2 I've been tracking some problems building jboss drools 5.1.0, specifically where Maven can't locate commons-net 2.1. http://anonsvn.jboss.org/repos/labs/labs/jbossrules/tags/5.1.0.34406.FINAL/pom.xml (search for commons-net) Looking in Maven central (http://repo1.maven.org/maven2/commons-net/commons-net/) I cannot find commons-net 2.1. Looking in the Maven-Central proxies from repository.sonatype.org and repository.jboss.org, however, I *did* find it. When I looked at the SVN tags for commons-net, I see that a 2.1 release was rolled back in July 2010. It appears that this release, while rolled back in SVN and on Maven central, has escaped into the wild before it could be un-released. Maven and most Maven repository managers will NOT re-check a non-snapshot version of an artifact once it's been downloaded. This is somewhat like trying to un-send an email... What this means is, if you release a real commons-net 2.1 sometime in the future, you're going to have a ton of confusion over which version of that artifact is in a user's Maven local repository and ultimately, his build classpath. I strongly urge you to change the next release version to 2.1.1 or something beyond 2.1, and simply write off that 2.1 version altogether. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-338) ftp.FTPClient.initiateListParsing(String parserKey, String pathname) can call createFileEntryParser with null systemName
[ https://issues.apache.org/jira/browse/NET-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-338: - Component/s: FTP ftp.FTPClient.initiateListParsing(String parserKey, String pathname) can call createFileEntryParser with null systemName Key: NET-338 URL: https://issues.apache.org/jira/browse/NET-338 Project: Commons Net Issue Type: Improvement Components: FTP Reporter: Sebb ftp.FTPClient.initiateListParsing(String parserKey, String pathname) can call createFileEntryParser(String) with null systemName if the getSystemName() method fails. The resulting ParserInitializationException does not identify the cause. It would be better to throw a more specific error if the system name cannot be found. Ideally, getSystemName() should throw the error, but that would change the documented behaviour (null is specifically allowed as a return value). As it happens, getSystemName() is badly named, so one way forward is to create a new method getSystemType() which never returns null. Can then deprecate getSystemName(). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-352) [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication
[ https://issues.apache.org/jira/browse/NET-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-352: - Component/s: POP3 [POP3] [PATCH] SASL PLAIN CRAM-MD5 authentication --- Key: NET-352 URL: https://issues.apache.org/jira/browse/NET-352 Project: Commons Net Issue Type: New Feature Components: POP3 Reporter: Bogdan Drozdowski Priority: Minor Attachments: ExtendedPOP3Client.java, pop3-ex.diff Original Estimate: 0h Remaining Estimate: 0h The POP3Client does not suppport the SASL PLAIN CRAM-MD5 authentication mechanisms. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-317) POP3MessageInfo fields should be final
[ https://issues.apache.org/jira/browse/NET-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-317: - Component/s: POP3 POP3MessageInfo fields should be final -- Key: NET-317 URL: https://issues.apache.org/jira/browse/NET-317 Project: Commons Net Issue Type: Bug Components: POP3 Affects Versions: 2.0 Reporter: Sebb Fix For: 3.0 The 3 public instance fields in POP3MessageInfo should be made final. AFAICT, there's no use case for allowing them to be changed externally. They are not written by current code, but changing them to final would change the API - hence fix version set to 3.0 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-353) [SMTP] [PATCH] The SMTPClient does not support authentication
[ https://issues.apache.org/jira/browse/NET-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated NET-353: - Component/s: SMTP [SMTP] [PATCH] The SMTPClient does not support authentication - Key: NET-353 URL: https://issues.apache.org/jira/browse/NET-353 Project: Commons Net Issue Type: New Feature Components: SMTP Reporter: Bogdan Drozdowski Priority: Minor Attachments: AuthenticatingSMTPClient.java Original Estimate: 0h Remaining Estimate: 0h The SMTPClient java class doesn't support any kind of client authentication. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COLLECTIONS-371) BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection)
BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection,
Collection)
--
Key: COLLECTIONS-371
URL: https://issues.apache.org/jira/browse/COLLECTIONS-371
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2
Reporter: li gui
Priority: Critical
line: 1121
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove); // here
absolutely wrong!
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (NET-222) Implement threadsafety annotations: @ThreadSafe, @Immutable etc
[ https://issues.apache.org/jira/browse/NET-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988859#comment-12988859 ] Sebb commented on NET-222: -- Note: some versions of the javax.concurrent.annotations have Retention=Runtime which will cause problems. Implement threadsafety annotations: @ThreadSafe, @Immutable etc --- Key: NET-222 URL: https://issues.apache.org/jira/browse/NET-222 Project: Commons Net Issue Type: Wish Reporter: Sebb Priority: Trivial It would be very helpful for maintaing and checking code if the classes and fields were updated with the thread-safety annotations: @Immutable @Threadsafe @NotThreadsafe @GuardedBy These can be used by tools such as Findbugs to check that code conforms to the annotations -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[ https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988978#comment-12988978 ] Phil Steitz commented on MATH-505: -- What fields, exactly? TestUtils is thread-hostile --- Key: MATH-505 URL: https://issues.apache.org/jira/browse/MATH-505 Project: Commons Math Issue Type: Bug Affects Versions: 1.2, 2.1 Reporter: Sebb TestUtils has several mutable static fields which are not synchronised, or volatile. If one of the fields is updated by thread A, there is no guarantee that thread B will see the full update - it may see a partially updated object. Furthermore, at least some of the static fields reference a mutable object, which can be changed whilst another thread is using it. As far as I can tell, this class must only ever be used by a single thread otherwise the results will be unpredictable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[
https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988980#comment-12988980
]
Sebb commented on MATH-505:
---
{code}
/** Singleton TTest instance using default implementation. */
private static TTest tTest = new TTestImpl();
/** Singleton ChiSquareTest instance using default implementation. */
private static ChiSquareTest chiSquareTest =
new ChiSquareTestImpl();
/** Singleton ChiSquareTest instance using default implementation. */
private static UnknownDistributionChiSquareTest
unknownDistributionChiSquareTest =
new ChiSquareTestImpl();
/** Singleton OneWayAnova instance using default implementation. */
private static OneWayAnova oneWayAnova =
new OneWayAnovaImpl();
{code}
All of the above may be changed by set methods. There is no synch.
TestUtils is thread-hostile
---
Key: MATH-505
URL: https://issues.apache.org/jira/browse/MATH-505
Project: Commons Math
Issue Type: Bug
Affects Versions: 1.2, 2.1
Reporter: Sebb
TestUtils has several mutable static fields which are not synchronised, or
volatile.
If one of the fields is updated by thread A, there is no guarantee that
thread B will see the full update - it may see a partially updated object.
Furthermore, at least some of the static fields reference a mutable object,
which can be changed whilst another thread is using it.
As far as I can tell, this class must only ever be used by a single thread
otherwise the results will be unpredictable.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[ https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12988986#comment-12988986 ] Phil Steitz commented on MATH-505: -- OK, I was looking at the wrong TestUtils :) The reason for this strange-looking setup is to allow the implementations to be pluggable at runtime. Hostile is a harsh word, but this class is certainly *not* threadsafe. Ideas / patches to achieve the design goal with less hostility would be appreciated. I would have to double-check, but I don't think that there is any test instance state used by the methods in this class. TestUtils is thread-hostile --- Key: MATH-505 URL: https://issues.apache.org/jira/browse/MATH-505 Project: Commons Math Issue Type: Bug Affects Versions: 1.2, 2.1 Reporter: Sebb TestUtils has several mutable static fields which are not synchronised, or volatile. If one of the fields is updated by thread A, there is no guarantee that thread B will see the full update - it may see a partially updated object. Furthermore, at least some of the static fields reference a mutable object, which can be changed whilst another thread is using it. As far as I can tell, this class must only ever be used by a single thread otherwise the results will be unpredictable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[ https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12989013#comment-12989013 ] Sebb commented on MATH-505: --- By thread-hostile, I mean that it is not possible in general for two different threads to use the class safely. If one thread changes any of the static fields, there is no way of knowing how the methods called by the other thread will behave. This is partly because the values are not safely published currently, but even if they were, the threads don't know what settings will be used as they can be changed at any time by another thread. In general, any class which relies on mutable static state for its behaviour is thread-hostile. The shared state cannot simultaneously satisfy two threads needing different behaviour. I think the only safe way for two threads to use the class as it stands is if they both synchronize on the class. This will ensure safe publication of any field changes, and enforce serial usage which can guarantee the setting that will be used (but the lock will have to be held for the set call as well). ChiSquareTestImpl has a non-final instance field which means its value won't necessarily be safely published. The field also has a setter which could be invoked by one thread while another was using it. TTestImpl is immutable (has no fields), and OneWayAnovaImpl can be made immutable, but other implementations of the interfaces might exist which are not immutable. The simplest way to make the class thread-safe would be to convert all the methods and fields from static to instance, but I don't know if that is acceptable. TestUtils is thread-hostile --- Key: MATH-505 URL: https://issues.apache.org/jira/browse/MATH-505 Project: Commons Math Issue Type: Bug Affects Versions: 1.2, 2.1 Reporter: Sebb TestUtils has several mutable static fields which are not synchronised, or volatile. If one of the fields is updated by thread A, there is no guarantee that thread B will see the full update - it may see a partially updated object. Furthermore, at least some of the static fields reference a mutable object, which can be changed whilst another thread is using it. As far as I can tell, this class must only ever be used by a single thread otherwise the results will be unpredictable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[ https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12989039#comment-12989039 ] Phil Steitz commented on MATH-505: -- Making the methods instance sort of defeats the purpose of the class. None of the instance data in any of the static singletons is actually used or depended on by the methods of this class. You are correct though that if one thread changes the impl for one of the singletons while another is using the class, the other could see a different than expected impl. I think the practical likelihood of this is pretty much nil, as it is hard to imagine an application supplying two different implementations for the tests and wanting different threads to use different impls. Personally, I would be happy just documenting the fact that the class is not threadsafe and if concurrent threads want to plug in different implementations, they need to synchronize on the class. If this is not acceptable, my next preference would be to remove the pluggability - i.e., make the singletons final or get rid of them altogether, creating instances as needed for static method calls. There is no initialization overhead creating the test classes. TestUtils is thread-hostile --- Key: MATH-505 URL: https://issues.apache.org/jira/browse/MATH-505 Project: Commons Math Issue Type: Bug Affects Versions: 1.2, 2.1 Reporter: Sebb TestUtils has several mutable static fields which are not synchronised, or volatile. If one of the fields is updated by thread A, there is no guarantee that thread B will see the full update - it may see a partially updated object. Furthermore, at least some of the static fields reference a mutable object, which can be changed whilst another thread is using it. As far as I can tell, this class must only ever be used by a single thread otherwise the results will be unpredictable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MATH-505) TestUtils is thread-hostile
[ https://issues.apache.org/jira/browse/MATH-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12989071#comment-12989071 ] Joerg Schaible commented on MATH-505: - @Phil: Please also keep in mind that M3 supports now (currently optional) parallel execution and it might be no longer a proper assumption that all tests are executed serially. TestUtils is thread-hostile --- Key: MATH-505 URL: https://issues.apache.org/jira/browse/MATH-505 Project: Commons Math Issue Type: Bug Affects Versions: 1.2, 2.1 Reporter: Sebb TestUtils has several mutable static fields which are not synchronised, or volatile. If one of the fields is updated by thread A, there is no guarantee that thread B will see the full update - it may see a partially updated object. Furthermore, at least some of the static fields reference a mutable object, which can be changed whilst another thread is using it. As far as I can tell, this class must only ever be used by a single thread otherwise the results will be unpredictable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COLLECTIONS-371) BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection, Collection)
[
https://issues.apache.org/jira/browse/COLLECTIONS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Schaible closed COLLECTIONS-371.
--
Resolution: Duplicate
BUG in org.apache.commons.collections.CollectionUtils.removeAll(Collection,
Collection)
--
Key: COLLECTIONS-371
URL: https://issues.apache.org/jira/browse/COLLECTIONS-371
Project: Commons Collections
Issue Type: Bug
Components: Collection
Affects Versions: 3.2
Reporter: li gui
Priority: Critical
line: 1121
public static Collection removeAll(Collection collection, Collection remove) {
return ListUtils.retainAll(collection, remove); // here
absolutely wrong!
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
