date:20130313


 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simone Tripodi resolved FILEUPLOAD-212.
---

Resolution: Fixed

resolved by [~tn]'s in r1455729

 Insecure request size checking
 --

 Key: FILEUPLOAD-212
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-212
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.2.2
 Environment: Default configuration default environment.
Reporter: Damian Kolasa
Assignee: Thomas Neidhart
Priority: Critical
  Labels: max_upload_size, resource_depletion, security
 Fix For: 1.3

 Attachments: FILEUPLOAD-212_fix.patch, FILEUPLOAD-212_test.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 In FileUploadBase there is an issue when checking for upload request size, 
 the check is based on presence of Content-Length header in request and FALSE 
 assumption that when present it will represent the actual request size. Using 
 this fact, attacker can supply request with defined Content-Length of 60 and 
 bypass file upload restrictions, which can lead to successful Resource 
 Depletion type attack. 
 IMHO by default file upload should return the LimitedInputStream 
 implementation for file upload.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (FILEUPLOAD-202) org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. Stream ended unexpectedly


 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simone Tripodi updated FILEUPLOAD-202:
--

Fix Version/s: 1.3

 org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: 
 Processing of multipart/form-data request failed. Stream ended unexpectedly
 ---

 Key: FILEUPLOAD-202
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-202
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: tina
  Labels: fileupload
 Fix For: 1.3

   Original Estimate: 1h
  Remaining Estimate: 1h

 I used this one to write the servlet
 http://www.servletworld.com/servlet-tutorials/servlet-file-upload-example.html
 I can successfully upload the file through localhost, however, when I use 
 Jmeter to test the app server using 300 threads, it
 will report this error:
 [10:40:23.577] {http--8080-244$1283730842} 
 WebApp[http://localhost:8080/OrderFile] CommonsFileUploadServlet: Error 
 encountered while parsing the request
 [10:40:23.577] {http--8080-244$1283730842} 
 org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: 
 Processing of multipart/form-data request failed. Stream ended unexpectedly
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:371)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
 [10:40:23.577] {http--8080-244$1283730842}at 
 CommonsFileUploadServlet.doPost(CommonsFileUploadServlet.java:66)
 [10:40:23.577] {http--8080-244$1283730842}at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:153)
 [10:40:23.577] {http--8080-244$1283730842}at 
 javax.servlet.http.HttpServlet.service(HttpServlet.java:91)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:103)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.server.webapp.WebAppFilterChain.doFilter(WebAppFilterChain.java:187)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.server.dispatch.ServletInvocation.service(ServletInvocation.java:265)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:273)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.server.port.TcpConnection.run(TcpConnection.java:682)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.util.ThreadPool$Item.runTasks(ThreadPool.java:743)
 [10:40:23.577] {http--8080-244$1283730842}at 
 com.caucho.util.ThreadPool$Item.run(ThreadPool.java:662)
 [10:40:23.577] {http--8080-244$1283730842}at 
 java.lang.Thread.run(Thread.java:619)
 [10:40:23.577] {http--8080-244$1283730842} Caused by: 
 org.apache.commons.fileupload.MultipartStream$MalformedStreamException: 
 Stream ended unexpectedly
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:982)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:886)
 [10:40:23.577] {http--8080-244$1283730842}at 
 java.io.FilterInputStream.read(FilterInputStream.java:116)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.util.LimitedInputStream.read(LimitedInputStream.java:125)
 [10:40:23.577] {http--8080-244$1283730842}at 
 java.io.FilterInputStream.read(FilterInputStream.java:90)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.util.Streams.copy(Streams.java:96)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.util.Streams.copy(Streams.java:66)
 [10:40:23.577] {http--8080-244$1283730842}at 
 org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:366)
 [10:40:23.577] {http--8080-244$1283730842}... 12 more
 Is it because of the size limit? the uploaded file size is 8KB.
 Thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Othmen TILIOUINE updated COLLECTIONS-448:
-

Description: 
Hello,

This is a patch to add two methods to Bag interface and classes
public E pick();
public E pickAndRemit();
as discussed in this mail.
-
http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
I just saw the Bag interface and its implementations, I'm surprised that Bag 
T (and none of these implementations) expose the method
public T pick() and public T pickAndRemit() (pick a random element)
The Bag object we see in nature, it is mainly used to this, that's why it is 
widely used in the probability that when I met 2 white balls and one black, 
when I draw a ball randomly I have 2 times more likely to have a white ball

I think that if this caracteristic exists it would be very valuable.
--


these methods pick a random element from the bag, The probability of picking a 
copy of a given element is proportional to the number of copies of this element 
in the bag.
the diference between pick() and pickAndRemit() is that with pick() the picked 
element is not removed from the bag. 

this is my first contribution on open source project 

if you accept to add this feature to bags and validate my patch i will add one 
other patch to add this methods

public IteratorE pick(int n); //pick random n element (with remove)
public IteratorE pickAndRemit(int n) ; //pick random n element (without 
remove)


-Question : should i regenerate the serialVersionUID of classes that i have 
changed ?

Othmen TILIOUINE

  was:
Hello,

This is a patch to add row methods to Bag interfaces and classes
public E pick();
public E pickAndRemit();
as discussed in this mail.
-
http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
I just saw the Bag interface and its implementations, I'm surprised that Bag 
T (and none of these implementations) expose the method
public T pick() and public T pickAndRemit() (pick a random element)
The Bag object we see in nature, it is mainly used to this, that's why it is 
widely used in the probability that when I met 2 white balls and one black, 
when I draw a ball randomly I have 2 times more likely to have a white ball

I think that if this caracteristic exists it would be very valuable.
--


these methods pick a random element from the bag, The probability of picking a 
copy of a given element is proportional to the number of copies of this element 
in the bag.
the diference between pick() and pickAndRemit() is that with pick() the picked 
element is not removed from the bag. 

this is my first contribution on open source project 

if you accept to add this feature to bags and validate my patch i will add one 
other patch to add this methods

public IteratorE pick(int n); //pick random n element (with remove)
public IteratorE pickAndRemit(int n) ; //pick random n element (without 
remove)


-Question : should i regenerate the serialVersionUID of classes that i have 
changed ?

Othmen TILIOUINE


 [PATCH] Proposal for addinig random pick methods to Bags
 

 Key: COLLECTIONS-448
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-448
 Project: Commons Collections
  Issue Type: Wish
  Components: Bag
Affects Versions: 4.0
Reporter: Othmen TILIOUINE
Priority: Minor
  Labels: patch
 Attachments: pickFromABag.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 Hello,
 This is a patch to add two methods to Bag interface and classes
 public E pick();
 public E pickAndRemit();
 as discussed in this mail.
 -
 http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
 I just saw the Bag interface and its implementations, I'm surprised that Bag 
 T (and none of these implementations) expose the method
 public T pick() and public T pickAndRemit() (pick a random element)
 The Bag object we see in nature, it is mainly used to this, that's why it is 
 widely used in the probability that when I met 2 white balls and one black, 
 when I draw a ball randomly I have 2 times more likely to have a white ball
 I think that if this caracteristic exists it would be very valuable.

[jira] [Commented] (FILEUPLOAD-199) Uploads have unexpected results for files with non-ASCII names - support RFC2047


[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13600940#comment-13600940
 ] 

Simone Tripodi commented on FILEUPLOAD-199:
---

{quote}
so maybe a clarification of this would be useful in the commons fileupload home 
page
{quote}

