[jira] Updated: (MATH-247) Add MathUtils method to check equality given some error bounds

2009-03-01 Thread Benjamin McCann (JIRA)

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

Benjamin McCann updated MATH-247:
-

Attachment: compareTo.patch

Adding a compareTo function to go along with the equals function submitted 
earlier.

 Add MathUtils method to check equality given some error bounds
 --

 Key: MATH-247
 URL: https://issues.apache.org/jira/browse/MATH-247
 Project: Commons Math
  Issue Type: New Feature
Reporter: Benjamin McCann
 Attachments: compareTo.patch, MathUtils.java.patch, 
 MathUtilsTest.java.patch


 It would be nice to have a utility method that tests for equality given some 
 range of allowed error to account for floating point error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Reopened: (MATH-247) Add MathUtils method to check equality given some error bounds

2009-03-01 Thread Benjamin McCann (JIRA)

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

Benjamin McCann reopened MATH-247:
--


I added a path for a compareTo to go along with the equals method added earlier.

 Add MathUtils method to check equality given some error bounds
 --

 Key: MATH-247
 URL: https://issues.apache.org/jira/browse/MATH-247
 Project: Commons Math
  Issue Type: New Feature
Reporter: Benjamin McCann
 Attachments: compareTo.patch, MathUtils.java.patch, 
 MathUtilsTest.java.patch


 It would be nice to have a utility method that tests for equality given some 
 range of allowed error to account for floating point error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (MATH-207) Implementation of GeneticAlgorithm.nextGeneration() is wrong

2009-03-01 Thread Benjamin McCann (JIRA)

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

Benjamin McCann updated MATH-207:
-

Attachment: geneticalgorithm.patch

Patch to improve the API.

 Implementation of GeneticAlgorithm.nextGeneration() is wrong
 

 Key: MATH-207
 URL: https://issues.apache.org/jira/browse/MATH-207
 Project: Commons Math
  Issue Type: Bug
Affects Versions: 2.0
Reporter: David Stefka
Assignee: Phil Steitz
 Fix For: 2.0

 Attachments: geneticalgorithm.patch, genetics_impl.zip, patch

   Original Estimate: 0.17h
  Remaining Estimate: 0.17h

 The implementation of GeneticAlgorithm.nextGeneration() is wrong, since the 
 only way how a Chromosome can get into the new generation is by mutation. 
 Enclosed, I am sending a patch for this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell updated LANG-480:
---

Description: 
Characters that are represented as a 2 characters internaly by java are 
incorrectly converted by the function. The following test displays the problem 
quite nicely:

import org.apache.commons.lang.*;

public class J2 {
public static void main(String[] args) throws Exception {
// this is the utf8 representation of the character:
// COUNTING ROD UNIT DIGIT THREE
// in unicode
// codepoint: U+1D362
byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, 
(byte)0xA2 };

//output is: amp;#55348;amp;#57186;
// should be: amp;#119650;
System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, 
UTF8)) + ');
}
}

Should be very quick to fix, feel free to drop me an email if you want a patch.

  was:
Characters that are represented as a 2 characters internaly by java are 
incorrectly converted by the function. The following test displays the problem 
quite nicely:

import org.apache.commons.lang.*;

public class J2 {
public static void main(String[] args) throws Exception {
// this is the utf8 representation of the character:
// COUNTING ROD UNIT DIGIT THREE
// in unicode
// codepoint: U+1D362
byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, 
(byte)0xA2 };

//output is: #55348;#57186;
// should be: #119650;
System.out.println(' + StringEscapeUtils.escapeHtml(new String(data, 
UTF8)) + ');
}
}

Should be very quick to fix, feel free to drop me an email if you want a patch.


 StringEscapeUtils.escapeHtml incorrectly converts unicode characters above 
 U+00 into 2 characters
 -

 Key: LANG-480
 URL: https://issues.apache.org/jira/browse/LANG-480
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.4
 Environment: doesn't matter
Reporter: Alexander Kjäll
Priority: Minor
 Fix For: 3.0

 Attachments: lang-480.patch


 Characters that are represented as a 2 characters internaly by java are 
 incorrectly converted by the function. The following test displays the 
 problem quite nicely:
 import org.apache.commons.lang.*;
 public class J2 {
 public static void main(String[] args) throws Exception {
 // this is the utf8 representation of the character:
 // COUNTING ROD UNIT DIGIT THREE
 // in unicode
 // codepoint: U+1D362
 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, 
 (byte)0xA2 };
 //output is: amp;#55348;amp;#57186;
 // should be: amp;#119650;
 System.out.println(' + StringEscapeUtils.escapeHtml(new 
 String(data, UTF8)) + ');
 }
 }
 Should be very quick to fix, feel free to drop me an email if you want a 
 patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (LANG-480) StringEscapeUtils.escapeHtml incorrectly converts unicode characters above U+00FFFF into 2 characters

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell closed LANG-480.
--

