[jira] Closed: (BEANUTILS-300) NPE in LazyDynaList
[ https://issues.apache.org/jira/browse/BEANUTILS-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell closed BEANUTILS-300. --- Resolution: Won't Fix Agreed. I suspect there's a way in which an NPE can happen, but that it's not realistic. Closing, given that BeanUtils appears to have dropped out of http://opensource.fortifysoftware.com/welcome.html > NPE in LazyDynaList > --- > > Key: BEANUTILS-300 > URL: https://issues.apache.org/jira/browse/BEANUTILS-300 > Project: Commons BeanUtils > Issue Type: Bug > Environment: Fortify >Reporter: Henri Yandell > Fix For: 1.8.0 > > > The transform() method does not protect lazyDynaClass from being null when > the new DynaBean is created. > Throw an exception? Or should the setElementType(..) call be joined by a > lazyDynaClass=...something -- 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-tabpanel&focusedCommentId=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.
[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: (VFS-118) Need for standard VFS JFileChooser implementation
[ https://issues.apache.org/jira/browse/VFS-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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.(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-74) AbstractMethodError when using httpclient v3.0.1
[ https://issues.apache.org/jira/browse/VFS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.(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.
