[jira] [Updated] (DBCP-471) Cannot use connectionInitSqls property in BasicDataSource

2016-10-23 Thread happybuddha (JIRA) 

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

happybuddha updated DBCP-471:
-
Description: 
Error : 

{code}Caused by: org.springframework.beans.NotWritablePropertyException: 
Invalid property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
{code}
Configuration : 
{code}
  






Select 1 from dual;


  
{code}

Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469

The property is listed as a List, has a getter which returns a 
List but has a setter which takes a Collection 
This is also not in line with what was in versions before 2 
(dbcp.BasicDataSource)

  was:
Error : 

{code}Caused by: org.springframework.beans.NotWritablePropertyException: 
Invalid property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
{code}
Configuration : 
{code}
  






BEGIN call initialise_connection(); END;


  
{code}

Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469

The property is listed as a List, has a getter which returns a 
List but has a setter which takes a Collection 
This is also not in line with what was in versions before 2 
(dbcp.BasicDataSource)


> Cannot use connectionInitSqls property in BasicDataSource
> -
>
> Key: DBCP-471
> URL: https://issues.apache.org/jira/browse/DBCP-471
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: happybuddha
>
> Error : 
> {code}Caused by: org.springframework.beans.NotWritablePropertyException: 
> Invalid property 'connectionInitSqls' of bean class 
> [org.apache.commons.dbcp2.BasicDataSource]: Bean property 
> 'connectionInitSqls' is not writable or has an invalid setter method. Does 
> the parameter type of the setter match the return type of the getter?
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
>   at 
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
> {code}
> Configuration : 
> {code}
>destroy-method="close">
> 
> 
> 
> 
> 
> 
>   Select 1 from dual;
> 
> 
>   
> {code}
> Similar issue for another bean : 
> https://issues.apache.org/jira/browse/DBCP-469
> The property is listed as a List, has a getter which returns a 
> List but has a setter which takes a Collection 
> This is also not in line with what was in versions before 2 
> (dbcp.BasicDataSource)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DBCP-471) Cannot use connectionInitSqls property in BasicDataSource

2016-10-23 Thread happybuddha (JIRA) 

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

happybuddha updated DBCP-471:
-
Description: 
Error : 

{code}Caused by: org.springframework.beans.NotWritablePropertyException: 
Invalid property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
{code}
Configuration : 
{code}
  






BEGIN call initialise_connection(); END;


  
{code}

Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469

The property is listed as a List, has a getter which returns a 
List but has a setter which takes a Collection 
This is also not in line with what was in versions before 2 
(dbcp.BasicDataSource)

  was:
Error : 

{code}Caused by: org.springframework.beans.NotWritablePropertyException: 
Invalid property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
{code}
Configuration : 
{code}
  






BEGIN call initialise_connection(); END;


  
{code}
Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469


> Cannot use connectionInitSqls property in BasicDataSource
> -
>
> Key: DBCP-471
> URL: https://issues.apache.org/jira/browse/DBCP-471
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: happybuddha
>
> Error : 
> {code}Caused by: org.springframework.beans.NotWritablePropertyException: 
> Invalid property 'connectionInitSqls' of bean class 
> [org.apache.commons.dbcp2.BasicDataSource]: Bean property 
> 'connectionInitSqls' is not writable or has an invalid setter method. Does 
> the parameter type of the setter match the return type of the getter?
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
>   at 
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
> {code}
> Configuration : 
> {code}
>destroy-method="close">
> 
> 
> 
> 
> 
> 
>   BEGIN call initialise_connection(); END;
> 
> 
>   
> {code}
> Similar issue for another bean : 
> https://issues.apache.org/jira/browse/DBCP-469
> The property is listed as a List, has a getter which returns a 
> List but has a setter which takes a Collection 
> This is also not in line with what was in versions before 2 
> (dbcp.BasicDataSource)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DBCP-471) Cannot use connectionInitSqls property in BasicDataSource

2016-10-23 Thread happybuddha (JIRA) 
happybuddha created DBCP-471:


 Summary: Cannot use connectionInitSqls property in BasicDataSource
 Key: DBCP-471
 URL: https://issues.apache.org/jira/browse/DBCP-471
 Project: Commons Dbcp
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: happybuddha


Caused by: org.springframework.beans.NotWritablePropertyException: Invalid 
property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)

Configuration : 

  






BEGIN call initialise_connection(); END;


  

Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DBCP-471) Cannot use connectionInitSqls property in BasicDataSource

2016-10-23 Thread happybuddha (JIRA) 

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

happybuddha updated DBCP-471:
-
Description: 
Error : 

{code}Caused by: org.springframework.beans.NotWritablePropertyException: 
Invalid property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
{code}
Configuration : 
{code}
  






BEGIN call initialise_connection(); END;


  
{code}
Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469

  was:
Caused by: org.springframework.beans.NotWritablePropertyException: Invalid 
property 'connectionInitSqls' of bean class 
[org.apache.commons.dbcp2.BasicDataSource]: Bean property 'connectionInitSqls' 
is not writable or has an invalid setter method. Does the parameter type of the 
setter match the return type of the getter?
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
at 
org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
at 
org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)