Resolution: Fixed

svn ci -m Applying Alexander Kjall's patch from LANG-480; along with a unit 
test made from his example. Fixes unicode conversion above U+00 being done 
into 2 characters

Sendingsrc/java/org/apache/commons/lang/Entities.java
Sendingsrc/test/org/apache/commons/lang/StringEscapeUtilsTest.java
Transmitting file data ..
Committed revision 749095.

 StringEscapeUtils.escapeHtml incorrectly converts unicode characters above 
 U+00 into 2 characters
 -

 Key: LANG-480
 URL: https://issues.apache.org/jira/browse/LANG-480
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.4
 Environment: doesn't matter
Reporter: Alexander Kjäll
Priority: Minor
 Fix For: 3.0

 Attachments: lang-480.patch


 Characters that are represented as a 2 characters internaly by java are 
 incorrectly converted by the function. The following test displays the 
 problem quite nicely:
 import org.apache.commons.lang.*;
 public class J2 {
 public static void main(String[] args) throws Exception {
 // this is the utf8 representation of the character:
 // COUNTING ROD UNIT DIGIT THREE
 // in unicode
 // codepoint: U+1D362
 byte[] data = new byte[] { (byte)0xF0, (byte)0x9D, (byte)0x8D, 
 (byte)0xA2 };
 //output is: amp;#55348;amp;#57186;
 // should be: amp;#119650;
 System.out.println(' + StringEscapeUtils.escapeHtml(new 
 String(data, UTF8)) + ');
 }
 }
 Should be very quick to fix, feel free to drop me an email if you want a 
 patch.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (LANG-11) Depend on JDK 1.5+

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell closed LANG-11.
-

Resolution: Fixed

Probably 1.5. 1.6 wasn't that special.

 Depend on JDK 1.5+
 --

 Key: LANG-11
 URL: https://issues.apache.org/jira/browse/LANG-11
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 3.0
 Environment: Operating System: other
 Platform: Other
Reporter: Henri Yandell
 Fix For: LangTwo 1.0


 Compile under Java 5.
 Or go straight to 6?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (LANG-478) StopWatch does not resist to system time changes

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell updated LANG-478:
---

Attachment: LANG-478.patch

Attaching patch to move to nanoTime.

 StopWatch does not resist to system time changes
 

 Key: LANG-478
 URL: https://issues.apache.org/jira/browse/LANG-478
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.3
 Environment: all operating systems.
Reporter: Regis Desgroppes
 Fix For: 3.0

 Attachments: LANG-478.patch


 org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, 
 i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
 When a system time change occurs (user action, NTP synchronization...) 
 between 2 calls to StopWatch.getTime(), the difference between the 2 samples 
 is wrong: the measured duration may noticeably differ from the real one. 
 Moreover, should the system time change consist in a backward adjustment, the 
 difference could be negative.
 In order to make StopWatch resistant to system time changes, would it be 
 possible to use the process time, i.e. by making implementation calling 
 java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
 Thanks a lot,
 Regis.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (LANG-478) StopWatch does not resist to system time changes

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell closed LANG-478.
--

Resolution: Fixed

svn ci -m Applying my patch from LANG-478 - moving StopWatch to using nanoTime 
under the hood. 

Sendingsrc/java/org/apache/commons/lang/time/StopWatch.java
Transmitting file data .
Committed revision 749114.

 StopWatch does not resist to system time changes
 

 Key: LANG-478
 URL: https://issues.apache.org/jira/browse/LANG-478
 Project: Commons Lang
  Issue Type: Bug
Affects Versions: 2.3
 Environment: all operating systems.
Reporter: Regis Desgroppes
 Fix For: 3.0

 Attachments: LANG-478.patch


 org.apache.commons.lang.time.StopWatch seems to be relying on wall clock, 
 i.e. by calling java.lang.System.currentTimeMillis() to sample current time.
 When a system time change occurs (user action, NTP synchronization...) 
 between 2 calls to StopWatch.getTime(), the difference between the 2 samples 
 is wrong: the measured duration may noticeably differ from the real one. 
 Moreover, should the system time change consist in a backward adjustment, the 
 difference could be negative.
 In order to make StopWatch resistant to system time changes, would it be 
 possible to use the process time, i.e. by making implementation calling 
 java.lang.System.nanoTime() -multiplied by appropriate factor, of course.
 Thanks a lot,
 Regis.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (LANG-484) Create changes-report xml file from history

