[jira] [Reopened] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[ https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikkel Meyer Andersen reopened MATH-790: Thomas Neidhart suspect an overflow issues is still present. Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets -- Key: MATH-790 URL: https://issues.apache.org/jira/browse/MATH-790 Project: Commons Math Issue Type: Bug Affects Versions: 3.0, Nightly Builds Environment: Ubuntu Linux x64, Sun Java 6 Reporter: James Pickering Assignee: Mikkel Meyer Andersen Priority: Minor Labels: newbie, patch Fix For: 3.1 Attachments: MannWhitnetUOVerflowPatch.diff Original Estimate: 1h Remaining Estimate: 1h When performing a Mann-Whitney U Test on large data sets (the attached test uses two 1500 element sets), intermediate integer values used in calculateAsymptoticPValue can overflow, leading to invalid results, such as p-values of NaN, or incorrect calculations. Attached is a patch, including a test, and a fix, which modifies the affected code to use doubles -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-469) Erroneous No route to host on upload failure
[
https://issues.apache.org/jira/browse/NET-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasco Figueira updated NET-469:
---
Remaining Estimate: 0h
Original Estimate: 0h
Erroneous No route to host on upload failure
--
Key: NET-469
URL: https://issues.apache.org/jira/browse/NET-469
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1
Environment: Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
Linux 2.6.39-gentoo-r3 #6 SMP PREEMPT Thu Dec 8 19:34:57 WET 2011 x86_64
Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux
Reporter: Vasco Figueira
Attachments: dump.txt
Original Estimate: 0h
Remaining Estimate: 0h
The example code at
http://commons.apache.org/net/examples/ftp/FTPClientExample.java
...fails to store a file in a remote server with:
java TestConnection -s 91.231.###.## ## file.csv file.csv
{{
220 Unauthorized access prohibited!
Connected to 91.231.###.## on 21
USER ***
331 Password required for ##.
PASS ***
230 User logged in.
SYST
215 Windows_NT
Remote system is Windows_NT
PASV
227 Entering Passive Mode (85,88,142,160,117,69).
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:762)
at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:565)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:557)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1795)
at
pt.knowledgeworks.emsa.mssim.scenario.TestConnection.main(TestConnection.java:285)
}}
Tcpdump in attachment. I'm no tcp expert to tell what's wrong with the dump.
Ping, traceroute and other ftp clients work without problems. Standard
command-line ftp managed to upload a file with no problems.
Originally discovered via wagon-ftp (mvn deploy).
Thanks in advance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-469) Erroneous No route to host on upload failure
[
https://issues.apache.org/jira/browse/NET-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293509#comment-13293509
]
Vasco Figueira commented on NET-469:
The command-line client was working because it was not entering passive mode.
If we force it to passive fails with the exact same error message.
Do tell me in case the tcpdump for the command-line passive-mode client is of
any use for you.
Thank you for your response. Site admins have been informed. Closing the issue
Erroneous No route to host on upload failure
--
Key: NET-469
URL: https://issues.apache.org/jira/browse/NET-469
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1
Environment: Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
Linux 2.6.39-gentoo-r3 #6 SMP PREEMPT Thu Dec 8 19:34:57 WET 2011 x86_64
Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux
Reporter: Vasco Figueira
Attachments: dump.txt
Original Estimate: 0h
Remaining Estimate: 0h
The example code at
http://commons.apache.org/net/examples/ftp/FTPClientExample.java
...fails to store a file in a remote server with:
java TestConnection -s 91.231.###.## ## file.csv file.csv
{{
220 Unauthorized access prohibited!
Connected to 91.231.###.## on 21
USER ***
331 Password required for ##.
PASS ***
230 User logged in.
SYST
215 Windows_NT
Remote system is Windows_NT
PASV
227 Entering Passive Mode (85,88,142,160,117,69).
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:762)
at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:565)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:557)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1795)
at
pt.knowledgeworks.emsa.mssim.scenario.TestConnection.main(TestConnection.java:285)
}}
Tcpdump in attachment. I'm no tcp expert to tell what's wrong with the dump.
Ping, traceroute and other ftp clients work without problems. Standard
command-line ftp managed to upload a file with no problems.
Originally discovered via wagon-ftp (mvn deploy).
Thanks in advance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (NET-469) Erroneous No route to host on upload failure
[
https://issues.apache.org/jira/browse/NET-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasco Figueira closed NET-469.
--
Resolution: Not A Problem
Erroneous No route to host on upload failure
--
Key: NET-469
URL: https://issues.apache.org/jira/browse/NET-469
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 3.1
Environment: Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
Linux 2.6.39-gentoo-r3 #6 SMP PREEMPT Thu Dec 8 19:34:57 WET 2011 x86_64
Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz GenuineIntel GNU/Linux
Reporter: Vasco Figueira
Attachments: dump.txt
Original Estimate: 0h
Remaining Estimate: 0h
The example code at
http://commons.apache.org/net/examples/ftp/FTPClientExample.java
...fails to store a file in a remote server with:
java TestConnection -s 91.231.###.## ## file.csv file.csv
{{
220 Unauthorized access prohibited!
Connected to 91.231.###.## on 21
USER ***
331 Password required for ##.
PASS ***
230 User logged in.
SYST
215 Windows_NT
Remote system is Windows_NT
PASV
227 Entering Passive Mode (85,88,142,160,117,69).
java.net.NoRouteToHostException: No route to host
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at
org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:762)
at org.apache.commons.net.ftp.FTPClient._storeFile(FTPClient.java:565)
at org.apache.commons.net.ftp.FTPClient.__storeFile(FTPClient.java:557)
at org.apache.commons.net.ftp.FTPClient.storeFile(FTPClient.java:1795)
at
pt.knowledgeworks.emsa.mssim.scenario.TestConnection.main(TestConnection.java:285)
}}
Tcpdump in attachment. I'm no tcp expert to tell what's wrong with the dump.
Ping, traceroute and other ftp clients work without problems. Standard
command-line ftp managed to upload a file with no problems.
Originally discovered via wagon-ftp (mvn deploy).
Thanks in advance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[
https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293552#comment-13293552
]
Thomas Neidhart commented on MATH-790:
--
As discussed on the ML, there may be still a problem with integer overflow in
the code fragment below:
{noformat}
final double n1n2prod = n1 * n2;
// http://en.wikipedia.org/wiki/Mann%E2%80%93Whitney_U#Normal_approximation
final double EU = n1n2prod / 2.0;
final double VarU = n1n2prod * (n1 + n2 + 1) / 12.0;
final double z = (Umin - EU) / FastMath.sqrt(VarU);
{noformat}
The calculation of n1n2prod may still overflow if n1 and n2 are too big as it
still does an int multiplication, so I would suggest to do it like that:
{noformat}
final long n1n2prod = (long) n1 * n2;
// http://en.wikipedia.org/wiki/Mann%E2%80%93Whitney_U#Normal_approximation
final double EU = n1n2prod / 2.0;
final double VarU = n1n2prod * (n1 + n2 + 1) / 12.0;
final double z = (Umin - EU) / FastMath.sqrt(VarU);
{noformat}
Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
--
Key: MATH-790
URL: https://issues.apache.org/jira/browse/MATH-790
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0, Nightly Builds
Environment: Ubuntu Linux x64, Sun Java 6
Reporter: James Pickering
Assignee: Mikkel Meyer Andersen
Priority: Minor
Labels: newbie, patch
Fix For: 3.1
Attachments: MannWhitnetUOVerflowPatch.diff
Original Estimate: 1h
Remaining Estimate: 1h
When performing a Mann-Whitney U Test on large data sets (the attached test
uses two 1500 element sets), intermediate integer values used in
calculateAsymptoticPValue can overflow, leading to invalid results, such as
p-values of NaN, or incorrect calculations.
Attached is a patch, including a test, and a fix, which modifies the affected
code to use doubles
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-420) SFTP : USING SLASH (/) SYMBOLS AS DIRECTORY NAME PREFIXES
airody prasad shetty created VFS-420: Summary: SFTP : USING SLASH (/) SYMBOLS AS DIRECTORY NAME PREFIXES Key: VFS-420 URL: https://issues.apache.org/jira/browse/VFS-420 Project: Commons VFS Issue Type: Bug Environment: IBM z/OS Reporter: airody prasad shetty When using SFTP with a directory whose name contains '//' as prefix which is common in IBM z/OS the following error occurs org.apache.commons.vfs.FileSystemException: Could not determine the type of file sftp://REMOTEHOST/DW.ORACLE.TEST/CH;. at org.apache.commons.vfs.provider.AbstractFileObject.attach(AbstractFileObject.j ava:1305) at org.apache.commons.vfs.provider.AbstractFileObject.getType(AbstractFileObject. java:412) at org.apache.commons.vfs.provider.AbstractFileObject.exists(AbstractFileObject.j ava:402) at org.apache.commons.vfs.provider.AbstractFileObject.isWriteable(AbstractFileObj ect.java:468) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.directoryContains
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Fix Version/s: 2.2 Add new function FileUtils.directoryContains Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.2 Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[
https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293633#comment-13293633
]
Mikkel Meyer Andersen commented on MATH-790:
Thanks for the details. Why not use a double immediately as below? Is it to
avoid precision loss?
{noformat}
final double n1n2prod = (double) n1 * n2;
// http://en.wikipedia.org/wiki/Mann%E2%80%93Whitney_U#Normal_approximation
final double EU = n1n2prod / 2.0;
final double VarU = n1n2prod * (n1 + n2 + 1) / 12.0;
final double z = (Umin - EU) / FastMath.sqrt(VarU);
{noformat}
Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
--
Key: MATH-790
URL: https://issues.apache.org/jira/browse/MATH-790
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.0, Nightly Builds
Environment: Ubuntu Linux x64, Sun Java 6
Reporter: James Pickering
Assignee: Mikkel Meyer Andersen
Priority: Minor
Labels: newbie, patch
Fix For: 3.1
Attachments: MannWhitnetUOVerflowPatch.diff
Original Estimate: 1h
Remaining Estimate: 1h
When performing a Mann-Whitney U Test on large data sets (the attached test
uses two 1500 element sets), intermediate integer values used in
calculateAsymptoticPValue can overflow, leading to invalid results, such as
p-values of NaN, or incorrect calculations.
Attached is a patch, including a test, and a fix, which modifies the affected
code to use doubles
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[ https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293640#comment-13293640 ] Thomas Neidhart commented on MATH-790: -- Actually yes, this was my intention (and long multiplication should be faster too ;-), but in this case it may be negligible. Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets -- Key: MATH-790 URL: https://issues.apache.org/jira/browse/MATH-790 Project: Commons Math Issue Type: Bug Affects Versions: 3.0, Nightly Builds Environment: Ubuntu Linux x64, Sun Java 6 Reporter: James Pickering Assignee: Mikkel Meyer Andersen Priority: Minor Labels: newbie, patch Fix For: 3.1 Attachments: MannWhitnetUOVerflowPatch.diff Original Estimate: 1h Remaining Estimate: 1h When performing a Mann-Whitney U Test on large data sets (the attached test uses two 1500 element sets), intermediate integer values used in calculateAsymptoticPValue can overflow, leading to invalid results, such as p-values of NaN, or incorrect calculations. Attached is a patch, including a test, and a fix, which modifies the affected code to use doubles -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[ https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293644#comment-13293644 ] Mikkel Meyer Andersen commented on MATH-790: I agree - I just wanted to have it in writing :-). Thanks for this. Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets -- Key: MATH-790 URL: https://issues.apache.org/jira/browse/MATH-790 Project: Commons Math Issue Type: Bug Affects Versions: 3.0, Nightly Builds Environment: Ubuntu Linux x64, Sun Java 6 Reporter: James Pickering Assignee: Mikkel Meyer Andersen Priority: Minor Labels: newbie, patch Fix For: 3.1 Attachments: MannWhitnetUOVerflowPatch.diff Original Estimate: 1h Remaining Estimate: 1h When performing a Mann-Whitney U Test on large data sets (the attached test uses two 1500 element sets), intermediate integer values used in calculateAsymptoticPValue can overflow, leading to invalid results, such as p-values of NaN, or incorrect calculations. Attached is a patch, including a test, and a fix, which modifies the affected code to use doubles -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-790) Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets
[ https://issues.apache.org/jira/browse/MATH-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikkel Meyer Andersen resolved MATH-790. Resolution: Fixed This second issue is fixed in SVN revision 1349372. Thanks again for reporting this issue, too. Mann-Whitney U Test Suffers From Integer Overflow With Large Data Sets -- Key: MATH-790 URL: https://issues.apache.org/jira/browse/MATH-790 Project: Commons Math Issue Type: Bug Affects Versions: 3.0, Nightly Builds Environment: Ubuntu Linux x64, Sun Java 6 Reporter: James Pickering Assignee: Mikkel Meyer Andersen Priority: Minor Labels: newbie, patch Fix For: 3.1 Attachments: MannWhitnetUOVerflowPatch.diff Original Estimate: 1h Remaining Estimate: 1h When performing a Mann-Whitney U Test on large data sets (the attached test uses two 1500 element sets), intermediate integer values used in calculateAsymptoticPValue can overflow, leading to invalid results, such as p-values of NaN, or incorrect calculations. Attached is a patch, including a test, and a fix, which modifies the affected code to use doubles -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-805) Percentile calculation is very slow when input data are constants
Benoit de Rancourt created MATH-805: --- Summary: Percentile calculation is very slow when input data are constants Key: MATH-805 URL: https://issues.apache.org/jira/browse/MATH-805 Project: Commons Math Issue Type: Improvement Affects Versions: 3.0 Reporter: Benoit de Rancourt Priority: Minor I use the Percentile class to calculate quantile on a big array (10^6 entries). When I have to test the performance of my code, I notice that the calculation of quantile is at least 100x slower when my data are constants (10^6 of the same nomber). Maybe the Percentile calculation can be improved for this special case. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-326) Add new FileUtils.sizeOf[Directory] APIs to return BigInteger
[ https://issues.apache.org/jira/browse/IO-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated IO-326: -- Attachment: IO-326.patch Fixing unused return value of BigInteger.add() Add new FileUtils.sizeOf[Directory] APIs to return BigInteger - Key: IO-326 URL: https://issues.apache.org/jira/browse/IO-326 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.3 Reporter: Gary D. Gregory Fix For: 2.4 Attachments: IO-326.patch FileUtils.sizeOfDirectory will return a negative number when the size count goes past Long.MAX_VALUE. Counting with a BigInteger will solve this issue. Options: - Change the signature of FileUtils.sizeOfDirectory() to return a BigInteger. This will obviously break BC. - Create a new API to return a BigInteger. What would this new API be called? -- sizeOfDirectoryAsBigInteger -- bigIntegerSizeOfDirectory -- largeSizeOfDirectory -- ...? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-397) [BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor with NoSuchMethodEceptions
[
https://issues.apache.org/jira/browse/SANDBOX-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293845#comment-13293845
]
Benedikt Ritter commented on SANDBOX-397:
-
Hi Simo,
I'm very happy to hear, that you liked my idea. Many thanks for your
improvements. Making {{BeanProperties}} publicly available is a good idea. Here
are some comments regarding your commit:
* Usually I try to avoid long return statements like the ones introduced
through {{checkMethod}} in {{DefaultBeanProperties}}. To much inlining can be
very confusing. However, since there isn't to much logic in those methods, I
guess we can leave it as it is.
* You should have a look at the extracted {{BeanProperties}} interface. I guess
your IDE refactoring created some public modifiers and some abstract method
declarations, that we can get rid of.
* I'm not happy about those methods in {{BeanProperties}} either, but at the
time I didn't have a better solution. Feel free to change what ever you like
(like you already did ;) )
regards,
Benedikt
[BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor
with NoSuchMethodEceptions
Key: SANDBOX-397
URL: https://issues.apache.org/jira/browse/SANDBOX-397
Project: Commons Sandbox
Issue Type: Task
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-397.txt, SANDBOX-397_SRP.txt,
SANDBOX-397_SRPv2.txt
At the moment, methods in {{DefaultBeanAccessor}} throw a
{{NullPointerException}}, if no {{PropertyDescriptor}} for a given property
name can be retrieved. As discussed on the ML (see
http://markmail.org/thread/zlehclmybp5xgn5n) this behavior should be changed
to throwing {{NoSuchMethodException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANDBOX-397) [BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor with NoSuchMethodEceptions
[
https://issues.apache.org/jira/browse/SANDBOX-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293876#comment-13293876
]
Simone Tripodi commented on SANDBOX-397:
guten abend Bene,
{quote}
Usually I try to avoid long return statements like the ones introduced through
{{checkMethod}} in {{DefaultBeanProperties}}. To much inlining can be very
confusing. However, since there isn't to much logic in those methods, I guess
we can leave it as it is.
{quote}
I am not sure I understood what you are referring -
{{DefaultBeanProperties#checkMethod()}} is similar to
{{Assertions#checkNotNull}} but they throw different exceptions...
{quote}
You should have a look at the extracted {{BeanProperties}} interface. I guess
your IDE refactoring created some public modifiers and some abstract method
declarations, that we can get rid of.
{quote}
hehehe yup perfectly right - I have been too lazy this time, thanks for
pointing!
{quote}
I'm not happy about those methods in {{BeanProperties}} either, but at the time
I didn't have a better solution. Feel free to change what ever you like (like
you already did ;) )
{quote}
nice to hear we found anyway an agreement!!
looking forward to apply more patches from you, alles gute!
[BeanUtils2] Replace NullPointerExceptions been thrown in DefaultBeanAccessor
with NoSuchMethodEceptions
Key: SANDBOX-397
URL: https://issues.apache.org/jira/browse/SANDBOX-397
Project: Commons Sandbox
Issue Type: Task
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Assignee: Simone Tripodi
Attachments: SANDBOX-397.txt, SANDBOX-397_SRP.txt,
SANDBOX-397_SRPv2.txt
At the moment, methods in {{DefaultBeanAccessor}} throw a
{{NullPointerException}}, if no {{PropertyDescriptor}} for a given property
name can be retrieved. As discussed on the ML (see
http://markmail.org/thread/zlehclmybp5xgn5n) this behavior should be changed
to throwing {{NoSuchMethodException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-336) Yottabyte (YB) incorrectly defined in FileUtils
Richard Leavelle created IO-336: --- Summary: Yottabyte (YB) incorrectly defined in FileUtils Key: IO-336 URL: https://issues.apache.org/jira/browse/IO-336 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.3 Reporter: Richard Leavelle Priority: Minor In FileUtils, a yottabyte is currently defined as follows: public static final BigInteger ONE_YB = ONE_ZB.multiply(BigInteger.valueOf(ONE_EB)); I believe this should be: public static final BigInteger ONE_YB = ONE_ZB.multiply(BigInteger.valueOf(ONE_KB)); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IO-336) Yottabyte (YB) incorrectly defined in FileUtils
[ https://issues.apache.org/jira/browse/IO-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved IO-336. Resolution: Fixed Fix Version/s: 2.4 Committed revision 1349509. Yottabyte (YB) incorrectly defined in FileUtils --- Key: IO-336 URL: https://issues.apache.org/jira/browse/IO-336 Project: Commons IO Issue Type: Bug Components: Utilities Affects Versions: 2.3 Reporter: Richard Leavelle Priority: Minor Fix For: 2.4 In FileUtils, a yottabyte is currently defined as follows: public static final BigInteger ONE_YB = ONE_ZB.multiply(BigInteger.valueOf(ONE_EB)); I believe this should be: public static final BigInteger ONE_YB = ONE_ZB.multiply(BigInteger.valueOf(ONE_KB)); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (SANDBOX-419) [BeanUtils2] Implement setIndexed(String propertyName) on DefaultBeanAccessor
Benedikt Ritter created SANDBOX-419:
---
Summary: [BeanUtils2] Implement setIndexed(String propertyName) on
DefaultBeanAccessor
Key: SANDBOX-419
URL: https://issues.apache.org/jira/browse/SANDBOX-419
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Implement {{DefaultBeanAccessor.setIndexed(String propertyName)}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SANDBOX-419) [BeanUtils2] Implement setIndexed(String propertyName) on DefaultBeanAccessor
[
https://issues.apache.org/jira/browse/SANDBOX-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated SANDBOX-419:
Attachment: SANDBOX-419.patch
I've created a patch for this issue. Summary:
* Changed {{DefaultIndexedPropertySetter}} to implement
{{IndexedPropertySetterAccessor}} (rather than
{{IndexedPropertyGetterAccessor}})
* Created a new implementation of {{BeanPropertySetter}} for indexed porperties.
However this patch only servers for the purpose of discussion, since I'm unsure
about two issues:
# name of the new {{BeanPropertySetter}} implementation: Maybe it should be
changed to IndexedBeanPropertySetter to make it clear that it is variant of
DefaultBeanPropertySetter
# checking of parameter types of the indexed setter method in
{{IndexedPropertySetter}}:
#* can we be sure that the first parameter type always will be of type int and
the second parameter type will be the type of the indexed property?
#* if so do we have to check if the first parameter is really of type int or do
we only have to check if the second parameter type is assignment compatible to
value?
After we have agreed on this points I can create a new patch (or you can simply
modify the patch).
[BeanUtils2] Implement setIndexed(String propertyName) on DefaultBeanAccessor
-
Key: SANDBOX-419
URL: https://issues.apache.org/jira/browse/SANDBOX-419
Project: Commons Sandbox
Issue Type: Improvement
Components: BeanUtils2
Affects Versions: Nightly Builds
Reporter: Benedikt Ritter
Attachments: SANDBOX-419.patch
Implement {{DefaultBeanAccessor.setIndexed(String propertyName)}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-49) Double-checked locking anti-pattern in OgnlRuntime
[
https://issues.apache.org/jira/browse/OGNL-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293921#comment-13293921
]
Simone Tripodi commented on OGNL-49:
while applying the patch, the {{patch}} command refuses 16 changes, maybe
because of the {{OgnlRuntime}} class evolvement - can you please double check?
TIA,
-Simo
Double-checked locking anti-pattern in OgnlRuntime
Key: OGNL-49
URL: https://issues.apache.org/jira/browse/OGNL-49
Project: Commons OGNL
Issue Type: Bug
Environment: java version 1.6.0_31
Java(TM) SE Runtime Environment (build 1.6.0_31-b04)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01, mixed mode)
Reporter: Matt Whitlock
Assignee: Simone Tripodi
Priority: Critical
Attachments:
0001-ognl-avoid-double-checked-locking-anti-pattern-in-Og.patch
OgnlRuntime in OGNL 3.0.5 has several occurrences of the double-checked
locking anti-pattern. This has already manifested in our product in the form
of:
ognl.MethodFailedException: Method xxx failed for object yyy
[java.lang.NoSuchMethodException: x.y.z.C.getFoo(java.lang.String)]
But method x.y.z.C.getFoo(String) does exist, and in fact the same OGNL
expression evaluates correctly when it is tried again subsequently.
There are 11 occurrences of double-checked locking in OgnlRuntime that must
be corrected. The simplest approach is to remove the unsynchronized accesses
to the guarded structures. A better approach would be to use ReadWriteLocks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