Configuration : 

  






BEGIN call initialise_connection(); END;


  

Similar issue for another bean : https://issues.apache.org/jira/browse/DBCP-469


> Cannot use connectionInitSqls property in BasicDataSource
> -
>
> Key: DBCP-471
> URL: https://issues.apache.org/jira/browse/DBCP-471
> Project: Commons Dbcp
>  Issue Type: Bug
>Affects Versions: 2.1.1
>Reporter: happybuddha
>
> Error : 
> {code}Caused by: org.springframework.beans.NotWritablePropertyException: 
> Invalid property 'connectionInitSqls' of bean class 
> [org.apache.commons.dbcp2.BasicDataSource]: Bean property 
> 'connectionInitSqls' is not writable or has an invalid setter method. Does 
> the parameter type of the setter match the return type of the getter?
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:1042)
>   at 
> org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:902)
>   at 
> org.springframework.beans.AbstractPropertyAccessor.setPropertyValues(AbstractPropertyAccessor.java:75)
> {code}
> Configuration : 
> {code}
>destroy-method="close">
> 
> 
> 
> 
> 
> 
>   BEGIN call initialise_connection(); END;
> 
> 
>   
> {code}
> Similar issue for another bean : 
> https://issues.apache.org/jira/browse/DBCP-469



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CRYPTO-127) CryptoInputStream#read should handle non-block case

2016-10-23 Thread Xianda Ke (JIRA) 

[ 
https://issues.apache.org/jira/browse/CRYPTO-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600808#comment-15600808
 ] 

Xianda Ke commented on CRYPTO-127:
--


similar to JCE: CipherInputStream#read()

> CryptoInputStream#read should handle non-block case
> ---
>
> Key: CRYPTO-127
> URL: https://issues.apache.org/jira/browse/CRYPTO-127
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Xianda Ke
>Assignee: Xianda Ke
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CRYPTO-127) CryptoInputStream#read should handle non-block case

2016-10-23 Thread Xianda Ke (JIRA) 
Xianda Ke created CRYPTO-127:


 Summary: CryptoInputStream#read should handle non-block case
 Key: CRYPTO-127
 URL: https://issues.apache.org/jira/browse/CRYPTO-127
 Project: Commons Crypto
  Issue Type: Bug
Reporter: Xianda Ke
Assignee: Xianda Ke






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1145) 64 bit check in SystemUtils

2016-10-23 Thread Gabor Liptak (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600378#comment-15600378
 ] 

Gabor Liptak commented on LANG-1145:


The suggestion was a generic 64 check (covering Windows, *nix and zOS). Thanks

> 64 bit check in SystemUtils
> ---
>
> Key: LANG-1145
> URL: https://issues.apache.org/jira/browse/LANG-1145
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Gabor Liptak
>Priority: Minor
>
> Add is64bit method to SystemUtils.java
> http://stackoverflow.com/a/2269242/304690 for Windows snippet and
> https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/util/SizeEstimator.scala
>  for zOS snippet



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600293#comment-15600293
 ] 

ASF GitHub Bot commented on LANG-1143:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/201
  