Sure, as soon as we will release 1.3, we will update the site as well - current 
fix is included in /trunk only ATM

 Uploads have unexpected results for files with non-ASCII names - support 
 RFC2047
 

 Key: FILEUPLOAD-199
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-199
 Project: Commons FileUpload
  Issue Type: Bug
Affects Versions: 1.2.2
Reporter: Mark Thomas
Assignee: Simone Tripodi
 Fix For: 1.3


 Uploading a file with a UTF-8 file name results in a garbled file name on the 
 server. Both the browser and Commons File Upload are at fault in this process.
 The headers for each uploaded part should only use ASCII. Non-ASCII header 
 values - such as UTF-8 file names - should be encoded as per RFC2047. The 
 browsers are at fault for not encoding the headers correctly. Commons File 
 Upload is at fault for not handling RFC2047 encoded header values.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (FILEUPLOAD-229) toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) instead


[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601000#comment-13601000
 ] 

Simone Tripodi commented on FILEUPLOAD-229:
---

As discussed dev@, about {{ServletFileUpload}}, _RFC-2616 5.1.1 Method_ states 
that http methods are case-sensitive:

{quote}
The Method  token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.

Method = OPTIONS; Section 9.2
   | GET; Section 9.3
   | HEAD   ; Section 9.4
   | POST   ; Section 9.5
   | PUT; Section 9.6
   | DELETE ; Section 9.7
   | TRACE  ; Section 9.8
   | CONNECT; Section 9.9
   | extension-method
extension-method = token
{quote}

So there is no need for {{equalsIgnoreCase}} or {{toLowerCase}} at all and 
{{POST.equals(...)}} should just do it.

 toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) 
 instead
 -

 Key: FILEUPLOAD-229
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-229
 Project: Commons FileUpload
  Issue Type: Bug
Reporter: Sebb

 toLowerCase() is Locale-dependent - as is toUpperCase().
 For comparisons, can often use equalsIgnoreCase(String) instead.
 If an actual lower/upper case is required, then should use a fixed locale 
 (unless the code is intended to use the default locale, which is quite 
 unusual for Commons)
 A suitable locale is Locale.ENGLISH as that behaves well with ASCII and 
 ISO-8859-1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (FILEUPLOAD-229) toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) instead


[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601000#comment-13601000
 ] 

Simone Tripodi edited comment on FILEUPLOAD-229 at 3/13/13 10:04 AM:
-

As discussed dev@, about {{ServletFileUpload}}, _RFC-2616 5.1.1 Method_ states 
that http methods are case-sensitive:

{quote}
The Method  token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.
{noformat}
Method = OPTIONS; Section 9.2
   | GET; Section 9.3
   | HEAD   ; Section 9.4
   | POST   ; Section 9.5
   | PUT; Section 9.6
   | DELETE ; Section 9.7
   | TRACE  ; Section 9.8
   | CONNECT; Section 9.9
   | extension-method
extension-method = token
{noformat}
{quote}

So there is no need for {{equalsIgnoreCase}} or {{toLowerCase}} at all and 
{{POST.equals(...)}} should just do it.

  was (Author: simone.tripodi):
As discussed dev@, about {{ServletFileUpload}}, _RFC-2616 5.1.1 Method_ 
states that http methods are case-sensitive:

{quote}
The Method  token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.

Method = OPTIONS; Section 9.2
   | GET; Section 9.3
   | HEAD   ; Section 9.4
   | POST   ; Section 9.5
   | PUT; Section 9.6
   | DELETE ; Section 9.7
   | TRACE  ; Section 9.8
   | CONNECT; Section 9.9
   | extension-method
extension-method = token
{quote}

So there is no need for {{equalsIgnoreCase}} or {{toLowerCase}} at all and 
{{POST.equals(...)}} should just do it.
  
 toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) 
 instead
 -

 Key: FILEUPLOAD-229
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-229
 Project: Commons FileUpload
  Issue Type: Bug
Reporter: Sebb

 toLowerCase() is Locale-dependent - as is toUpperCase().
 For comparisons, can often use equalsIgnoreCase(String) instead.
 If an actual lower/upper case is required, then should use a fixed locale 
 (unless the code is intended to use the default locale, which is quite 
 unusual for Commons)
 A suitable locale is Locale.ENGLISH as that behaves well with ASCII and 
 ISO-8859-1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getDeclaredFields() to return all the fields defined in the given class and super classes


[ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601004#comment-13601004
 ] 

Gary Gregory commented on LANG-873:
---

