[jira] Commented: (VFS-74) AbstractMethodError when using httpclient v3.0.1
[ https://issues.apache.org/jira/browse/VFS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586076#action_12586076 ] Jason Harrop commented on VFS-74: - Regarding the URL encoding, I did find one problem. I'm attaching an updated patch. AbstractMethodError when using httpclient v3.0.1 Key: VFS-74 URL: https://issues.apache.org/jira/browse/VFS-74 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Maarten Coene Fix For: later Attachments: WebdavConnectionManager.java.patch, work-with-httpclient-3.01.patch Hi, when you use VFS in combination with commons httpclient 3.0.1, you get an AbstractMethodError: java.lang.AbstractMethodError at org.apache.commons.httpclient.HttpClient.setHttpConnectionManager(HttpClient.java:472) at org.apache.commons.vfs.provider.webdav.WebdavClientFactory.createConnection(WebdavClientFactory.java:82) at org.apache.commons.vfs.provider.webdav.WebdavFileProvider.doCreateFileSystem(WebdavFileProvider.java:85) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:76) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:640) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:601) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:569) at fr.jayasoft.ivy.repository.vfs.VfsResource.init(VfsResource.java:39) at fr.jayasoft.ivy.repository.vfs.VfsRepository.put(VfsRepository.java:159) at fr.jayasoft.ivy.resolver.RepositoryResolver.put(RepositoryResolver.java:173) at fr.jayasoft.ivy.resolver.RepositoryResolver.publish(RepositoryResolver.java:168) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2079) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2063) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2044) at fr.jayasoft.ivy.ant.IvyPublish.execute(IvyPublish.java:195) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (VFS-74) AbstractMethodError when using httpclient v3.0.1
[ https://issues.apache.org/jira/browse/VFS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Harrop updated VFS-74: Attachment: work-with-httpclient-3.01.patch AbstractMethodError when using httpclient v3.0.1 Key: VFS-74 URL: https://issues.apache.org/jira/browse/VFS-74 Project: Commons VFS Issue Type: Bug Affects Versions: Nightly Builds Reporter: Maarten Coene Fix For: later Attachments: WebdavConnectionManager.java.patch, work-with-httpclient-3.01.patch Hi, when you use VFS in combination with commons httpclient 3.0.1, you get an AbstractMethodError: java.lang.AbstractMethodError at org.apache.commons.httpclient.HttpClient.setHttpConnectionManager(HttpClient.java:472) at org.apache.commons.vfs.provider.webdav.WebdavClientFactory.createConnection(WebdavClientFactory.java:82) at org.apache.commons.vfs.provider.webdav.WebdavFileProvider.doCreateFileSystem(WebdavFileProvider.java:85) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:76) at org.apache.commons.vfs.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:640) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:601) at org.apache.commons.vfs.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:569) at fr.jayasoft.ivy.repository.vfs.VfsResource.init(VfsResource.java:39) at fr.jayasoft.ivy.repository.vfs.VfsRepository.put(VfsRepository.java:159) at fr.jayasoft.ivy.resolver.RepositoryResolver.put(RepositoryResolver.java:173) at fr.jayasoft.ivy.resolver.RepositoryResolver.publish(RepositoryResolver.java:168) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2079) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2063) at fr.jayasoft.ivy.Ivy.publish(Ivy.java:2044) at fr.jayasoft.ivy.ant.IvyPublish.execute(IvyPublish.java:195) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (VFS-118) Need for standard VFS JFileChooser implementation
[ https://issues.apache.org/jira/browse/VFS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586077#action_12586077 ] Jason Harrop commented on VFS-118: -- See http://vfsjfilechooser.sourceforge.net/ That site also links to an SWT implementation at http://commons-vfs-ui.sourceforge.net/ Need for standard VFS JFileChooser implementation - Key: VFS-118 URL: https://issues.apache.org/jira/browse/VFS-118 Project: Commons VFS Issue Type: Improvement Affects Versions: later Environment: All. Reporter: Ludovic Maître I have searched the web several time and haven't find any standard Commons VFS (J)FileChooser. I really would like to have a component like this (with a Swing implementation and if possible a SWT equivalent), this would greatly help me and any developer adding commons-vfs support to desktop applications. I have under my hand at least ArgoUML and FreeMind which could be easily extended to support commons-vfs if such a component exist. And this is only the softwares i follow/contribute, i'm such a lot of java software could benefit of this. So if a good people would like to contribute this i would be more than happy. If noboy does it, well, i guess i will tackle this in the futur, but i would prefer to let an expert in UI do it :-) (if there is such a contributor to commons-vfs). Thanks in advance, -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MATH-201) T-test p-value precision hampered by machine epsilon
[ https://issues.apache.org/jira/browse/MATH-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved MATH-201. --- Resolution: Fixed Fix Version/s: 1.3 SVN 645193. Changes applied. Thank you for reporting this issue. T-test p-value precision hampered by machine epsilon Key: MATH-201 URL: https://issues.apache.org/jira/browse/MATH-201 Project: Commons Math Issue Type: Bug Affects Versions: 1.2 Reporter: Peter Wyngaard Assignee: Brent Worden Priority: Minor Fix For: 1.3 The smallest p-value returned by TTestImpl.tTest() is the machine epsilon, which is 2.220446E-16 with IEEE754 64-bit double precision floats. We found this bug porting some analysis software from R to java, and noticed that the p-values did not match up. We believe we've identified why this is happening in commons-math-1.2, and a possible solution. Please be gentle, as I am not a statistics expert! The following method in org.apache.commons.math.stat.inference.TTestImpl currently implements the following method to calculate the p-value for a 2-sided, 2-sample t-test: protected double tTest(double m1, double m2, double v1, double v2, double n1, double n2) and it returns: 1.0 - distribution.cumulativeProbability(-t, t); at line 1034 in version 1.2. double cumulativeProbability(double x0, double x1) is implemented by org.apache.commons.math.distribution.AbstractDisstribution, and returns: return cumulativeProbability(x1) - cumulativeProbability(x0); So in essence, the p-value returned by TTestImpl.tTest() is: 1.0 - (cumulativeProbability(t) - cumulativeProbabily(-t)) For large-ish t-statistics, cumulativeProbabilty(-t) can get quite small, and cumulativeProbabilty(t) can get very close to 1.0. When cumulativeProbability(-t) is less than the machine epsilon, we get p-values equal to zero because: 1.0 - 1.0 + 0.0 = 0.0 An alternative calculation for the p-value of a 2-sided, 2-sample t-test is: p = 2.0 * cumulativeProbability(-t) This calculation does not suffer from the machine epsilon problem, and we are now getting p-values much smaller than the 2.2E-16 limit we were seeing previously. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (COLLECTIONS-246) LoopingListIterator behaves unexpected on next and previous mixed
[
https://issues.apache.org/jira/browse/COLLECTIONS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12586084#action_12586084
]
Henri Yandell commented on COLLECTIONS-246:
---
Can you restate your failing test? Looking at the description, I was taking it
as:
{code:java}
ArrayList al = new ArrayList();
al.add(0);
al.add(1);
al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
{code}
Your statement here is incorrect - the answer should be 0 not 2. This is the
base of your misunderstanding - you are not on 0, you are before 0. I think
that's a part of the java.util.Iterator concept; and that we shouldn't
implement an alternative to java.util.Iterator as it would lead to having to
write lots of code.
LoopingListIterator behaves unexpected on next and previous mixed
-
Key: COLLECTIONS-246
URL: https://issues.apache.org/jira/browse/COLLECTIONS-246
Project: Commons Collections
Issue Type: Bug
Components: Iterator
Affects Versions: 3.2
Environment: JDK 1.4.2_12
Common Collections 3.2
Reporter: Frank Hefter
Priority: Blocker
Fix For: 3.3
Attachments: LoopingListIterator.java, LoopingListIterator.java,
LoopingListIteratorTest.java
Using ArrayList as the backing list.
This combination at least returns unexpected results as you can see in the
testcase below.
I used this for a list navigator in a web frontend and had trouble with users.
I suspect java.util.AbstrList$ListItr (role of cursor var seems to be wrong
implemented ) to cause this problem. If so maybe we have to implement it in a
different way.
Testcase (it runs without hassle but the comments show whats wrong):
---
import java.util.ArrayList;
import junit.framework.TestCase;
import org.apache.commons.collections.iterators.LoopingListIterator;
public class SelectionControllerTest extends TestCase {
public void testSelectorForApache() {
ArrayList al = new ArrayList();
al.add(0); al.add(1); al.add(2);
LoopingListIterator it = new LoopingListIterator(al);
assertEquals(0, it.next()); // This is OK
// here I am on 0
assertEquals(0, it.previous()); // Wrong ! This should be 2!
// here I am on 0 too! This is wrong.
assertEquals(2, it.previous());
assertEquals(1, it.previous());
assertEquals(0, it.previous());
assertEquals(2, it.previous());
// here I am on 2
assertEquals(2, it.next()); // Wrong ! This should be 0!
// here I am on 2 too! This is wrong.
assertEquals(0, it.next());
assertEquals(1, it.next());
// here I am on 1
assertEquals(1, it.previous()); // Wrong ! This should be 0!
}
}
---
Thanks for your help.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