[![Coverage 
Status](https://coveralls.io/builds/8468379/badge)](https://coveralls.io/builds/8468379)

Coverage increased (+0.0002%) to 93.541% when pulling 
**f2726339e75dc94f3a11b3797a0162c24cd8bd5e on PascalSchumacher:LANG-1143** into 
**383bc8eefae7e17d0bb0349ab2300488c655ec42 on apache:master**.



> StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
> ---
>
> Key: LANG-1143
> URL: https://issues.apache.org/jira/browse/LANG-1143
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Sebb
> Fix For: Review Patch
>
> Attachments: LANG-1143.patch
>
>
> The Javadoc for Character#toTitleCase(char) recommends using 
> Character#toTitleCase(int) instead. This method was added in Java 1.5 which 
> is perhaps is why it was not used originally; maybe we should use it now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #201: LANG-1143: StringUtils should use toXxxxCase(int) r...

2016-10-23 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/201
  

[![Coverage 
Status](https://coveralls.io/builds/8468379/badge)](https://coveralls.io/builds/8468379)

Coverage increased (+0.0002%) to 93.541% when pulling 
**f2726339e75dc94f3a11b3797a0162c24cd8bd5e on PascalSchumacher:LANG-1143** into 
**383bc8eefae7e17d0bb0349ab2300488c655ec42 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (LANG-1188) StringUtils#join(T...): warning: [unchecked] Possible heap pollution from parameterized vararg type T

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher resolved LANG-1188.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: 3.6

> StringUtils#join(T...): warning: [unchecked] Possible heap pollution from 
> parameterized vararg type T
> -
>
> Key: LANG-1188
> URL: https://issues.apache.org/jira/browse/LANG-1188
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.4
> Environment: javac 1.8.0_25
>Reporter: Simon KRAMER
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> commons-lang3-3.4-src/src/main/java/org/apache/commons/lang3/StringUtils.java:3302:
>  warning: [unchecked] Possible heap pollution from parameterized vararg type T
> public static  String join(final T... elements) {
>  ^
> usage: String.join(" ", stringarray)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1188) StringUtils#join(T...): warning: [unchecked] Possible heap pollution from parameterized vararg type T

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated LANG-1188:

Summary: StringUtils#join(T...): warning: [unchecked] Possible heap 
pollution from parameterized vararg type T  (was: StringUtils.java:3302: 
warning: [unchecked] Possible heap pollution from parameterized vararg type T)

> StringUtils#join(T...): warning: [unchecked] Possible heap pollution from 
> parameterized vararg type T
> -
>
> Key: LANG-1188
> URL: https://issues.apache.org/jira/browse/LANG-1188
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.4
> Environment: javac 1.8.0_25
>Reporter: Simon KRAMER
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> commons-lang3-3.4-src/src/main/java/org/apache/commons/lang3/StringUtils.java:3302:
>  warning: [unchecked] Possible heap pollution from parameterized vararg type T
> public static  String join(final T... elements) {
>  ^
> usage: String.join(" ", stringarray)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1188) StringUtils.java:3302: warning: [unchecked] Possible heap pollution from parameterized vararg type T

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated LANG-1188:

Summary: StringUtils.java:3302: warning: [unchecked] Possible heap 
pollution from parameterized vararg type T  (was: lang3/StringUtils.java:3302: 
warning: [unchecked] Possible heap pollution from parameterized vararg type T)

> StringUtils.java:3302: warning: [unchecked] Possible heap pollution from 
> parameterized vararg type T
> 
>
> Key: LANG-1188
> URL: https://issues.apache.org/jira/browse/LANG-1188
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.*
>Affects Versions: 3.4
> Environment: javac 1.8.0_25
>Reporter: Simon KRAMER
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> commons-lang3-3.4-src/src/main/java/org/apache/commons/lang3/StringUtils.java:3302:
>  warning: [unchecked] Possible heap pollution from parameterized vararg type T
> public static  String join(final T... elements) {
>  ^
> usage: String.join(" ", stringarray)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1196) Provide way to set random number generator on RandomStringUtils to enable repeatable test execution

2016-10-23 Thread Gus Power (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600144#comment-15600144
 ] 

Gus Power commented on LANG-1196:
-

Yes from a thread-safety point of view your patch of just setting the seed on 
the underlying random is definitely better. The stock Random.setSeed(seed) 
method is synchronized and so shouldn't need an explicit lock. I guess a 
possible alternative is to pass in a Random but it there are already plenty of 
randomX() style methods on there and I didn't want to create more.

I broke out the Scenario class to better understand what was happening in the 
random generation. I wasn't immediately obvious to me that it walks backwards 
through the character array, shuttling forward a step if it happens upon a 
surrogate character and it's at the first element. In this instance I was 
trying to determine whether it's a bug to allow odd numbers of characters when 
requesting UTF-16 surrogate pairs. The Scenario class passes all the units 
tests without change so it should be functionally equivalent to the existing 
implementation. 

> Provide way to set random number generator on RandomStringUtils to enable 
> repeatable test execution
> ---
>
> Key: LANG-1196
> URL: https://issues.apache.org/jira/browse/LANG-1196
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.4
> Environment: java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> Linux 4.0.5 #3 SMP Mon Sep 14 12:41:09 BST 2015 x86_64 Intel(R) Core(TM) 
> i7-4710MQ CPU @ 2.50GHz GenuineIntel GNU/Linux
>Reporter: Gus Power
>Priority: Minor
> Attachments: LANG-1196.patch
>
>
> Hi,
> I'm using [Sham 
> |http://search.maven.org/#artifactdetails%7Corg.shamdata%7Csham%7C0.3%7Cjar] 
> to generate realistic looking test data for both parameterized tests and user 
> acceptance testing. We log the seed that is used for each run so that if 
> there is an issue we can recreate exactly the same test data. I would also 
> like to use some of the commons-lang RandomStringUtils functionality but 
> notice that the implementation provides no way of setting the random number 
> generator to be used.
> {code}private static final Random RANDOM = new Random();{code}
> A way to configure this would be really useful. If there is an alternative 
> way to do this then that would be great. If you think it's a good idea and it 
> requires a patch I'm happy to supply one.
> Cheers,
> Gus.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #:

2016-10-23 Thread PascalSchumacher 
Github user PascalSchumacher commented on the pull request:


https://github.com/apache/commons-lang/commit/e4c72a5522aabfa6a660088aa9262d849756e464#commitcomment-19532086
  
In src/changes/changes.xml:
In src/changes/changes.xml on line 48:
pretty optimistic ;) :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1034) Recursive and reflective equals builder

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600083#comment-15600083
 ] 

ASF GitHub Bot commented on LANG-1034:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/202
  

[![Coverage 
Status](https://coveralls.io/builds/8467444/badge)](https://coveralls.io/builds/8467444)

Coverage decreased (-0.04%) to 93.442% when pulling 
**f4cf194decebba1b6aad156b8a0d146195708676 on 
PascalSchumacher:recursiveAndReflectiveEqualsBuilder** into 
**89afbb0c3eaa2d074dc1ef46d09675f24da0e120 on apache:master**.



> Recursive and reflective equals builder
> ---
>
> Key: LANG-1034
> URL: https://issues.apache.org/jira/browse/LANG-1034
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: Review Patch
>
> Attachments: LANG-1034.1.patch
>
>
> The current implementation of {{EqualsBuilder.reflectionEquals()}} uses 
> object equality to test reference fields found in the class. It may be 
> helpful to offer a method that recursively builds {{.equals()}} methods for 
> each field and uses that to perform the comparison.
> This functionality could be further extended by accepting a list of classes 
> to include/exclude. Classes that are excluded would use the normal object 
> equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #202: LANG-1034: Recursive and reflective EqualsBuilder

2016-10-23 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/202
  

[![Coverage 
Status](https://coveralls.io/builds/8467444/badge)](https://coveralls.io/builds/8467444)

Coverage decreased (-0.04%) to 93.442% when pulling 
**f4cf194decebba1b6aad156b8a0d146195708676 on 
PascalSchumacher:recursiveAndReflectiveEqualsBuilder** into 
**89afbb0c3eaa2d074dc1ef46d09675f24da0e120 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Closed] (LANG-1279) Update Java requirement from Java 6 to 7

2016-10-23 Thread Gary Gregory (JIRA) 

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

Gary Gregory closed LANG-1279.
--
Resolution: Fixed

In Git master.

> Update Java requirement from Java 6 to 7
> 
>
> Key: LANG-1279
> URL: https://issues.apache.org/jira/browse/LANG-1279
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: General
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 3.6
>
>
> Update Java requirement from Java 6 to 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1034) Recursive and reflective equals builder

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600066#comment-15600066
 ] 

ASF GitHub Bot commented on LANG-1034:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/202
  
I haven't locked at this in-depth yet, but seems like a useful enhancement.

I would remove the support for including transient fields, because that 
seems like a bad practice.


> Recursive and reflective equals builder
> ---
>
> Key: LANG-1034
> URL: https://issues.apache.org/jira/browse/LANG-1034
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: Review Patch
>
> Attachments: LANG-1034.1.patch
>
>
> The current implementation of {{EqualsBuilder.reflectionEquals()}} uses 
> object equality to test reference fields found in the class. It may be 
> helpful to offer a method that recursively builds {{.equals()}} methods for 
> each field and uses that to perform the comparison.
> This functionality could be further extended by accepting a list of classes 
> to include/exclude. Classes that are excluded would use the normal object 
> equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1034) Recursive and reflective equals builder

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600064#comment-15600064
 ] 