and your alternative proposal is...?

 Add FieldUtils getDeclaredFields() to return all the fields defined in the 
 given class and super classes
 

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MATH-738) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b


 [ 
https://issues.apache.org/jira/browse/MATH-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe updated MATH-738:
---

Fix Version/s: (was: 3.2)

 Incomplete beta function I(x, a, b) is inaccurate for large values of a 
 and/or b
 

 Key: MATH-738
 URL: https://issues.apache.org/jira/browse/MATH-738
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.0
Reporter: Sébastien Brisard
  Labels: special-functions
 Fix For: 4.0


 This was first reported in MATH-718. The result of the current implementation 
 of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are 
 large-ish. 
 I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], 
 GSL, 
 [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html]
  as well as NR. At first sight, neither uses the same method to compute this 
 function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the 
 best option.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (FILEUPLOAD-229) toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) instead


 [ 
https://issues.apache.org/jira/browse/FILEUPLOAD-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simone Tripodi resolved FILEUPLOAD-229.
---

   Resolution: Fixed
Fix Version/s: 1.3
 Assignee: Simone Tripodi

Resolved in r1455858 and 1455868

 toLowerCase() is Locale-dependent; should use toLowerCase(Locale.ENGLISH) 
 instead
 -

 Key: FILEUPLOAD-229
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-229
 Project: Commons FileUpload
  Issue Type: Bug
Reporter: Sebb
Assignee: Simone Tripodi
 Fix For: 1.3


 toLowerCase() is Locale-dependent - as is toUpperCase().
 For comparisons, can often use equalsIgnoreCase(String) instead.
 If an actual lower/upper case is required, then should use a fixed locale 
 (unless the code is intended to use the default locale, which is quite 
 unusual for Commons)
 A suitable locale is Locale.ENGLISH as that behaves well with ASCII and 
 ISO-8859-1.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MATH-925) Implementation of a diagonal matrix


 [ 
https://issues.apache.org/jira/browse/MATH-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-925.


Resolution: Fixed

Fixed in subversion repository as of r1455890.

Thanks for having done all the initial implementation work.

 Implementation of a diagonal matrix
 ---

 Key: MATH-925
 URL: https://issues.apache.org/jira/browse/MATH-925
 Project: Commons Math
  Issue Type: New Feature
Reporter: Gilles
Priority: Minor
 Fix For: 3.2


 By implementing a diagonal matrix (where only the non-zero elements are 
 actually stored), it is possible to solve MATH-924 with minimal changes to 
 the code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MATH-628) use only SparseIterator, on RealVectors, that implement SpareRealVectors


 [ 
https://issues.apache.org/jira/browse/MATH-628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-628.


Resolution: Won't Fix

Sparse linear algebra implementation in Apache Commons Math needs a complete 
rewrite. As per issue MATH-870, it was decided to remove the corresponding 
classes for 4.0. The classes and interfaces have already been deprecated as of 
3.1.1.

 use only SparseIterator, on RealVectors, that implement SpareRealVectors 
 -

 Key: MATH-628
 URL: https://issues.apache.org/jira/browse/MATH-628
 Project: Commons Math
  Issue Type: Improvement
Reporter: Arne Plöse
Priority: Minor
 Fix For: 3.2

 Attachments: ArrayRealVector.diff


 the performance suffers badly if one tries to use SparseIterator when there 
 is no sparse backing.
 Currently there is only a check for ArrayRealvector, all other is supposed to 
 be a SparseRealvector.
 If one creates a new implementation of RealVector ... bang.
 here is a performance test case:
 {code}
 package org.apache.commons.math.linear;
 import java.util.Iterator;
 import org.junit.Test;
 /**
  *
  * @author aploese
  */
 public class PerformanceTest {
 final static int ITER = 100;
 final static int VECTOR_SIZE = 2048;
 final static double SPARSE_FILL_STATE = 0.8;
 @Test
 public void performanceSparseVectorOpenMap() {
 System.out.println(performanceSparseVectorOpenMap);
 RealVector v = new OpenMapRealVector(VECTOR_SIZE);
 for (int i = 0; i  v.getDimension() * SPARSE_FILL_STATE; i++) {
 v.setEntry(i, i);
 }
 for (int j = 0; j  ITER; j++) {
 long t1 = System.nanoTime();
 double a = 0;
 IteratorRealVector.Entry it = v.sparseIterator();
 RealVector.Entry e;
 while (it.hasNext()  (e = it.next()) != null) {
 a += e.getValue();
 }
 long t2 = System.nanoTime();
 for (int i = 0; i  v.getDimension(); i++) {
 a += v.getEntry(i);
 }
 long t3 = System.nanoTime();
 System.out.println(String.format(OpenMap: %d\t%s\t| %s, j, 
 Long.toString(t2 - t1), Long.toString(t3 - t2)));
 }
 }
 @Test
 public void performanceSparseVectorArray() {
 System.out.println(performanceSparseVectorArray);
 RealVector v = new ArrayRealVector(VECTOR_SIZE);
 for (int i = 0; i  v.getDimension() * SPARSE_FILL_STATE; i++) {
 v.setEntry(i, i);
 }
 for (int j = 0; j  ITER; j++) {
 long t1 = System.nanoTime();
 double a = 0;
 IteratorRealVector.Entry it = v.sparseIterator();
 RealVector.Entry e;
 while (it.hasNext()  (e = it.next()) != null) {
 a += e.getValue();
 }
 long t2 = System.nanoTime();
 for (int i = 0; i  v.getDimension(); i++) {
 a += v.getEntry(i);
 }
 long t3 = System.nanoTime();
 System.out.println(String.format(Array: %d\t%s\t| %s, j, 
 Long.toString(t2 - t1), Long.toString(t3 - t2)));
 }
 }
 {code}
 Patch will follow.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MATH-580) FastMath Performance Test should use larger ranges where the functions support them


 [ 
https://issues.apache.org/jira/browse/MATH-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-580.


Resolution: Fixed

Fixed in subversion repository as of r1455921.

The extension was done in the individual tests, not in the global catch-all 
one. The results show that for large ranges, there are some important slow down 
(for example for asin/acos/atan, probably due to range reduction).

 FastMath Performance Test should use larger ranges where the functions 
 support them
 ---

 Key: MATH-580
 URL: https://issues.apache.org/jira/browse/MATH-580
 Project: Commons Math
  Issue Type: Bug
Reporter: Sebb
 Fix For: 3.2


 FastMath calculations should be faster than Math, especially over larger 
 ranges of operands.
 The Performance test code currently uses a very small range of operands 
 (probably so the same range can be used for all tests).
 The test should be enhanced to use much larger ranges where this is supported 
 by the function under test.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (CHAIN-40) ContextBase should use LinkedHashMap

2013-03-13 Thread Steve Westwood (JIRA)

[
https://issues.apache.org/jira/browse/CHAIN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601194#comment-13601194
]

Steve Westwood edited comment on CHAIN-40 at 3/13/13 2:37 PM:
--

This issue is obsolete given the work in CHAIN-53 to accommodate JDK 1.5 and
generics. Whereas the older version of ContextBase extended HashMap, this
current trunk version uses ConcurrentHashMap.

Suggest that this issue be closed.

was (Author: hexsaw):
This is obsolete given the work in CHAIN-53 to accommodate JDK 1.5 and
generics. Whereas the older version of ContextBase extended HashMap, this
current trunk version uses ConcurrentHashMap.

ContextBase should use LinkedHashMap

Key: CHAIN-40
URL: https://issues.apache.org/jira/browse/CHAIN-40
Project: Commons Chain
Issue Type: Improvement
Reporter: Cédric BODIN
Priority: Minor

org.apache.commons.chain.impl.ContextBase should use java.util.LinkedHashMap
(instead of java.util.HashMap) : as its superclass, and as the java.util.Map
implementation for its descriptors attribute.
Indeed LinkedHashMap allow insertion-order iteration over the context,
which is an additional information about the chain execution (to know the
order of the commands into the chain).
Moreover LinkedHashMap is a HashMap : so this enhancement is transparent
for users who didn't/don't/won't want to presume about context's iteration
order.
Thanks in advance.
Cédric BODIN

[jira] [Commented] (CHAIN-40) ContextBase should use LinkedHashMap

2013-03-13 Thread Steve Westwood (JIRA)


[ 
https://issues.apache.org/jira/browse/CHAIN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601194#comment-13601194
 ] 

Steve Westwood commented on CHAIN-40:
-

This is obsolete given the work in CHAIN-53 to accommodate JDK 1.5 and 
generics. Whereas the older version of ContextBase extended HashMap, this 
current trunk version uses ConcurrentHashMap.

 ContextBase should use LinkedHashMap
 

 Key: CHAIN-40
 URL: https://issues.apache.org/jira/browse/CHAIN-40
 Project: Commons Chain
  Issue Type: Improvement
Reporter: Cédric BODIN
Priority: Minor

 org.apache.commons.chain.impl.ContextBase should use java.util.LinkedHashMap 
 (instead of java.util.HashMap) : as its superclass,  and as the java.util.Map 
 implementation for its descriptors attribute.
 Indeed LinkedHashMap allow insertion-order iteration over the context, 
 which is an additional information about the chain execution (to know the 
 order of the commands into the chain).
 Moreover LinkedHashMap is a HashMap : so this enhancement is transparent 
 for users who didn't/don't/won't want to presume about context's iteration 
 order.
 Thanks in advance.
 Cédric BODIN

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getDeclaredFields() to return all the fields defined in the given class and super classes

2013-03-13 Thread Matt Benson (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601226#comment-13601226
 ] 

Matt Benson commented on LANG-873:
--

;P  If I'm forced to provide one, I'd say {{#getAllFields()}} would be fairly 
unambiguous.

 Add FieldUtils getDeclaredFields() to return all the fields defined in the 
 given class and super classes
 

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LANG-873) Add FieldUtils getDeclaredFields() to return all the fields defined in the given class and super classes

2013-03-13 Thread nguyen phuc lam (JIRA)


 [ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

nguyen phuc lam updated LANG-873:
-

Attachment: FieldUtils.diff

 Add FieldUtils getDeclaredFields() to return all the fields defined in the 
 given class and super classes
 

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getDeclaredFields() to return all the fields defined in the given class and super classes

2013-03-13 Thread nguyen phuc lam (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601244#comment-13601244
 ] 

nguyen phuc lam commented on LANG-873:
--

Hi Gary,

Can you check my latest change if it still uses many temporary objects? Your 
implementation is nice but I think it is not very neat. Thanks.

 Add FieldUtils getDeclaredFields() to return all the fields defined in the 
 given class and super classes
 

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (LANG-873) Add FieldUtils getAllFields() to return all the fields defined in the given class and super classes


 [ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated LANG-873:
--

Summary: Add FieldUtils getAllFields() to return all the fields defined in 
the given class and super classes  (was: Add FieldUtils getDeclaredFields() to 
return all the fields defined in the given class and super classes)

 Add FieldUtils getAllFields() to return all the fields defined in the given 
 class and super classes
 ---

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getAllFields() to return all the fields defined in the given class and super classes


[ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601273#comment-13601273
 ] 

Gary Gregory commented on LANG-873:
---

Matt, I changed the name to 'getAllFields'.

Gary

 Add FieldUtils getAllFields() to return all the fields defined in the given 
 class and super classes
 ---

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-946) Array Scaling

2013-03-13 Thread Jared Becksfort (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601274#comment-13601274
 ] 

Jared Becksfort commented on MATH-946:
--

Bump.

 Array Scaling
 -

 Key: MATH-946
 URL: https://issues.apache.org/jira/browse/MATH-946
 Project: Commons Math
  Issue Type: Improvement
Reporter: Jared Becksfort
Priority: Minor
 Attachments: MathArrays.java.patch, MathArraysTest.java.patch


 Add methods in MathArrays to scale array in place or return a copy.
 These would be useful for multiplying all elements in an array by a scalar 
 without explicit looping.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getAllFields() to return all the fields defined in the given class and super classes

2013-03-13 Thread Matt Benson (JIRA)


[ 
https://issues.apache.org/jira/browse/LANG-873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601275#comment-13601275
 ] 

Matt Benson commented on LANG-873:
--

Thanks, Gary!

 Add FieldUtils getAllFields() to return all the fields defined in the given 
 class and super classes
 ---

 Key: LANG-873
 URL: https://issues.apache.org/jira/browse/LANG-873
 Project: Commons Lang
  Issue Type: Improvement
  Components: lang.reflect.*
Reporter: Emmanuel Bourg
Priority: Minor
 Fix For: 3.2

 Attachments: FieldUtils.diff, FieldUtils.diff, FieldUtilsTest.diff


 {{java.lang.Class.getDeclaredFields()}} doesn't return the fields defined by 
 the super classes. I'd like to suggest the addition of a new method in 
 FieldUtils that also returns the inherited fields (including the private 
 fields).
 According to this question on StackOverflow this method would be quite useful:
 http://stackoverflow.com/questions/3567372/access-to-private-inherited-fields-via-reflection-in-java

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (MATH-437) Kolmogorov Smirnov Distribution


 [ 
https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe updated MATH-437:
---

Attachment: ks-distribution.patch

Would the ks-distribution.patch patch be an acceptable way to implement the 
real distribution interface and solve the issue?

Note that the implementations is really basic numerical computation using the 
cumulative probability as the reference. There are surely much better ways to 
do that. In particular, there seems to be exact formulas to compute the first 
moments (see the comments in the code and in the test case).

I did not set up the test case to implement the abstract test shared by all 
distributions, but it would need to be done too.

If the patch is not acceptable, could we push this issue to 4.0?

 Kolmogorov Smirnov Distribution
 ---

 Key: MATH-437
 URL: https://issues.apache.org/jira/browse/MATH-437
 Project: Commons Math
  Issue Type: New Feature
Reporter: Mikkel Meyer Andersen
Priority: Minor
 Fix For: 3.2

 Attachments: ks-distribution.patch, MATH437-with-test-take-1

   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a 
 known probability density functions or if two samples are from the same 
 distribution. To evaluate the test statistic, the Kolmogorov-Smirnov 
 distribution is used. Quite good asymptotics exist for the one-sided test, 
 but it's more difficult for the two-sided test.
 [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-460) Levy Distribution


[ 
https://issues.apache.org/jira/browse/MATH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601383#comment-13601383
 ] 

Luc Maisonobe commented on MATH-460:


Are there any news on this issue?

It seems a lot of works has already been done, but unfortunately we only have 
the initial patch from 2010 attached to the issue.
Would it be possible to have the current status of the code, even if it is not 
complete yet?

 Levy Distribution
 -

 Key: MATH-460
 URL: https://issues.apache.org/jira/browse/MATH-460
 Project: Commons Math
  Issue Type: New Feature
Reporter: Pavel Ryzhov
Priority: Minor
 Fix For: 3.2

 Attachments: levy_math_460.patch


 Pretty straightforward implementation of Levy Distribution (not Levy 
 alpha-stable) according to http://en.wikipedia.org/wiki/Lévy_distribution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Othmen TILIOUINE updated COLLECTIONS-448:
-

Attachment: pickFromABag2.patch

correction of reformatting problem

 [PATCH] Proposal for addinig random pick methods to Bags
 

 Key: COLLECTIONS-448
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-448
 Project: Commons Collections
  Issue Type: Wish
  Components: Bag
Affects Versions: 4.0
Reporter: Othmen TILIOUINE
Priority: Minor
  Labels: patch
 Attachments: pickFromABag2.patch, pickFromABag.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 Hello,
 This is a patch to add two methods to Bag interface and classes
 public E pick();
 public E pickAndRemit();
 as discussed in this mail.
 -
 http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
 I just saw the Bag interface and its implementations, I'm surprised that Bag 
 T (and none of these implementations) expose the method
 public T pick() and public T pickAndRemit() (pick a random element)
 The Bag object we see in nature, it is mainly used to this, that's why it is 
 widely used in the probability that when I met 2 white balls and one black, 
 when I draw a ball randomly I have 2 times more likely to have a white ball
 I think that if this caracteristic exists it would be very valuable.
 --
 these methods pick a random element from the bag, The probability of picking 
 a copy of a given element is proportional to the number of copies of this 
 element in the bag.
 the diference between pick() and pickAndRemit() is that with pick() the 
 picked element is not removed from the bag. 
 this is my first contribution on open source project 
 if you accept to add this feature to bags and validate my patch i will add 
 one other patch to add this methods
 public IteratorE pick(int n); //pick random n element (with remove)
 public IteratorE pickAndRemit(int n) ; //pick random n element (without 
 remove)
 -Question : should i regenerate the serialVersionUID of classes that i have 
 changed ?
 Othmen TILIOUINE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601515#comment-13601515
 ] 

Othmen TILIOUINE commented on COLLECTIONS-448:
--

in the first patch (pickFromABag.patch) there is a problem of reformating of 
the entire file Bag.java, i attached a new patch (pickFromABag2.patch) to 
eliminate this problem.

 [PATCH] Proposal for addinig random pick methods to Bags
 

 Key: COLLECTIONS-448
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-448
 Project: Commons Collections
  Issue Type: Wish
  Components: Bag
Affects Versions: 4.0
Reporter: Othmen TILIOUINE
Priority: Minor
  Labels: patch
 Attachments: pickFromABag2.patch, pickFromABag.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 Hello,
 This is a patch to add two methods to Bag interface and classes
 public E pick();
 public E pickAndRemit();
 as discussed in this mail.
 -
 http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
 I just saw the Bag interface and its implementations, I'm surprised that Bag 
 T (and none of these implementations) expose the method
 public T pick() and public T pickAndRemit() (pick a random element)
 The Bag object we see in nature, it is mainly used to this, that's why it is 
 widely used in the probability that when I met 2 white balls and one black, 
 when I draw a ball randomly I have 2 times more likely to have a white ball
 I think that if this caracteristic exists it would be very valuable.
 --
 these methods pick a random element from the bag, The probability of picking 
 a copy of a given element is proportional to the number of copies of this 
 element in the bag.
 the diference between pick() and pickAndRemit() is that with pick() the 
 picked element is not removed from the bag. 
 this is my first contribution on open source project 
 if you accept to add this feature to bags and validate my patch i will add 
 one other patch to add this methods
 public IteratorE pick(int n); //pick random n element (with remove)
 public IteratorE pickAndRemit(int n) ; //pick random n element (without 
 remove)
 -Question : should i regenerate the serialVersionUID of classes that i have 
 changed ?
 Othmen TILIOUINE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags


 [ 
https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Othmen TILIOUINE updated COLLECTIONS-448:
-

Attachment: (was: pickFromABag.patch)

 [PATCH] Proposal for addinig random pick methods to Bags
 

 Key: COLLECTIONS-448
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-448
 Project: Commons Collections
  Issue Type: Wish
  Components: Bag
Affects Versions: 4.0
Reporter: Othmen TILIOUINE
Priority: Minor
  Labels: patch
 Attachments: pickFromABag2.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 Hello,
 This is a patch to add two methods to Bag interface and classes
 public E pick();
 public E pickAndRemit();
 as discussed in this mail.
 -
 http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
 I just saw the Bag interface and its implementations, I'm surprised that Bag 
 T (and none of these implementations) expose the method
 public T pick() and public T pickAndRemit() (pick a random element)
 The Bag object we see in nature, it is mainly used to this, that's why it is 
 widely used in the probability that when I met 2 white balls and one black, 
 when I draw a ball randomly I have 2 times more likely to have a white ball
 I think that if this caracteristic exists it would be very valuable.
 --
 these methods pick a random element from the bag, The probability of picking 
 a copy of a given element is proportional to the number of copies of this 
 element in the bag.
 the diference between pick() and pickAndRemit() is that with pick() the 
 picked element is not removed from the bag. 
 this is my first contribution on open source project 
 if you accept to add this feature to bags and validate my patch i will add 
 one other patch to add this methods
 public IteratorE pick(int n); //pick random n element (with remove)
 public IteratorE pickAndRemit(int n) ; //pick random n element (without 
 remove)
 -Question : should i regenerate the serialVersionUID of classes that i have 
 changed ?
 Othmen TILIOUINE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Comment Edited] (COLLECTIONS-448) [PATCH] Proposal for addinig random pick methods to Bags


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601515#comment-13601515
 ] 