2009-03-01 Thread Henri Yandell (JIRA)
Create changes-report xml file from history
---

 Key: LANG-484
 URL: https://issues.apache.org/jira/browse/LANG-484
 Project: Commons Lang
  Issue Type: Task
Reporter: Henri Yandell
 Fix For: 3.0


It'll take a while, but we need to start a Maven changes report. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (LANG-332) EqualsBuilder to alternatively use method properties

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell commented on LANG-332:


+1, I'd like this too. 

 EqualsBuilder to alternatively use method properties
 

 Key: LANG-332
 URL: https://issues.apache.org/jira/browse/LANG-332
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Paul Benedict
 Fix For: 3.0


 While it is very nice reflection can be used to build a nice equals method, 
 the strategy to focus on private properties is non-negotiable. This strategy 
 is incompatible with CGLIB proxies which rely on method invocations to 
 delegate to the properties of the inner target. I would prefer a switch to 
 dynamically invoke public get* methods over direct property access.
 PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (LANG-417) ClassUtils: method for turning FQN into resource path

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell commented on LANG-417:


PackageUtils sounds good. Code something Paul :)

 ClassUtils: method for turning FQN into resource path
 -

 Key: LANG-417
 URL: https://issues.apache.org/jira/browse/LANG-417
 Project: Commons Lang
  Issue Type: New Feature
Reporter: Paul Benedict
 Fix For: 3.0


 I commonly need a FQ path to a resource within the same location as a class 
 file. I recommend the addition of this method:
 public String getPackageResourcePath(Class clazz, String resourceName)
 StringBuffer buf = new StringBuffer();
 buf.append(ClassUtils.getPackageName(getClass()).replace('.', '/'));
 buf.append(/);
 buf.append(resourceName);
 return  buf.toString();
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (MATH-247) Add MathUtils method to check equality given some error bounds

2009-03-01 Thread Luc Maisonobe (JIRA)

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

Luc Maisonobe resolved MATH-247.


Resolution: Fixed
  Assignee: Luc Maisonobe

applied patch with minor changes to obey javadoc html
fixed in subversion repository as of r749139

thanks for the patch

 Add MathUtils method to check equality given some error bounds
 --

 Key: MATH-247
 URL: https://issues.apache.org/jira/browse/MATH-247
 Project: Commons Math
  Issue Type: New Feature
Reporter: Benjamin McCann
Assignee: Luc Maisonobe
 Attachments: compareTo.patch, MathUtils.java.patch, 
 MathUtilsTest.java.patch


 It would be nice to have a utility method that tests for equality given some 
 range of allowed error to account for floating point error.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (NET-258) Implement A Keepalive Mechanism

2009-03-01 Thread Rory Winston (JIRA)
Implement A Keepalive Mechanism
---

 Key: NET-258
 URL: https://issues.apache.org/jira/browse/NET-258
 Project: Commons Net
  Issue Type: Improvement
Affects Versions: 2.0
Reporter: Rory Winston
Assignee: Rory Winston


For routers/firewalls that terminate idle connections, a separate heartbeat 
mechanism may need to be implemented to keep the control connection active.

Some potential issues:

* Synchronization between a heartbeat write and a __getReply() on an active 
control connection command;
* Should use the NOOP command as a heartbeat signal;
* Make the timeout configurable;
* Default SocketImpl::setKeepAlive() wont do here.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Closed: (LANG-424) Improve Javadoc for StringUtils class

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell closed LANG-424.
--

Resolution: Fixed

Javadoc added. Not sure why it behaves that way, but probably not worth trying 
to change now.

svn ci -m Adding javadoc per LANG-424 to point out what happens in 
substringLast/substringBefore methods when substring is not found src

Sendingsrc/java/org/apache/commons/lang/StringUtils.java
Transmitting file data .
Committed revision 749151.


 Improve Javadoc for StringUtils class
 -

 Key: LANG-424
 URL: https://issues.apache.org/jira/browse/LANG-424
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.4
Reporter: Denise Fernandez
 Fix For: 3.0


 In the StringUtils class it would be helpful if in the following methods, the 
 Javadoc is improved:
 substringAfter
 substringAfterLast
 I think there should be better documentation in the case where the separator 
 string is not found in the search string: It should be explicity noted that 
 in this case an empty string will be returned.
 In the following methods:
 substringBefore
 substringBeforeLast
 It should be documented that if the separator is not found in the search 
 string, the search string is returned.
 I realise there are examples for both these cases, but I think that they 
 should be separately and explicity documented as special cases. I had 
 expected that substringAfterLast would return the original string if the 
 separator was not found in it and this caused me some trouble.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (LANG-290) EnumUtils for JDK 5.0