ASF GitHub Bot commented on LANG-1034:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/202
  

[![Coverage 
Status](https://coveralls.io/builds/8467369/badge)](https://coveralls.io/builds/8467369)

Coverage decreased (-0.02%) to 93.438% when pulling 
**b6eee76036d4e44f89f029aa3d45b6842598e69b on 
PascalSchumacher:recursiveAndReflectiveEqualsBuilder** into 
**eb2b89efbe15ab0b70fd94f0ecd0aa03866fb4d2 on apache:master**.



> Recursive and reflective equals builder
> ---
>
> Key: LANG-1034
> URL: https://issues.apache.org/jira/browse/LANG-1034
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: Review Patch
>
> Attachments: LANG-1034.1.patch
>
>
> The current implementation of {{EqualsBuilder.reflectionEquals()}} uses 
> object equality to test reference fields found in the class. It may be 
> helpful to offer a method that recursively builds {{.equals()}} methods for 
> each field and uses that to perform the comparison.
> This functionality could be further extended by accepting a list of classes 
> to include/exclude. Classes that are excluded would use the normal object 
> equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #202: LANG-1034: Recursive and reflective EqualsBuilder

2016-10-23 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/202
  
I haven't locked at this in-depth yet, but seems like a useful enhancement.

I would remove the support for including transient fields, because that 
seems like a bad practice.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang issue #202: LANG-1034: Recursive and reflective EqualsBuilder

2016-10-23 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/202
  

[![Coverage 
Status](https://coveralls.io/builds/8467369/badge)](https://coveralls.io/builds/8467369)

Coverage decreased (-0.02%) to 93.438% when pulling 
**b6eee76036d4e44f89f029aa3d45b6842598e69b on 
PascalSchumacher:recursiveAndReflectiveEqualsBuilder** into 
**eb2b89efbe15ab0b70fd94f0ecd0aa03866fb4d2 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1034) Recursive and reflective equals builder

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600056#comment-15600056
 ] 

ASF GitHub Bot commented on LANG-1034:
--

GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-lang/pull/202

LANG-1034: Recursive and reflective EqualsBuilder

patch by yathos UG

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-lang 
recursiveAndReflectiveEqualsBuilder

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/202.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #202


commit b6eee76036d4e44f89f029aa3d45b6842598e69b
Author: pascalschumacher 
Date:   2016-10-23T17:56:28Z

LANG-1034: Recursive and reflective EqualsBuilder

patch by yathos UG




> Recursive and reflective equals builder
> ---
>
> Key: LANG-1034
> URL: https://issues.apache.org/jira/browse/LANG-1034
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*
>Reporter: Duncan Jones
>Assignee: Duncan Jones
> Fix For: Review Patch
>
> Attachments: LANG-1034.1.patch
>
>
> The current implementation of {{EqualsBuilder.reflectionEquals()}} uses 
> object equality to test reference fields found in the class. It may be 
> helpful to offer a method that recursively builds {{.equals()}} methods for 
> each field and uses that to perform the comparison.
> This functionality could be further extended by accepting a list of classes 
> to include/exclude. Classes that are excluded would use the normal object 
> equality.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #202: LANG-1034: Recursive and reflective EqualsBu...

2016-10-23 Thread PascalSchumacher 
GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-lang/pull/202

LANG-1034: Recursive and reflective EqualsBuilder

patch by yathos UG

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-lang 
recursiveAndReflectiveEqualsBuilder

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/202.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #202


commit b6eee76036d4e44f89f029aa3d45b6842598e69b
Author: pascalschumacher 
Date:   2016-10-23T17:56:28Z

LANG-1034: Recursive and reflective EqualsBuilder

patch by yathos UG




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (LANG-1279) Update Java requirement from Java 6 to 7

2016-10-23 Thread Gary Gregory (JIRA) 
Gary Gregory created LANG-1279:
--

 Summary: Update Java requirement from Java 6 to 7
 Key: LANG-1279
 URL: https://issues.apache.org/jira/browse/LANG-1279
 Project: Commons Lang
  Issue Type: Improvement
  Components: General
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 3.6


Update Java requirement from Java 6 to 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LANG-1144) Multiple calls of org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible

2016-10-23 Thread Gary Gregory (JIRA) 

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

Gary Gregory resolved LANG-1144.

   Resolution: Fixed
Fix Version/s: 3.6

In Git master. 

Please verify and close.

> Multiple calls of 
> org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible
> ---
>
> Key: LANG-1144
> URL: https://issues.apache.org/jira/browse/LANG-1144
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.concurrent.*
>Affects Versions: 3.4, 3.5
> Environment: Java 1.8 on Windows 7 x64
>Reporter: Waldemar Maier
>Assignee: Gary Gregory
> Fix For: 3.6
>
> Attachments: 0001-LANG-1144-allow-nulls-as-return-value.patch, 
> commons-lang.patch
>
>
> It is possible to create a construct, that allows multiple calls of 
> LazyInitializer.initialize, when calculations (which can be very expensive) 
> return null as result. 
> In the Javadoc is described that the initialize method will be called only on 
> the first access
> {code:java}
> /**
>  * Creates and initializes the object managed by this {@code
>  * LazyInitializer}. This method is called by {@link #get()} when the 
> object
>  * is accessed for the first time. An implementation can focus on the
>  * creation of the object. No synchronization is needed, as this is 
> already
>  * handled by {@code get()}.
>  *
>  * @return the managed data object
>  * @throws ConcurrentException if an error occurs during object creation
>  */
> protected abstract T initialize() throws ConcurrentException;
> {code}
> The Junit Test can be something like this:
> *(fix can be appplied from attached patch-file)*
> {code:java}
> package edu.test;
> import static org.junit.Assert.assertEquals;
> import org.apache.commons.lang3.concurrent.ConcurrentException;
> import org.apache.commons.lang3.concurrent.LazyInitializer;
> import org.junit.Test;
> public class LazyInitializerTest {
>   private int lazyinitCounter = 0;
>   private LazyInitializer lazyIinit = new LazyInitializer() {
> @Override
> protected Object initialize() throws ConcurrentException {
>   lazyinitCounter++;
>   return doSomeVeryExpensiveOperations();
> }
>   };
>   
>   
>   private Object doSomeVeryExpensiveOperations() {
> // do db calls
> // do some complex math calculations
> // the result of them all is null
> return null;
>   }
>   
>   
>   @Test
>   public void testInitialization() throws Exception {
> lazyIinit.get();
> lazyIinit.get();
> assertEquals("Multiple call of LazyInitializer#initialize", 1, 
> lazyinitCounter);
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1144) Multiple calls of org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible

2016-10-23 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated LANG-1144:
---
Affects Version/s: 3.5

> Multiple calls of 
> org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible
> ---
>
> Key: LANG-1144
> URL: https://issues.apache.org/jira/browse/LANG-1144
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.concurrent.*
>Affects Versions: 3.4, 3.5
> Environment: Java 1.8 on Windows 7 x64
>Reporter: Waldemar Maier
>Assignee: Gary Gregory
> Fix For: 3.6
>
> Attachments: 0001-LANG-1144-allow-nulls-as-return-value.patch, 
> commons-lang.patch
>
>
> It is possible to create a construct, that allows multiple calls of 
> LazyInitializer.initialize, when calculations (which can be very expensive) 
> return null as result. 
> In the Javadoc is described that the initialize method will be called only on 
> the first access
> {code:java}
> /**
>  * Creates and initializes the object managed by this {@code
>  * LazyInitializer}. This method is called by {@link #get()} when the 
> object
>  * is accessed for the first time. An implementation can focus on the
>  * creation of the object. No synchronization is needed, as this is 
> already
>  * handled by {@code get()}.
>  *
>  * @return the managed data object
>  * @throws ConcurrentException if an error occurs during object creation
>  */
> protected abstract T initialize() throws ConcurrentException;
> {code}
> The Junit Test can be something like this:
> *(fix can be appplied from attached patch-file)*
> {code:java}
> package edu.test;
> import static org.junit.Assert.assertEquals;
> import org.apache.commons.lang3.concurrent.ConcurrentException;
> import org.apache.commons.lang3.concurrent.LazyInitializer;
> import org.junit.Test;
> public class LazyInitializerTest {
>   private int lazyinitCounter = 0;
>   private LazyInitializer lazyIinit = new LazyInitializer() {
> @Override
> protected Object initialize() throws ConcurrentException {
>   lazyinitCounter++;
>   return doSomeVeryExpensiveOperations();
> }
>   };
>   
>   
>   private Object doSomeVeryExpensiveOperations() {
> // do db calls
> // do some complex math calculations
> // the result of them all is null
> return null;
>   }
>   
>   
>   @Test
>   public void testInitialization() throws Exception {
> lazyIinit.get();
> lazyIinit.get();
> assertEquals("Multiple call of LazyInitializer#initialize", 1, 
> lazyinitCounter);
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1145) 64 bit check in SystemUtils

2016-10-23 Thread Pascal Schumacher (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15600011#comment-15600011
 ] 

Pascal Schumacher commented on LANG-1145:
-

I'm not sure what is requested here. The StackOverflow link describes a way to 
check if the windows operating system is 64-bit, while the spark link checks if 
the JVM uses 64-bit.

> 64 bit check in SystemUtils
> ---
>
> Key: LANG-1145
> URL: https://issues.apache.org/jira/browse/LANG-1145
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Gabor Liptak
>Priority: Minor
>
> Add is64bit method to SystemUtils.java
> http://stackoverflow.com/a/2269242/304690 for Windows snippet and
> https://github.com/apache/spark/blob/master/core/src/main/scala/org/apache/spark/util/SizeEstimator.scala
>  for zOS snippet



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1550#comment-1550
 ] 

ASF GitHub Bot commented on LANG-1143:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/201
  

[![Coverage 
Status](https://coveralls.io/builds/8467115/badge)](https://coveralls.io/builds/8467115)

Coverage increased (+0.02%) to 93.57% when pulling 
**fc0f62597b8f0284413ea35c1d958e30fe20392f on PascalSchumacher:LANG-1143** into 
**65ed41ff7a8cfb0bbc03620e186382a16e23db56 on apache:master**.



> StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
> ---
>
> Key: LANG-1143
> URL: https://issues.apache.org/jira/browse/LANG-1143
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Sebb
> Fix For: Review Patch
>
> Attachments: LANG-1143.patch
>
>
> The Javadoc for Character#toTitleCase(char) recommends using 
> Character#toTitleCase(int) instead. This method was added in Java 1.5 which 
> is perhaps is why it was not used originally; maybe we should use it now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #201: LANG-1143: StringUtils should use toXxxxCase(int) r...

2016-10-23 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/201
  

[![Coverage 
Status](https://coveralls.io/builds/8467115/badge)](https://coveralls.io/builds/8467115)

Coverage increased (+0.02%) to 93.57% when pulling 
**fc0f62597b8f0284413ea35c1d958e30fe20392f on PascalSchumacher:LANG-1143** into 
**65ed41ff7a8cfb0bbc03620e186382a16e23db56 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1143) StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599983#comment-15599983
 ] 

ASF GitHub Bot commented on LANG-1143:
--

GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-lang/pull/201

LANG-1143: StringUtils should use toXxxxCase(int) rather than toXxxxC…

…ase(char)

based on patch by Sebb

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-lang LANG-1143

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/201.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #201


commit fc0f62597b8f0284413ea35c1d958e30fe20392f
Author: pascalschumacher 
Date:   2016-10-23T17:07:04Z

LANG-1143: StringUtils should use toXxxxCase(int) rather than 
toXxxxCase(char)

based on patch by Sebb




> StringUtils should use toXxxxCase(int) rather than toXxxxCase(char)
> ---
>
> Key: LANG-1143
> URL: https://issues.apache.org/jira/browse/LANG-1143
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Reporter: Sebb
> Fix For: Review Patch
>
> Attachments: LANG-1143.patch
>
>
> The Javadoc for Character#toTitleCase(char) recommends using 
> Character#toTitleCase(int) instead. This method was added in Java 1.5 which 
> is perhaps is why it was not used originally; maybe we should use it now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #201: LANG-1143: StringUtils should use toXxxxCase...

2016-10-23 Thread PascalSchumacher 
GitHub user PascalSchumacher opened a pull request:

https://github.com/apache/commons-lang/pull/201

LANG-1143: StringUtils should use toXxxxCase(int) rather than toXxxxC…

…ase(char)

based on patch by Sebb

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PascalSchumacher/commons-lang LANG-1143

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/201.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #201


commit fc0f62597b8f0284413ea35c1d958e30fe20392f
Author: pascalschumacher 
Date:   2016-10-23T17:07:04Z

LANG-1143: StringUtils should use toXxxxCase(int) rather than 
toXxxxCase(char)

based on patch by Sebb




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LANG-1144) Multiple calls of org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible

2016-10-23 Thread Oliver Heger (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599914#comment-15599914
 ] 

Oliver Heger commented on LANG-1144:


The patch looks good to me, but I would propose to make the special noInit 
object even *static*.

Regarding exception handling: I think, the currently implemented solution is 
in-line with the approach taken by the JDK. See for instance {{Future.get()}}, 
which throws an {{ExecutionException}}. There is also some support for the 
exception type in the {{ConcurrentUtils}} class.

> Multiple calls of 
> org.apache.commons.lang3.concurrent.LazyInitializer.initialize() are possible
> ---
>
> Key: LANG-1144
> URL: https://issues.apache.org/jira/browse/LANG-1144
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.concurrent.*
>Affects Versions: 3.4
> Environment: Java 1.8 on Windows 7 x64
>Reporter: Waldemar Maier
>Assignee: Gary Gregory
> Attachments: 0001-LANG-1144-allow-nulls-as-return-value.patch, 
> commons-lang.patch
>
>
> It is possible to create a construct, that allows multiple calls of 
> LazyInitializer.initialize, when calculations (which can be very expensive) 
> return null as result. 
> In the Javadoc is described that the initialize method will be called only on 
> the first access
> {code:java}
> /**
>  * Creates and initializes the object managed by this {@code
>  * LazyInitializer}. This method is called by {@link #get()} when the 
> object
>  * is accessed for the first time. An implementation can focus on the
>  * creation of the object. No synchronization is needed, as this is 
> already
>  * handled by {@code get()}.
>  *
>  * @return the managed data object
>  * @throws ConcurrentException if an error occurs during object creation
>  */
> protected abstract T initialize() throws ConcurrentException;
> {code}
> The Junit Test can be something like this:
> *(fix can be appplied from attached patch-file)*
> {code:java}
> package edu.test;
> import static org.junit.Assert.assertEquals;
> import org.apache.commons.lang3.concurrent.ConcurrentException;
> import org.apache.commons.lang3.concurrent.LazyInitializer;
> import org.junit.Test;
> public class LazyInitializerTest {
>   private int lazyinitCounter = 0;
>   private LazyInitializer lazyIinit = new LazyInitializer() {
> @Override
> protected Object initialize() throws ConcurrentException {
>   lazyinitCounter++;
>   return doSomeVeryExpensiveOperations();
> }
>   };
>   
>   
>   private Object doSomeVeryExpensiveOperations() {
> // do db calls
> // do some complex math calculations
> // the result of them all is null
> return null;
>   }
>   
>   
>   @Test
>   public void testInitialization() throws Exception {
> lazyIinit.get();
> lazyIinit.get();
> assertEquals("Multiple call of LazyInitializer#initialize", 1, 
> lazyinitCounter);
>   }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (LANG-965) FieldUtils methods leak accessible flags

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher closed LANG-965.
--
   Resolution: Won't Fix
 Assignee: (was: Benedikt Ritter)
Fix Version/s: (was: Patch Needed)

I'm closing this as "Won't Fix" because (as Joerg said) setAccessible only 
modifies the behavior of the Field object not of the actual underlying field of 
the object. 

> FieldUtils methods leak accessible flags
> 
>
> Key: LANG-965
> URL: https://issues.apache.org/jira/browse/LANG-965
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.reflect.*
>Affects Versions: 3.1, 3.2.1
> Environment: Apache Maven 3.1.1 
> (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400)
> Maven home: C:\Java\apache-maven-3.1.1\bin\..
> Java version: 1.7.0_51, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_51\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
> Attachments: commons-lang-965.patch, commons-lang-965.patch
>
>
> When various FieldUtils methods are called the accessible is set to true but 
> never reset to false. This is side-effect should be cleaned up.
> This makes a mess of the object model which represents the class meta data.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (LANG-1276) StrBuilder#replaceAll ArrayIndexOutOfBoundsException

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher resolved LANG-1276.
-
   Resolution: Fixed
 Assignee: Pascal Schumacher
Fix Version/s: (was: Patch Needed)

Pull request merged. Thanks for the pull request and thanks for reporting!

> StrBuilder#replaceAll ArrayIndexOutOfBoundsException
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.text.*
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1276) StrBuilder#replaceAll ArrayIndexOutOfBoundsException

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated LANG-1276:

Component/s: lang.text.*

> StrBuilder#replaceAll ArrayIndexOutOfBoundsException
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.text.*
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1276) StrBuilder#replaceAll ArrayIndexOutOfBoundsException

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599818#comment-15599818
 ] 

ASF GitHub Bot commented on LANG-1276:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/200
  
Thanks! :+1: 


> StrBuilder#replaceAll ArrayIndexOutOfBoundsException
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1276) StrBuilder#replaceAll ArrayIndexOutOfBoundsException