Othmen TILIOUINE edited comment on COLLECTIONS-448 at 3/13/13 7:17 PM:
---

in the first patch (pickFromABag.patch) there is a problem of reformating of 
the entire file Bag.java, I replaced it with a new patch (pickFromABag2.patch) 
to eliminate this problem.

  was (Author: influence160):
in the first patch (pickFromABag.patch) there is a problem of reformating 
of the entire file Bag.java, i attached a new patch (pickFromABag2.patch) to 
eliminate this problem.
  
 [PATCH] Proposal for addinig random pick methods to Bags
 

 Key: COLLECTIONS-448
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-448
 Project: Commons Collections
  Issue Type: Wish
  Components: Bag
Affects Versions: 4.0
Reporter: Othmen TILIOUINE
Priority: Minor
  Labels: patch
 Attachments: pickFromABag2.patch

   Original Estimate: 4h
  Remaining Estimate: 4h

 Hello,
 This is a patch to add two methods to Bag interface and classes
 public E pick();
 public E pickAndRemit();
 as discussed in this mail.
 -
 http://mail-archives.apache.org/mod_mbox/commons-dev/201303.mbox/%3CCAChO4O-YRE%3Db1%3D4hEK%2BuhvpV6-OD3F3apyRn3mwjvGzUEXe%2BaQ%40mail.gmail.com%3E
 I just saw the Bag interface and its implementations, I'm surprised that Bag 
 T (and none of these implementations) expose the method
 public T pick() and public T pickAndRemit() (pick a random element)
 The Bag object we see in nature, it is mainly used to this, that's why it is 
 widely used in the probability that when I met 2 white balls and one black, 
 when I draw a ball randomly I have 2 times more likely to have a white ball
 I think that if this caracteristic exists it would be very valuable.
 --
 these methods pick a random element from the bag, The probability of picking 
 a copy of a given element is proportional to the number of copies of this 
 element in the bag.
 the diference between pick() and pickAndRemit() is that with pick() the 
 picked element is not removed from the bag. 
 this is my first contribution on open source project 
 if you accept to add this feature to bags and validate my patch i will add 
 one other patch to add this methods
 public IteratorE pick(int n); //pick random n element (with remove)
 public IteratorE pickAndRemit(int n) ; //pick random n element (without 
 remove)
 -Question : should i regenerate the serialVersionUID of classes that i have 
 changed ?
 Othmen TILIOUINE

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-325) Improve thread-safety of ExtendedProperties