2009-03-01 Thread Henri Yandell (JIRA)

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

Henri Yandell updated LANG-290:
---

Fix Version/s: (was: LangTwo 1.0)
   3.0

 EnumUtils for JDK 5.0
 -

 Key: LANG-290
 URL: https://issues.apache.org/jira/browse/LANG-290
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.2
Reporter: Henri Yandell
 Fix For: 3.0


 Below is an EnumUtils for JDK 1.5. It's also found in the enums.EnumUtils 
 javadoc:
  import java.util.*;
  public class EnumUtils {
public static Enum getEnum(Class enumClass, String token) {
  return Enum.valueOf(enumClass, token);
}
public static Map getEnumMap(Class enumClass) {
  HashMap map = new HashMap();
  Iterator itr = EnumUtils.iterator(enumClass);
  while(itr.hasNext()) {
Enum enm = (Enum) itr.next();
map.put( enm.name(), enm );
  }
  return map;
}
   
public static List getEnumList(Class enumClass) {
  return new ArrayList( EnumSet.allOf(enumClass) );
}
   
public static Iterator iterator(Class enumClass) {
  return EnumUtils.getEnumList(enumClass).iterator();
}
  }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (LANG-482) Enhance StrSubstitutor to support nested ${var-${subvr}} expansion

2009-03-01 Thread Rob Walker (JIRA)

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

Rob Walker commented on LANG-482:
-

Cool - I just need to make time to fix the tests Oliver reported as not 
working. The code in the patch does work for basic use cases though, so feel 
free to try it. Will hopefully get around to looking at a better version 
sometime this week.

 Enhance StrSubstitutor to support nested ${var-${subvr}} expansion
 --

 Key: LANG-482
 URL: https://issues.apache.org/jira/browse/LANG-482
 Project: Commons Lang
  Issue Type: Improvement
Reporter: Rob Walker
Priority: Minor
 Fix For: 3.0

 Attachments: StrSubstitutor.java.nested.patch


 t would be really handy of StrSubstitutor could support nested variable 
 interpolation:
 org.osgi.framework.system.packages=org.osgi.framework; version=1.4.0, \
 org.osgi.service.packageadmin; version=1.2.0, \
 org.osgi.service.startlevel; version=1.1.0, \
 org.osgi.service.url; version=1.0.0, \
 org.osgi.util.tracker; version=1.3.3 \
 ${jre-${java.specification.version}}
 The process being to expand innermost variable references first and work 
 outwards - this allows for very advance config, such as the above, which can 
 dynamically detect the Java version and expand a JRE version specific 
 property into the property being defined.
 Looking at the implementation, it seems it might be a fairly straightforward 
 enhancement to:
 private int substitute(StrBuilder buf, int offset, int length, List 
 priorVariables)
 The code already has the cyclic map in place.
 I already have code that achieves this within Apache Felix, so I will see if 
 I can retro-fit a similar model to the above and if so submit a patch. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (LANG-332) EqualsBuilder to alternatively use method properties

2009-03-01 Thread Joerg Schaible (JIRA)

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

Joerg Schaible commented on LANG-332:
-

I am quite sure, that we break a lot of code if we change the behavior of this 
method. However, it would be really nice if we had both - 
ReflectionEqualsBuilder and JavaBeanEqualsBuilder. It simply depends on the 
situation where the functionality is used.

 EqualsBuilder to alternatively use method properties
 

 Key: LANG-332
 URL: https://issues.apache.org/jira/browse/LANG-332
 Project: Commons Lang
  Issue Type: Improvement
Affects Versions: 2.3
Reporter: Paul Benedict
 Fix For: 3.0


 While it is very nice reflection can be used to build a nice equals method, 
 the strategy to focus on private properties is non-negotiable. This strategy 
 is incompatible with CGLIB proxies which rely on method invocations to 
 delegate to the properties of the inner target. I would prefer a switch to 
 dynamically invoke public get* methods over direct property access.
 PS: Same thoughts on ReflectionToStringBuilder and HashCodeBuilder

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.