2016-10-23 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599817#comment-15599817
 ] 

ASF GitHub Bot commented on LANG-1276:
--

Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/200


> StrBuilder#replaceAll ArrayIndexOutOfBoundsException
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #200: LANG-1276

2016-10-23 Thread PascalSchumacher 
Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/200
  
Thanks! :+1: 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] commons-lang pull request #200: LANG-1276

2016-10-23 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/commons-lang/pull/200


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (LANG-1276) StrBuilder#replaceAll ArrayIndexOutOfBoundsException

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated LANG-1276:

Summary: StrBuilder#replaceAll ArrayIndexOutOfBoundsException  (was: 
ArrayIndexOutOfBoundsException StrBuilder replace)

> StrBuilder#replaceAll ArrayIndexOutOfBoundsException
> 
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (LANG-1276) ArrayIndexOutOfBoundsException StrBuilder replace

2016-10-23 Thread Pascal Schumacher (JIRA) 

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

Pascal Schumacher updated LANG-1276:

Summary: ArrayIndexOutOfBoundsException StrBuilder replace  (was: [lang] 
ArrayIndexOutOfBoundsException StrBuilder replace)

> ArrayIndexOutOfBoundsException StrBuilder replace
> -
>
> Key: LANG-1276
> URL: https://issues.apache.org/jira/browse/LANG-1276
> Project: Commons Lang
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.4, 3.5
>Reporter: Andreas Skomedal
> Fix For: Patch Needed, 3.6
>
>
> There is a bug in replace for StrBuilder, seems the use of nonupdated buffer 
> and character count is off.
> new StrBuilder("Dear X, hello X.").replaceAll(StrMatcher.stringMatcher("X"), 
> "012345678901234567");
> yields
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 49
>   at 
> org.apache.commons.lang3.text.StrMatcher$StringMatcher.isMatch(StrMatcher.java:372)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceImpl(StrBuilder.java:2115)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replace(StrBuilder.java:2088)
>   at 
> org.apache.commons.lang3.text.StrBuilder.replaceAll(StrBuilder.java:2049)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (DAEMON-357) Removing __try/__finally syntactic sugar