2013-03-13 Thread Thomas Neidhart (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601562#comment-13601562
 ] 

Thomas Neidhart commented on COLLECTIONS-325:
-

The class javadoc already states that it would probably a better idea to use 
commons-configuration. So I wonder if we should not take the opportunity 
(release 4.0) and remove the class completely.

Any objections?

 Improve thread-safety of ExtendedProperties
 ---

 Key: COLLECTIONS-325
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-325
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb

 It looks as though ExtendedProperties is intended to be thread-safe, 
 otherwise why bother synchronizing load() and save()?
 If so, then ExtendedProperties field isInitialized should be made volatile 
 to ensure the variable is correctly published.
 Likewise, the field includePropertyName needs to be volatile or 
 synchronised.
 Also, the following protected variables could be made final to improve 
 thread-safety:
 defaults
 file
 basePath
 fileSeparator - this could perhaps be static too?
 keysAsListed
 Regardless of thread-safety issues, does it make sense for these variables to 
 be changed once initialised?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (MATH-460) Levy Distribution

2013-03-13 Thread Andrew Waterman (JIRA)


[ 
https://issues.apache.org/jira/browse/MATH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601567#comment-13601567
 ] 

Andrew Waterman commented on MATH-460:
--

Hi Luc,

My apologies for not updating you guys sooner. I haven't touched the code for 
about 6 months; I got hung up on implementing the standard distribution tests.

My last commit includes the re-incorporating the work from the 2010 patch along 
with the work I did in conjunction with my mathematician friend, Jim Smith, 
here in Chiapas. 

The main issue is really how to test the implementation. 

Please see my GitHub commit for more details:

https://github.com/awaterma/commons-math/commit/a2396a824352dc372a5e8c58409be6d21150b071

The following methods in the Class I'm unsure about:

public boolean isSupportLowerBoundInclusive() {
+return false;  //To change body of implemented methods use File | 
Settings | File Templates.
+}
+
+public boolean isSupportUpperBoundInclusive() {
+return false;  //To change body of implemented methods use File | 
Settings | File Templates.
+}
+
+public boolean isSupportConnected() {
+return false;  //To change body of implemented methods use File | 
Settings | File Templates.
+}