2016-10-23 Thread Guillaume Chauvet (JIRA) 

[ 
https://issues.apache.org/jira/browse/DAEMON-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599667#comment-15599667
 ] 

Guillaume Chauvet edited comment on DAEMON-357 at 10/23/16 1:17 PM:


I request a validation to be sure to not introduce an unexpected behaviour.
I've tested this patch with MinGW toolchain, not MSVC.


was (Author: gchauvet):
I request a validation to be sure to not introduce an unexpected behaviour.
I've tested this patch wirh a MinGW toolchain, not MSVC.

> Removing __try/__finally syntactic sugar
> 
>
> Key: DAEMON-357
> URL: https://issues.apache.org/jira/browse/DAEMON-357
> Project: Commons Daemon
>  Issue Type: Task
>Reporter: Guillaume Chauvet
>Priority: Minor
> Attachments: DAEMON-357.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I submit this patch to remove "__try" and "__finally" syntactic sugars from C 
> source code, to prevent any specific compiler extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DAEMON-357) Removing __try/__finally syntactic sugar

2016-10-23 Thread Guillaume Chauvet (JIRA) 

[ 
https://issues.apache.org/jira/browse/DAEMON-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15599667#comment-15599667
 ] 

Guillaume Chauvet commented on DAEMON-357:
--