And, as you can see from my local commit, the tests are incomplete. I had 
planned on finishing this but got caught up with other projects. At least my 
changes have incorporated much of Pavel's work in the new inheritance model 
and the skeleton for the correct unit test is available. As I mentioned above, 
I had quite a few problems with the rmutil package for helping build out these 
tests (it's not available in a normal R repository). Do you have any other 
suggestions/implementations that might speed this along? It would be nice to 
submit something to you guys after so many comment threads.

 Levy Distribution
 -

 Key: MATH-460
 URL: https://issues.apache.org/jira/browse/MATH-460
 Project: Commons Math
  Issue Type: New Feature
Reporter: Pavel Ryzhov
Priority: Minor
 Fix For: 3.2

 Attachments: levy_math_460.patch


 Pretty straightforward implementation of Levy Distribution (not Levy 
 alpha-stable) according to http://en.wikipedia.org/wiki/Lévy_distribution.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-299) ConvertingWrapDynaBean should allow custom BeanUtilsBean


[ 
https://issues.apache.org/jira/browse/BEANUTILS-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601598#comment-13601598
 ] 

Benedikt Ritter commented on BEANUTILS-299:
---

This can be achieved by using {{BeanUtilsBean.setInstance(BeanUtilsBean)}} 
before creating the {{ConvertingWrapDynaBean}}.

 ConvertingWrapDynaBean should allow custom BeanUtilsBean
 

 Key: BEANUTILS-299
 URL: https://issues.apache.org/jira/browse/BEANUTILS-299
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: DynaBean
Reporter: Heikki Vesalainen
 Fix For: LATER THAN 1.8.4


 ConvertingWrapDynaBean should accept as constructor parameter a custom 
 BeanUtilsBean and use that instead of the static BeanUtils.
 like so:
 BeanUtilsBean beanUtils;
 public ConvertingWrapDynaBean(Object instance, BeanUtilsBean beanUtils) {
   super(instance);
   this.beanUtils = beanUtils;
 }
 public ConvertingWrapDynaBean(Object instance) {
   this(instance, new BeanUtilsBean);
 }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (BEANUTILS-430) Clean up SVN keywords


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter resolved BEANUTILS-430.
---

Resolution: Duplicate

 Clean up SVN keywords
 -

 Key: BEANUTILS-430
 URL: https://issues.apache.org/jira/browse/BEANUTILS-430
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.3
Reporter: Benedikt Ritter
 Fix For: 1.8.4


 For example a lot of files contain the $Date$ keyword. 
 This should not be used because it depends on the clients locale.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-434) Add generics where possible


[ 
https://issues.apache.org/jira/browse/BEANUTILS-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601603#comment-13601603
 ] 

Benedikt Ritter commented on BEANUTILS-434:
---

We should postpone this as long as possible, because it will make reviewing 
patches created before very difficult.

 Add generics where possible
 ---

 Key: BEANUTILS-434
 URL: https://issues.apache.org/jira/browse/BEANUTILS-434
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.3
Reporter: Benedikt Ritter
 Fix For: LATER THAN 1.8.4


 After updating to Java 1.5 we cann add generics where it is possible without 
 breaking BC.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-433) Update to JUnit 4


[ 
https://issues.apache.org/jira/browse/BEANUTILS-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601604#comment-13601604
 ] 

Benedikt Ritter commented on BEANUTILS-433:
---

We should postpone this as long as possible, because it will make reviewing 
patches created before very difficult.

 Update to JUnit 4
 -

 Key: BEANUTILS-433
 URL: https://issues.apache.org/jira/browse/BEANUTILS-433
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.3
Reporter: Benedikt Ritter
 Fix For: LATER THAN 1.8.4


 After switching to Java 1.5 we can update to the latest JUnit version.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-257) Many of the helper methods expose the java.lang exceptions. I'd like to convert them to RuntimeExceptions

[
https://issues.apache.org/jira/browse/BEANUTILS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601615#comment-13601615
]

Benedikt Ritter commented on BEANUTILS-257:
---

Hi Aaron, we have started work on BeanUtils 2 in the mean time. In the new API
we wrap all the exceptions into custom RuntimeExceptions (see
http://svn.apache.org/viewvc/commons/sandbox/beanutils2/trunk/src/main/java/org/apache/commons/beanutils2/BeanReflectionException.java?view=markup).
So I don't expect this patch to be included in BeanUtils 1 anymore.

Many of the helper methods expose the java.lang exceptions. I'd like to
convert them to RuntimeExceptions
-

Key: BEANUTILS-257
URL: https://issues.apache.org/jira/browse/BEANUTILS-257
Project: Commons BeanUtils
Issue Type: Improvement
Components: Bean / Property Utils
Affects Versions: 1.8.0
Reporter: Aaron Digulla
Fix For: LATER THAN 1.8.4

Attachments: beanutils-nce.patch

Hello,
A lot of the helper functions throw checked exceptions (mostly
IllegalAccessException, InvocationTargetException and NoSuchMethodException).
I'd like to write a patch which converts them all into RuntimeExceptions so
the code upstream doesn't have to handle them.
Rationale: When working with properties, you usually expect the code to work.
When working with dynamic properties, you don't care about what went wrong
but only that something went wrong. In most cases, it's not possible to fix
the problem automatically but the code has to pass the exception up.
This all calls for non-checked exceptions.
My patch would be against the SVN version and contain these changes:
- The old methods would still be there with an E at the end (for throws a
checked exception).
- The new code would throw exceptions based on a common exception so you can
catch all the exceptions thrown in beanutils in one statement. IAE, ITE, etc.
would then be derived from this base class so you can still filter them.
Since this is going to involve some work, I wanted to ask beforehand if you
would accept such a patch.
Best regards.

[jira] [Commented] (COLLECTIONS-325) Improve thread-safety of ExtendedProperties


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601616#comment-13601616
 ] 

Oliver Heger commented on COLLECTIONS-325:
--

+1, the class does not really fit into Collections.

Commons Configurations should provide various alternatives (however, improving 
thread-safety is a topic here, too.)

 Improve thread-safety of ExtendedProperties
 ---

 Key: COLLECTIONS-325
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-325
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb

 It looks as though ExtendedProperties is intended to be thread-safe, 
 otherwise why bother synchronizing load() and save()?
 If so, then ExtendedProperties field isInitialized should be made volatile 
 to ensure the variable is correctly published.
 Likewise, the field includePropertyName needs to be volatile or 
 synchronised.
 Also, the following protected variables could be made final to improve 
 thread-safety:
 defaults
 file
 basePath
 fileSeparator - this could perhaps be static too?
 keysAsListed
 Regardless of thread-safety issues, does it make sense for these variables to 
 be changed once initialised?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-292) ResultSetDynaClass should implement Iterable


[ 
https://issues.apache.org/jira/browse/BEANUTILS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601619#comment-13601619
 ] 

Benedikt Ritter commented on BEANUTILS-292:
---

Java 5 is now available. Time to fix this :)

 ResultSetDynaClass should implement Iterable
 

 Key: BEANUTILS-292
 URL: https://issues.apache.org/jira/browse/BEANUTILS-292
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.0-BETA
Reporter: Johan
Priority: Minor
 Fix For: LATER THAN 1.8.4


 org.apache.commons.beanutils.ResultSetDynaClass already provides an 
 iterator() method. If it would implement the Iterable interface too, it could 
 be used with the new Java5 for loop construct, e.g.:
 for (final Object dynaBean : new ResultSetDynaClass(resultSet, false))
 {
 }
 Changes to ResultSetDynaClass are minimal and will not break the API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (COLLECTIONS-325) Improve thread-safety of ExtendedProperties

2013-03-13 Thread Matt Benson (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601621#comment-13601621
 ] 

Matt Benson commented on COLLECTIONS-325:
-

+1 from me.

 Improve thread-safety of ExtendedProperties
 ---

 Key: COLLECTIONS-325
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-325
 Project: Commons Collections
  Issue Type: Improvement
Reporter: Sebb

 It looks as though ExtendedProperties is intended to be thread-safe, 
 otherwise why bother synchronizing load() and save()?
 If so, then ExtendedProperties field isInitialized should be made volatile 
 to ensure the variable is correctly published.
 Likewise, the field includePropertyName needs to be volatile or 
 synchronised.
 Also, the following protected variables could be made final to improve 
 thread-safety:
 defaults
 file
 basePath
 fileSeparator - this could perhaps be static too?
 keysAsListed
 Regardless of thread-safety issues, does it make sense for these variables to 
 be changed once initialised?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CONFIGURATION-530) AbstractFileConfiguration.getProperty(String key) locking causes thread hault

[
https://issues.apache.org/jira/browse/CONFIGURATION-530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601626#comment-13601626
]

Oliver Heger commented on CONFIGURATION-530:

Currently, work on a redesigned version 2.0 is going on. This also includes
reworking file-based configurations and improved support for concurrent access.
There is already code in subversion showing the direction I would like to go.
The basic ideas are as follows:
* Configurations are now created by builder objects.
* Reloading is moved from configurations to builders. This means, the content
of a configuration will not change due to a reload while you work with it. Only
if you query the builder again, it might return another configuration instance
if a reload was performed in the meantime. So there is no need to synchronize
because of possible reloads.
* It is planed to rework the concept of concurrent access to configuration
objects. The idea is to use a similar concept as for Java collection classes:
Plain configurations are not thread-safe, but it should be possible to create
synchronized configurations if required.

AbstractFileConfiguration.getProperty(String key) locking causes thread hault
-

Key: CONFIGURATION-530
URL: https://issues.apache.org/jira/browse/CONFIGURATION-530
Project: Commons Configuration
Issue Type: Bug
Components: File reloading
Affects Versions: 1.9
Reporter: yair ogen
Priority: Critical

Every call to getProperty causes a lock (related to the reload
functionality). In a near real-time system where we have many concurrent
threads this affects heavily on the application TPS.
Possible solution will be: getProperty only returns current value. Reload
when needed occurs in a background thread that updates the in-memory map
(perhaps by using CopyOnWrite collections?).

[jira] [Resolved] (CONFIGURATION-531) AbstractConfiguration should be Serializable


 [ 
https://issues.apache.org/jira/browse/CONFIGURATION-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oliver Heger resolved CONFIGURATION-531.


Resolution: Duplicate

In CONFIGURATION-203 there is a long discussion about pros and cons of 
serializable configurations.

 AbstractConfiguration should be Serializable
 

 Key: CONFIGURATION-531
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-531
 Project: Commons Configuration
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.9
Reporter: Laurent Sauvage
 Attachments: serializable.patch


 It would be really great to have AbstractConfiguration implement Serializable.
 Then it could be bound in JNDI so EJBs could retrieve config with a simple 
 @Resource injection.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-248) Code to create a JavaBean and set its properties from a Java Properties instance


[ 
https://issues.apache.org/jira/browse/BEANUTILS-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601633#comment-13601633
 ] 

Benedikt Ritter commented on BEANUTILS-248:
---

Now that we have switched to Java 5 we could even do something like:

{code}
public T populateNewInstance(ClassT beanClass, MapString, String 
properties) { 
   T bean = beanClass.newInstance(); 
   populate(bean, properties); 
   return bean; 
}
{code}

 Code to create a JavaBean and set its properties from a Java Properties 
 instance
 

 Key: BEANUTILS-248
 URL: https://issues.apache.org/jira/browse/BEANUTILS-248
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Bean / Property Utils
 Environment: Coded on Windows XP professional with Netbean 5.5 Beta 2 
 using JDK 1.5.0
Reporter: Trevor Charles Miller
Priority: Minor
 Fix For: LATER THAN 1.8.4

 Attachments: BeanCreator.java


 The idea is simple and I've seen this done in Log4J and had a use case for it 
 myself in another project. Given a set of properties, create an instance of a 
 specified class and set properties on it. I think this could be very useful 
 for runtime configuration.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (BEANUTILS-292) ResultSetDynaClass should implement Iterable


 [ 
https://issues.apache.org/jira/browse/BEANUTILS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter updated BEANUTILS-292:
--

Attachment: BEANUTILS-292.patch

Attaching a patch that adds IterableDynaBean to ResultSetDynaClass and 
IteratorDynaBean to ResultSetIterator. This will cause a Clirr Error, because 
{{public Object next()}} has to be changed to {{public DynaBean next()}}. I 
think for this reason it can not be included like this (but has to be changed 
to implement Iterator without generics).

 ResultSetDynaClass should implement Iterable
 

 Key: BEANUTILS-292
 URL: https://issues.apache.org/jira/browse/BEANUTILS-292
 Project: Commons BeanUtils
  Issue Type: Improvement
Affects Versions: 1.8.0-BETA
Reporter: Johan
Priority: Minor
 Fix For: LATER THAN 1.8.4

 Attachments: BEANUTILS-292.patch


 org.apache.commons.beanutils.ResultSetDynaClass already provides an 
 iterator() method. If it would implement the Iterable interface too, it could 
 be used with the new Java5 for loop construct, e.g.:
 for (final Object dynaBean : new ResultSetDynaClass(resultSet, false))
 {
 }
 Changes to ResultSetDynaClass are minimal and will not break the API.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CONFIGURATION-532) FileChangedReloadingStrategy should support reloading of rolled-back (older timestamp) files


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601640#comment-13601640
 ] 

Oliver Heger commented on CONFIGURATION-532:


Your request perfectly makes sense to me. The documentation of 
{{FileChangedReloadingStrategy}} says
{quote}
A reloading strategy that will reload the configuration every time its 
underlying file is changed.
{quote}
So one could argue that the current behavior to detect only newer files is 
actually a bug. I think when the class was created the author had the 
assumption that somehow modifying the configuration file would always result in 
a newer timestamp which is obviously not the case.

So shouldn't we in general use a != comparison?

 FileChangedReloadingStrategy should support reloading of rolled-back (older 
 timestamp) files
 

 Key: CONFIGURATION-532
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-532
 Project: Commons Configuration
  Issue Type: Improvement
  Components: File reloading