I request a validation to be sure to not introduce an unexpected behaviour.
I've tested this patch wirh a MinGW toolchain, not MSVC.

> Removing __try/__finally syntactic sugar
> 
>
> Key: DAEMON-357
> URL: https://issues.apache.org/jira/browse/DAEMON-357
> Project: Commons Daemon
>  Issue Type: Task
>Reporter: Guillaume Chauvet
>Priority: Minor
> Attachments: DAEMON-357.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I submit this patch to remove "__try" and "__finally" syntactic sugars from C 
> source code, to prevent any specific compiler extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DAEMON-357) Removing __try/__finally syntactic sugar

2016-10-23 Thread Guillaume Chauvet (JIRA) 

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

Guillaume Chauvet updated DAEMON-357:
-
Attachment: DAEMON-357.patch

> Removing __try/__finally syntactic sugar
> 
>
> Key: DAEMON-357
> URL: https://issues.apache.org/jira/browse/DAEMON-357
> Project: Commons Daemon
>  Issue Type: Task
>Reporter: Guillaume Chauvet
>Priority: Minor
> Attachments: DAEMON-357.patch
>
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I submit this patch to remove "__try" and "__finally" syntactic sugars from C 
> source code, to prevent any specific compiler extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DAEMON-357) Removing __try/__finally syntactic sugar

2016-10-23 Thread Guillaume Chauvet (JIRA) 
Guillaume Chauvet created DAEMON-357:


 Summary: Removing __try/__finally syntactic sugar
 Key: DAEMON-357
 URL: https://issues.apache.org/jira/browse/DAEMON-357
 Project: Commons Daemon
  Issue Type: Task
Reporter: Guillaume Chauvet
Priority: Minor


I submit this patch to remove "__try" and "__finally" syntactic sugars from C 
source code, to prevent any specific compiler extensions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)