Affects Versions: 1.9
Reporter: Mike Lucas
   Original Estimate: 48h
  Remaining Estimate: 48h

 Currently the {{FileChangedReloadingStrategy}} only reloads when the 
 timestamp of the file on the filesystem is _newer_ than the timestamp it had 
 when it was last loaded.
 This may not be the expected behaviour when, for example, an administrator 
 makes a backup copy of the original configuration file before making changes. 
 If the administrator wants to roll back to the original configuration, he may 
 expect that copying/renaming the backup back to the original name, would 
 cause the original configuration to take effect again.
 Another example where the current behaviour is problematic is when using a 
 Deploy System (like we do at my company). We expect to be able to roll-back 
 to a previous configuration by simply redeploying the Config artifact, but 
 because the timestamps reflect when the Config artifact was _built_ (not when 
 it was deployed), this roll-back will not work.
 The current behaviour could be kept as the default, simply adding 
 {{setReloadOnRollback()}} or similarly named method to change the behaviour 
 to reload when the timestamp is either older or newer (i.e. not equal to) the 
 {{lastModified}} variable. Another option would to be to create subclass 
 {{FileChangedOrRolledBackReloadingStrategy}} that overrides the 
 {{hasChanged()}} method.
 In either option the actual change is to use {{!=}} instead of {{}} in the 
 {{hasChanged}} method's comparison:
 {code}
 return file.lastModified()  lastModified;
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (BEANUTILS-198) [beanutils] Copy bean properties with different names


[ 
https://issues.apache.org/jira/browse/BEANUTILS-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601659#comment-13601659
 ] 

Benedikt Ritter commented on BEANUTILS-198:
---

Would be better to have something like 

{code}
public interface PropertyMapper {

   String getTarget(String sourcePropName);

}
{code}

And pass this to {{copyProperties}} instead of an array. A straight forward 
implemenation that the existing {{copyProperties}} method could than delegate 
to would be:

{code}
public void copyProperties(Object dest, Object orig) {
   copyProperties(dest, orig, new PropertyMapper() {
  
  public String getTarget(String sourcePropName) {
 return sourcePropName;
  }
   }
}
{code}

 [beanutils] Copy bean properties with different names
 -

 Key: BEANUTILS-198
 URL: https://issues.apache.org/jira/browse/BEANUTILS-198
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Bean / Property Utils
Affects Versions: Nightly Builds
 Environment: Operating System: All
 Platform: PC
Reporter: Rafael U. C. Afonso
Priority: Minor
 Fix For: LATER THAN 1.8.4

 Attachments: ASF.LICENSE.NOT.GRANTED--BeanFrom.java, 
 ASF.LICENSE.NOT.GRANTED--BeanTo.java, 
 ASF.LICENSE.NOT.GRANTED--CopyPropertiesWithDifferentNames.java


 In avaliable BeanUtils.copyProperties() implementation it is necessary that
 properties names of origin and destiny bean must be equals. My propose is
 include a overloading method in BeanUtils that receives - beyond destiny and
 origin beans - a two dimensional String array with two columns. This array 
 will
 have name of properties to be copied - destiny property in first column, 
 origin
 property in second column.  
 Code Implementation:
 private static final int TO = 0;
 private static final int FROM = 1;
 /**pCopy property values from the origin bean to the destination bean 
  * for cases where properties names are different. A bidimentional array 
  * provides properties names: destiny bean properties in first column and
  * origin bean properties in secon column. To be added to 
  * org.apache.commons.beanutils.BeanUtils class.  
  * 
  * @param dest
  * @param orig
  * @param toFrom
  * @throws IllegalAccessException
  * @throws InvocationTargetException
  * @throws NoSuchMethodException
  */
 public static void copyProperties(Object dest, Object orig,
 String[][] toFrom) throws IllegalAccessException,
 InvocationTargetException, NoSuchMethodException {
 BeanUtilsBean beanUtilsBean = BeanUtilsBean.getInstance();
 for (int i = 0; i  toFrom.length; i++) {
 String[] strings = toFrom[i];
 Object value = beanUtilsBean.getProperty(orig, strings[FROM]);
 beanUtilsBean.setProperty(dest, strings[TO], value);
 }
 }
 Usage:
 BeanFrom from = new BeanFrom(10, my value); // properties: keyFrom
 (int), valueFrom (String)
 BeanTo to = new BeanTo(); // properties: keyTo (int), valueTo 
 (String) 
 String[][] table = { { keyTo, keyFrom }, { valueTo, valueFrom 
 } };
copyProperties(b, a, table);

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CONFIGURATION-532) FileChangedReloadingStrategy should support reloading of rolled-back (older timestamp) files

2013-03-13 Thread Mike Lucas (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13601661#comment-13601661
 ] 

Mike Lucas commented on CONFIGURATION-532:
--

Hi Oliver,
I would be fine with using a != comparison in general, and I agree that it fits 
the javadoc description better. And it's probably the most intuitive -- 
basically you can expect that the file on the filesystem _right now_ is the 
configuration in effect, subject only to the {{refreshDelay}}.

Of course it's also the simplest change and simple is always good!

My only concern would be if there are any users out there who expect it to 
continue to behave as it does now. Perhaps updated javadoc  release notes are 
enough to alleviate that?

 FileChangedReloadingStrategy should support reloading of rolled-back (older 
 timestamp) files
 

 Key: CONFIGURATION-532
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-532
 Project: Commons Configuration
  Issue Type: Improvement
  Components: File reloading
Affects Versions: 1.9
Reporter: Mike Lucas
   Original Estimate: 48h
  Remaining Estimate: 48h

 Currently the {{FileChangedReloadingStrategy}} only reloads when the 
 timestamp of the file on the filesystem is _newer_ than the timestamp it had 
 when it was last loaded.
 This may not be the expected behaviour when, for example, an administrator 
 makes a backup copy of the original configuration file before making changes. 
 If the administrator wants to roll back to the original configuration, he may 
 expect that copying/renaming the backup back to the original name, would 
 cause the original configuration to take effect again.
 Another example where the current behaviour is problematic is when using a 
 Deploy System (like we do at my company). We expect to be able to roll-back 
 to a previous configuration by simply redeploying the Config artifact, but 
 because the timestamps reflect when the Config artifact was _built_ (not when 
 it was deployed), this roll-back will not work.
 The current behaviour could be kept as the default, simply adding 
 {{setReloadOnRollback()}} or similarly named method to change the behaviour 
 to reload when the timestamp is either older or newer (i.e. not equal to) the 
 {{lastModified}} variable. Another option would to be to create subclass 
 {{FileChangedOrRolledBackReloadingStrategy}} that overrides the 
 {{hasChanged()}} method.
 In either option the actual change is to use {{!=}} instead of {{}} in the 
 {{hasChanged}} method's comparison:
 {code}
 return file.lastModified()  lastModified;
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (MATH-937) NoBracketingException after event was found


 [ 
https://issues.apache.org/jira/browse/MATH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luc Maisonobe resolved MATH-937.


   Resolution: Fixed
Fix Version/s: 3.2

As there are no further comments, we set the issue as fixed.

 NoBracketingException after event was found
 ---

 Key: MATH-937
 URL: https://issues.apache.org/jira/browse/MATH-937
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 3.1.1
Reporter: Christoph Höger
 Fix For: 3.2

 Attachments: ApacheCommonsBouncingBall.java, 
 ApacheCommonsBouncingBallTest.java


 The BracketingNthOrderBrentSolver used by the EmbeddedRungeKuttaIntegrator 
 fails, if an event is detected twice with a NoBracketingException.
 The problem lies in line EventState.java line 262 (version 3.1.1). Here the 
 event detection function f is applied to an arbitrary choosen value of time. 
 If the event detector crosses zero before this time, the solver throws the 
 mentioned exception.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (LANG-873) Add FieldUtils getAllFields() to return all the fields defined in the given class and super classes