[jira] [Commented] (BEANUTILS-532) Require commons-beanutils library which supports commons-collections-4.x version

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17468620#comment-17468620
 ] 

Melloware commented on BEANUTILS-532:
-

[~NicolaIsotta] I forked it for the exact reasons you mentioned and its on 
Maven Central:


{code:xml}

  com.melloware
  commons-beanutils2
  2.0.0

{code}


> Require commons-beanutils library which supports commons-collections-4.x 
> version 
> -
>
> Key: BEANUTILS-532
> URL: https://issues.apache.org/jira/browse/BEANUTILS-532
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean-Collections
>Reporter: AvanthikaNC
>Priority: Blocker
> Attachments: image-2020-01-31-14-52-43-114.png
>
>
> Hi Team,
>  
>  We are working on ATM SWITCH project and the project currently uses 
> commons-beanutils library 1.9.4 and we have upgraded to 
> commons-collections-4.1 as part of our project requirement as it contained 
> vulnerabilities.
> We are facing some errors due to the above mentioned upgrade as 
> commons-beanutils library 1.9.4 will support commons-collections 3.2.2 
> version.
> Now as per our requirement we cannot downgrade common-collections library but 
> we need commons-beanutils library which supports commons-collections4-4.1 
> version.
> Please provide your response asap.
> Thanks



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17304098#comment-17304098
 ] 

Melloware commented on BEANUTILS-509:
-

[~suvp_nokia] its still not released yet but I cut my own version you can use 
on Maven Central found here:
{code:java}

  com.melloware
  commons-beanutils2
  2.0.0

 {code}

> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, 
> 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, 
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We noticed that our application was using too much of CPU , all the 6 cores 
> were used. 
> On capturing the thread dump we saw that large number of threads were in the 
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
>  at 
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>  
> So we are suspecting that the thread has entered into indefinite while loop 
> and hogging all the CPU resources.
> I have attached the thread dump for reference.  
>  
> what is the solution for this issue?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17291666#comment-17291666
 ] 

Melloware commented on IO-663:
--

[~ggregory] Yes it does.  Which would explain in the previous version our 
random AccessDenied exceptions. Now it seems nothing gets copied at all.  But I 
revert back to 2.6.0 all is working fine.

 
{code:java}

java.nio.file.AccessDeniedException: .\runtime\test.csv -> 
.\runtime\copy\test.csv
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at 
sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at 
sun.nio.fs.WindowsFileCopy.copy(Unknown Source) at 
sun.nio.fs.WindowsFileSystemProvider.copy(Unknown Source) at 
java.nio.file.Files.copy(Unknown Source) at 
org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1392) at 
org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1354) at 
org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1352) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:733) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:659) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:606) at  {code}

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290154#comment-17290154
 ] 

Melloware commented on IO-663:
--

When I run this locally on Windows 10 it works fine...
{code:java}
final File sourceDir = new File("C:\\Personal\\temp\\dev");
final File testDir = new File("C:\\Personal\\temp\\dev-copy");
FileUtils.copyDirectory(sourceDir, testDir);
 {code}
 

My prod environment is Windows 2008 and the code runs as a Service with a 
different account than the main LAN account.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287956#comment-17287956
 ] 

Melloware edited comment on IO-663 at 2/21/21, 1:13 PM:


So I don't have access to the server but I swapped out our same exact 
executable with the only difference being 2.6.0 vs 2.9.0-SNAPSHOT.  Our process 
runs on a Windows 2008 server and before we run any code we make a copy of all 
our input files to a new directory so we are never working on the originals.

We use `FileUtils.copyDirectory` to do the copy and our application immediately 
started reporting errors of "missing files". Sure enough when we look in the 
directory that was copied to... its completely empty.  So its like it didn't 
actually copy all the files.


was (Author: melloware):
So I don't have access to the server but I swapped out our same exact 
executable with the only difference being 2.6.0 vs 2.9.0-SNAPSHOT.  Our process 
runs on a Windows 2008 server and before we run any code we make a copy of all 
our input files to a new directory so we are never working on the originals.

We use `FileUtils.copyDirectory` to do the copy and our application immediately 
started reporting errors of "missing files". Sure enough when we look in the 
directory that was copied its completely empty.  So its like it didn't actually 
copy all the files.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287956#comment-17287956
 ] 

Melloware commented on IO-663:
--

So I don't have access to the server but I swapped out our same exact 
executable with the only difference being 2.6.0 vs 2.9.0-SNAPSHOT.  Our process 
runs on a Windows 2008 server and before we run any code we make a copy of all 
our input files to a new directory so we are never working on the originals.

We use `FileUtils.copyDirectory` to do the copy and our application immediately 
started reporting errors of "missing files". Sure enough when we look in the 
directory that was copied its completely empty.  So its like it didn't actually 
copy all the files.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287159#comment-17287159
 ] 

Melloware commented on IO-663:
--

Nope all i did was swap out 2.6 for 2.9.0-SNAPSHOT in our app and it failed 
catstrophically.  All with "Missing files".  So i am looking and directories 
are empty like it didn't copy the files or copied them so my app can't see 
them.  So whatever it was it didn't make it better.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17287062#comment-17287062
 ] 

Melloware commented on IO-663:
--

[~ggregory] I got permission from my client to test the SNAPSHOT version. We 
are going to put it on two of our servers and monitor for at least a week or 
more.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17285972#comment-17285972
 ] 

Melloware commented on IO-663:
--

Gary unfortunately I was not given permission to run a SNAPSHOT version in our 
Environment so I will report back once this is released and then I will run a 
burn in test with it so we can know whether this ticket is fixed or not.  Sorry 
I can't give a better answer than that.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-533) If expression contains ")", DefaultResolver #getKey return wrong value

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17284412#comment-17284412
 ] 

Melloware commented on BEANUTILS-533:
-

[~amakachi] you can code review and comment on this already submitted PR for 
this issue here: https://github.com/apache/commons-beanutils/pull/65

> If expression contains ")", DefaultResolver #getKey return wrong value
> --
>
> Key: BEANUTILS-533
> URL: https://issues.apache.org/jira/browse/BEANUTILS-533
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.9.3
>Reporter: Maxime Garenne
>Priority: Blocker
>
> h2. Context
> I use BeanUtils to return a map that contain properties.
> I had a failure in my code because this property causes a fail in the 
> BeanUtils "getMappedProperty" method :
> test(myvalue(ineedthisparenthis))
> h2. Explanation
> In DefaultResolver #getKey(String expression), if the expression contains a 
> ")", the returned value is incorrect because the algorithm stops at the first 
> ")" character (#indefOf is used).
> In my example, the method now returns : "myvalue(ineedthisparenthis". It 
> should be "myvalue(ineedthisparenthis) with proprerty name = "test".
> Instead of using :
> {code:java}
> final int end = expression.indexOf(MAPPED_END, i);{code}
> It would be better to just check if the last character of "expression" is a 
> ")" and then substring between "i+1" and last character index.
> Then my example would not fail. 
>  
> This occurs in version 1.7.
> I checked in upper versions, the method is different but still wrong because 
> the method indexOf is still used (taking again the first ")" found). 
>  # escape # parenthesis # bracket # DefaultResolver # getKey # expression
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17267544#comment-17267544
 ] 

Melloware commented on IO-663:
--

I will see if I am allowed to run one of our servers with a SNAPSHOT release to 
let it burn it.  Like I said its intermittent right now so out of 504 runs a 
week it happens maybe once or twice.  I will let you know what I find out.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Jenkins CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
>  {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
>  {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
>  {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-541) FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17261289#comment-17261289
 ] 

Melloware commented on BEANUTILS-541:
-

Do you have a fix? IF so please submit a PR to GitHub.

> FluentPropertyBeanIntrospector caches corrupted writeMethod (two subclasses)
> 
>
> Key: BEANUTILS-541
> URL: https://issues.apache.org/jira/browse/BEANUTILS-541
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3, 1.9.4
>Reporter: Sergey Chernov
>Priority: Blocker
>
> There is an issue in {{FluentPropertyBeanIntrospector}} (at line 144 for 
> 1.9.3), it caches wrong writeMethod in the static cache of 
> {{java.beans.Introspector when base class has at least two subclasses}}. 
> Simple snippet to reproduce:
> {code:java}
> import org.apache.commons.beanutils.FluentPropertyBeanIntrospector;
> import org.apache.commons.beanutils.PropertyUtilsBean;
> public class BeanUtilsTest {
> public static void main(String[] args) throws Exception {
> PropertyUtilsBean propertyUtilsBean = new PropertyUtilsBean();
> propertyUtilsBean.addBeanIntrospector(new 
> FluentPropertyBeanIntrospector());
> // invert if condition and it will succeed
> if (true) {
> // fails
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> // uncomment this line and the failure will be handled 
> (workaround)
> //java.beans.Introspector.flushCaches();
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> } else {
> // the same as above, but reverse order - success
> SubTypeB subTypeB = new SubTypeB();
> //subTypeB.setField("name");
> propertyUtilsBean.setProperty(subTypeB, "field", "name");
> SubTypeA subTypeA = new SubTypeA();
> //subTypeA.setField("name");
> propertyUtilsBean.setProperty(subTypeA, "field", "name");
> }
> }
> public static class BaseType {
> private String field;
> public BaseType setField(String objectName) {
> this.field = objectName;
> return this;
> }
> public String getField() {
> return field;
> }
> }
> public static class SubTypeA extends BaseType {
> @Override
> public SubTypeA setField(String field) {
> super.setField(field);
> return this;
> }
> }
> public static class SubTypeB extends BaseType {
> }
> }
> {code}
>  
> It is critical, because wrong information is stored globally unless explicit 
> {{Introspector.flushCaches}} ({{Introspector.flushFromCaches}}) is called.
> Failure stacktrace:
> {code}
> Exception in thread "main" java.lang.IllegalArgumentException: 
> org.jeasy.random.BeanUtilsTest$SubTypeB is not assignable from 
> org.jeasy.random.BeanUtilsTest$SubTypeA
>   at 
> org.apache.commons.beanutils.MethodUtils.getAccessibleMethod(MethodUtils.java:793)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getWriteMethod(PropertyUtilsBean.java:1319)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.setSimpleProperty(PropertyUtilsBean.java:2094)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.setNestedProperty(PropertyUtilsBean.java:1915)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.setProperty(PropertyUtilsBean.java:2022)
>   at org.jeasy.random.BeanUtilsTest.main(BeanUtilsTest.java:44)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (IO-663) FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17260735#comment-17260735
 ] 

Melloware commented on IO-663:
--

We have a similar issues that only occurs intermittently on Window 10 using 
FileUtils.copyDirectory getting "java.nio.file.AccessDeniedException".  We have 
a process that runs every hour and fails every once in a while.   It has been 
working fine for years on IO 2.6 which used a homegrown doCopyFile method.  Now 
its using Files.copy() and we see this intermittent error.

Stack Trace:
{code:java}
java.nio.file.AccessDeniedException: .\runtime\test.csv -> 
.\runtime\copy\test.csv
at sun.nio.fs.WindowsException.translateToIOException(Unknown Source) at 
sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source) at 
sun.nio.fs.WindowsFileCopy.copy(Unknown Source) at 
sun.nio.fs.WindowsFileSystemProvider.copy(Unknown Source) at 
java.nio.file.Files.copy(Unknown Source) at 
org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1392) at 
org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1354) at 
org.apache.commons.io.FileUtils.doCopyDirectory(FileUtils.java:1352) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:733) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:659) at 
org.apache.commons.io.FileUtils.copyDirectory(FileUtils.java:606) at 
{code}
We switched back to IO 2.6 and everything is working fine.

> FileUtils.copyDirectory(File srcDir, File destDir) fails on Windows
> ---
>
> Key: IO-663
> URL: https://issues.apache.org/jira/browse/IO-663
> Project: Commons IO
>  Issue Type: Bug
>Reporter: Elliotte Rusty Harold
>Priority: Critical
>
> This bug is shared (likely because of code copied from one place to another) 
> between the similar methods in commons IO, codehaus-plexus-utils, and 
> maven-shared-utils.
> I don't have an isolated test case because this bug is platform specific and 
> I've only seen it in Travis CI builds on Windows using JDK 7 through 15. I 
> don't have a Windows system handy to test it. However it is reproducible.
> Typical code that triggers it is in RestoreBackupPomsPhaseTest in 
> maven-release:
> {{// copy poms so tests are valid without clean}}
> {{  File sourceDir = getTestFile( "src/test/resources" + projectPath );}}
> {{  File testDir = getTestFile( "target/test-classes" + projectPath );}}
> {{  FileUtils.copyDirectoryStructure( sourceDir, testDir );}}
> I don't know whether there might be something weird in the setup of those two 
> directories that's involved.
> Typical error message is:
> Caused by: java.nio.file.FileSystemException:
>  
> F:\jenkins\jenkins-slave\workspace\maven-box_maven-release_windows@2@2\windows-jdk8-m3.6.x_build\maven-release-manager\target\test-classes\projects\restore-backup-poms\basic-pom\pom.xml:
>  The process cannot access the file because it is being used by another 
> process
> "The process cannot access the file because it is being used by another 
> process" I think points to the root of the bug. This is a Windows file system 
> error message.
> Some history is here where I noticed it:
> [https://github.com/apache/maven-release/pull/42]
> In this case, I started with plexus-utils 3.1.0 which worked, upgraded to 
> plexus-utils 3.3.0, which didn't. And then tried the FileUtils.copyDirectory 
> from both maven-shared-utils and commons-io, all of which failed in the same 
> way.
> I think this is caused by the use of NIO, which doesn't work quite the same 
> when copying files on Windows as on Linux and Mac OS X.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213980#comment-17213980
 ] 

Melloware commented on BEANUTILS-509:
-

That's up to Apache PMC committers to review the PR and merge.  So I can't 
answer.

> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, 
> 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, 
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We noticed that our application was using too much of CPU , all the 6 cores 
> were used. 
> On capturing the thread dump we saw that large number of threads were in the 
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
>  at 
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>  
> So we are suspecting that the thread has entered into indefinite while loop 
> and hogging all the CPU resources.
> I have attached the thread dump for reference.  
>  
> what is the solution for this issue?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17213479#comment-17213479
 ] 

Melloware commented on BEANUTILS-509:
-

You can build a BETA version from this PR that hopefully fixes the issue: 
https://github.com/apache/commons-beanutils/pull/37

> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, 
> 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, 
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We noticed that our application was using too much of CPU , all the 6 cores 
> were used. 
> On capturing the thread dump we saw that large number of threads were in the 
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
>  at 
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>  
> So we are suspecting that the thread has entered into indefinite while loop 
> and hogging all the CPU resources.
> I have attached the thread dump for reference.  
>  
> what is the solution for this issue?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (BEANUTILS-533) If expression contains ")", DefaultResolver #getKey return wrong value

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051629#comment-17051629
 ] 

Melloware edited comment on BEANUTILS-533 at 3/4/20, 9:09 PM:
--

I just updated the DefaultResolverTestCase unit test with your new property 
values and verified your issue.

{code:java}
// Mapped Properties Test Data
private final String[] validMapProperties = new String[] {"a(b)", "c(de)", 
"fg(h)", "ij(kl)", "mno(pqr.s)", "tuv(wx).yz[1]", 
"test(myvalue(ineedthisparenthis))"};
private final String[] validMapNames  = new String[] {"a","c", 
"fg","ij", "mno","tuv", "test"};
private final String[] validMapKeys   = new String[] {"b","de","h", 
"kl", "pqr.s",  "wx",  "myvalue(ineedthisparenthis)"};
{code}


was (Author: melloware):
I just updated the DefaultResolverTestCase unit test with you new property 
values against the code in MASTER and its working fine.

{code:java}
// Mapped Properties Test Data
private final String[] validMapProperties = new String[] {"a(b)", "c(de)", 
"fg(h)", "ij(kl)", "mno(pqr.s)", "tuv(wx).yz[1], 
test(myvalue(ineedthisparenthis))"};
private final String[] validMapNames  = new String[] {"a","c", 
"fg","ij", "mno","tuv", "test"};
private final String[] validMapKeys   = new String[] {"b","de","h", 
"kl", "pqr.s",  "wx",  "myvalue(ineedthisparenthis)"};
{code}

> If expression contains ")", DefaultResolver #getKey return wrong value
> --
>
> Key: BEANUTILS-533
> URL: https://issues.apache.org/jira/browse/BEANUTILS-533
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.9.3
>Reporter: Maxime Garenne
>Priority: Blocker
>
> h2. Context
> I use BeanUtils to return a map that contain properties.
> I had a failure in my code because this property causes a fail in the 
> BeanUtils "getMappedProperty" method :
> test(myvalue(ineedthisparenthis))
> h2. Explanation
> In DefaultResolver #getKey(String expression), if the expression contains a 
> ")", the returned value is incorrect because the algorithm stops at the first 
> ")" character (#indefOf is used).
> In my example, the method now returns : "myvalue(ineedthisparenthis". It 
> should be "myvalue(ineedthisparenthis) with proprerty name = "test".
> Instead of using :
> {code:java}
> final int end = expression.indexOf(MAPPED_END, i);{code}
> It would be better to just check if the last character of "expression" is a 
> ")" and then substring between "i+1" and last character index.
> Then my example would not fail. 
>  
> This occurs in version 1.7.
> I checked in upper versions, the method is different but still wrong because 
> the method indexOf is still used (taking again the first ")" found). 
>  # escape # parenthesis # bracket # DefaultResolver # getKey # expression
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (BEANUTILS-533) If expression contains ")", DefaultResolver #getKey return wrong value

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051629#comment-17051629
 ] 

Melloware edited comment on BEANUTILS-533 at 3/4/20, 9:07 PM:
--

I just updated the DefaultResolverTestCase unit test with you new property 
values against the code in MASTER and its working fine.

{code:java}
// Mapped Properties Test Data
private final String[] validMapProperties = new String[] {"a(b)", "c(de)", 
"fg(h)", "ij(kl)", "mno(pqr.s)", "tuv(wx).yz[1], 
test(myvalue(ineedthisparenthis))"};
private final String[] validMapNames  = new String[] {"a","c", 
"fg","ij", "mno","tuv", "test"};
private final String[] validMapKeys   = new String[] {"b","de","h", 
"kl", "pqr.s",  "wx",  "myvalue(ineedthisparenthis)"};
{code}


was (Author: melloware):
I just updated the DefaultResolverTestCase unit test with you new property 
values against the code in MASTER and its working fine.

{code:java}
// Mapped Properties Test Data
private final String[] validMapProperties = new String[] {"a(b)", "c(de)", 
"fg(h)", "ij(kl)", "mno(pqr.s)", "tuv(wx).yz[1], 
test(myvalue(ineedthisparenthis))"};
private final String[] validMapNames  = new String[] {"a","c", 
"fg","ij", "mno","tuv", "test"};
private final String[] validMapKeys   = new String[] {"b","de",
"h", "kl", "pqr.s",  "wx",  "myvalue(ineedthisparenthis)"};
{code}

> If expression contains ")", DefaultResolver #getKey return wrong value
> --
>
> Key: BEANUTILS-533
> URL: https://issues.apache.org/jira/browse/BEANUTILS-533
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.9.3
>Reporter: Maxime Garenne
>Priority: Blocker
>
> h2. Context
> I use BeanUtils to return a map that contain properties.
> I had a failure in my code because this property causes a fail in the 
> BeanUtils "getMappedProperty" method :
> test(myvalue(ineedthisparenthis))
> h2. Explanation
> In DefaultResolver #getKey(String expression), if the expression contains a 
> ")", the returned value is incorrect because the algorithm stops at the first 
> ")" character (#indefOf is used).
> In my example, the method now returns : "myvalue(ineedthisparenthis". It 
> should be "myvalue(ineedthisparenthis) with proprerty name = "test".
> Instead of using :
> {code:java}
> final int end = expression.indexOf(MAPPED_END, i);{code}
> It would be better to just check if the last character of "expression" is a 
> ")" and then substring between "i+1" and last character index.
> Then my example would not fail. 
>  
> This occurs in version 1.7.
> I checked in upper versions, the method is different but still wrong because 
> the method indexOf is still used (taking again the first ")" found). 
>  # escape # parenthesis # bracket # DefaultResolver # getKey # expression
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-533) If expression contains ")", DefaultResolver #getKey return wrong value

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051629#comment-17051629
 ] 

Melloware commented on BEANUTILS-533:
-

I just updated the DefaultResolverTestCase unit test with you new property 
values against the code in MASTER and its working fine.

{code:java}
// Mapped Properties Test Data
private final String[] validMapProperties = new String[] {"a(b)", "c(de)", 
"fg(h)", "ij(kl)", "mno(pqr.s)", "tuv(wx).yz[1], 
test(myvalue(ineedthisparenthis))"};
private final String[] validMapNames  = new String[] {"a","c", 
"fg","ij", "mno","tuv", "test"};
private final String[] validMapKeys   = new String[] {"b","de",
"h", "kl", "pqr.s",  "wx",  "myvalue(ineedthisparenthis)"};
{code}

> If expression contains ")", DefaultResolver #getKey return wrong value
> --
>
> Key: BEANUTILS-533
> URL: https://issues.apache.org/jira/browse/BEANUTILS-533
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.9.3
>Reporter: Maxime Garenne
>Priority: Blocker
>
> h2. Context
> I use BeanUtils to return a map that contain properties.
> I had a failure in my code because this property causes a fail in the 
> BeanUtils "getMappedProperty" method :
> test(myvalue(ineedthisparenthis))
> h2. Explanation
> In DefaultResolver #getKey(String expression), if the expression contains a 
> ")", the returned value is incorrect because the algorithm stops at the first 
> ")" character (#indefOf is used).
> In my example, the method now returns : "myvalue(ineedthisparenthis". It 
> should be "myvalue(ineedthisparenthis) with proprerty name = "test".
> Instead of using :
> {code:java}
> final int end = expression.indexOf(MAPPED_END, i);{code}
> It would be better to just check if the last character of "expression" is a 
> ")" and then substring between "i+1" and last character index.
> Then my example would not fail. 
>  
> This occurs in version 1.7.
> I checked in upper versions, the method is different but still wrong because 
> the method indexOf is still used (taking again the first ")" found). 
>  # escape # parenthesis # bracket # DefaultResolver # getKey # expression
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-533) If expression contains ")", DefaultResolver #getKey return wrong value

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051623#comment-17051623
 ] 

Melloware commented on BEANUTILS-533:
-

Care to submit a PR on the GitHub page fixing the issue with unit tests?

> If expression contains ")", DefaultResolver #getKey return wrong value
> --
>
> Key: BEANUTILS-533
> URL: https://issues.apache.org/jira/browse/BEANUTILS-533
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.7.0, 1.8.0, 1.9.0, 1.9.3
>Reporter: Maxime Garenne
>Priority: Blocker
>
> h2. Context
> I use BeanUtils to return a map that contain properties.
> I had a failure in my code because this property causes a fail in the 
> BeanUtils "getMappedProperty" method :
> test(myvalue(ineedthisparenthis))
> h2. Explanation
> In DefaultResolver #getKey(String expression), if the expression contains a 
> ")", the returned value is incorrect because the algorithm stops at the first 
> ")" character (#indefOf is used).
> In my example, the method now returns : "myvalue(ineedthisparenthis". It 
> should be "myvalue(ineedthisparenthis) with proprerty name = "test".
> Instead of using :
> {code:java}
> final int end = expression.indexOf(MAPPED_END, i);{code}
> It would be better to just check if the last character of "expression" is a 
> ")" and then substring between "i+1" and last character index.
> Then my example would not fail. 
>  
> This occurs in version 1.7.
> I checked in upper versions, the method is different but still wrong because 
> the method indexOf is still used (taking again the first ")" found). 
>  # escape # parenthesis # bracket # DefaultResolver # getKey # expression
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-532) Require commons-beanutils library which supports commons-collections-4.1 version

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040937#comment-17040937
 ] 

Melloware commented on BEANUTILS-532:
-

BeanUtils2 is not in Maven Central yet as it has not been released but I am 
hoping it gets released soon.  It has been 3+ years in the making.

> Require commons-beanutils library which supports commons-collections-4.1 
> version 
> -
>
> Key: BEANUTILS-532
> URL: https://issues.apache.org/jira/browse/BEANUTILS-532
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean-Collections
>Reporter: AvanthikaNC
>Priority: Blocker
> Attachments: image-2020-01-31-14-52-43-114.png
>
>
> Hi Team,
>  
>  We are working on ATM SWITCH project and the project currently uses 
> commons-beanutils library 1.9.4 and we have upgraded to 
> commons-collections-4.1 as part of our project requirement as it contained 
> vulnerabilities.
> We are facing some errors due to the above mentioned upgrade as 
> commons-beanutils library 1.9.4 will support commons-collections 3.2.2 
> version.
> Now as per our requirement we cannot downgrade common-collections library but 
> we need commons-beanutils library which supports commons-collections4-4.1 
> version.
> Please provide your response asap.
> Thanks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (BEANUTILS-532) Require commons-beanutils library which supports commons-collections-4.1 version

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039179#comment-17039179
 ] 

Melloware edited comment on BEANUTILS-532 at 2/18/20 3:46 PM:
--

[~ggregory] [~avanthikanc] For BeanUtils2 the Commons Collection depedency is 
removed entirely!

See PR: https://github.com/apache/commons-beanutils/pull/9/files
See PR: https://github.com/apache/commons-beanutils/pull/8/files


was (Author: melloware):
[~ggregory][~avanthikanc] For BeanUtils2 the Commons Collection depedency is 
removed entirely!

See PR: https://github.com/apache/commons-beanutils/pull/9/files
See PR: https://github.com/apache/commons-beanutils/pull/8/files

> Require commons-beanutils library which supports commons-collections-4.1 
> version 
> -
>
> Key: BEANUTILS-532
> URL: https://issues.apache.org/jira/browse/BEANUTILS-532
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean-Collections
>Reporter: AvanthikaNC
>Priority: Blocker
> Attachments: image-2020-01-31-14-52-43-114.png
>
>
> Hi Team,
>  
>  We are working on ATM SWITCH project and the project currently uses 
> commons-beanutils library 1.9.4 and we have upgraded to 
> commons-collections-4.1 as part of our project requirement as it contained 
> vulnerabilities.
> We are facing some errors due to the above mentioned upgrade as 
> commons-beanutils library 1.9.4 will support commons-collections 3.2.2 
> version.
> Now as per our requirement we cannot downgrade common-collections library but 
> we need commons-beanutils library which supports commons-collections4-4.1 
> version.
> Please provide your response asap.
> Thanks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-532) Require commons-beanutils library which supports commons-collections-4.1 version

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17039179#comment-17039179
 ] 

Melloware commented on BEANUTILS-532:
-

[~ggregory][~avanthikanc] For BeanUtils2 the Commons Collection depedency is 
removed entirely!

See PR: https://github.com/apache/commons-beanutils/pull/9/files
See PR: https://github.com/apache/commons-beanutils/pull/8/files

> Require commons-beanutils library which supports commons-collections-4.1 
> version 
> -
>
> Key: BEANUTILS-532
> URL: https://issues.apache.org/jira/browse/BEANUTILS-532
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean-Collections
>Reporter: AvanthikaNC
>Priority: Blocker
> Attachments: image-2020-01-31-14-52-43-114.png
>
>
> Hi Team,
>  
>  We are working on ATM SWITCH project and the project currently uses 
> commons-beanutils library 1.9.4 and we have upgraded to 
> commons-collections-4.1 as part of our project requirement as it contained 
> vulnerabilities.
> We are facing some errors due to the above mentioned upgrade as 
> commons-beanutils library 1.9.4 will support commons-collections 3.2.2 
> version.
> Now as per our requirement we cannot downgrade common-collections library but 
> we need commons-beanutils library which supports commons-collections4-4.1 
> version.
> Please provide your response asap.
> Thanks



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CONFIGURATION-776) Update Commons BeanUtils from 1.9. to 2.X

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/CONFIGURATION-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17010058#comment-17010058
 ] 

Melloware commented on CONFIGURATION-776:
-

This is a reminder ticket.  When Beanutils2 is released (hopefully soon) then 
Commons Config should update to the new dependency.  Its just a warning that 
the package naming changes from org.apache.commons.beanutils. to 
org.apache.commons.beanutils2.

> Update Commons BeanUtils from 1.9. to 2.X
> -
>
> Key: CONFIGURATION-776
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-776
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.6
>Reporter: Melloware
>Priority: Major
>
> Update Apache Commons BeanUtils from 1.9. to 2.X
> BeanUtils 2.X removes its dependency on Commons Collections but does change 
> package name to the beanutils2 package.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (CONFIGURATION-776) Update Commons BeanUtils from 1.9. to 2.X

[Melloware (Jira)]

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

Melloware updated CONFIGURATION-776:

Summary: Update Commons BeanUtils from 1.9. to 2.X  (was: Update Apache 
BeanUtils from 1.9. to 2.X)

> Update Commons BeanUtils from 1.9. to 2.X
> -
>
> Key: CONFIGURATION-776
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-776
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.6
>Reporter: Melloware
>Priority: Major
>
> Update Apache BeanUtils from 1.9. to 2.X
> BeanUtils 2.X removes its dependency on Commons Collections but does change 
> package name to the beanutils2 package.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (CONFIGURATION-776) Update Commons BeanUtils from 1.9. to 2.X

[Melloware (Jira)]

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

Melloware updated CONFIGURATION-776:

Description: 
Update Apache Commons BeanUtils from 1.9. to 2.X

BeanUtils 2.X removes its dependency on Commons Collections but does change 
package name to the beanutils2 package.

  was:
Update Apache BeanUtils from 1.9. to 2.X

BeanUtils 2.X removes its dependency on Commons Collections but does change 
package name to the beanutils2 package.


> Update Commons BeanUtils from 1.9. to 2.X
> -
>
> Key: CONFIGURATION-776
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-776
> Project: Commons Configuration
>  Issue Type: Task
>Affects Versions: 2.6
>Reporter: Melloware
>Priority: Major
>
> Update Apache Commons BeanUtils from 1.9. to 2.X
> BeanUtils 2.X removes its dependency on Commons Collections but does change 
> package name to the beanutils2 package.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CONFIGURATION-776) Update Apache BeanUtils from 1.9. to 2.X

[Melloware (Jira)]

Melloware created CONFIGURATION-776:
---

 Summary: Update Apache BeanUtils from 1.9. to 2.X
 Key: CONFIGURATION-776
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-776
 Project: Commons Configuration
  Issue Type: Task
Affects Versions: 2.6
Reporter: Melloware


Update Apache BeanUtils from 1.9. to 2.X

BeanUtils 2.X removes its dependency on Commons Collections but does change 
package name to the beanutils2 package.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002426#comment-17002426
 ] 

Melloware commented on BEANUTILS-509:
-

I submitted a PR with the recommended fix

> WeakHashmap enters into infinite loop in WrapDynaClass.java
> ---
>
> Key: BEANUTILS-509
> URL: https://issues.apache.org/jira/browse/BEANUTILS-509
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: DynaBean
>Affects Versions: 1.8.2
>Reporter: sunil
>Priority: Major
> Attachments: 2018-10-13T11-43-27_961-jvmRun1.dump, 
> 2018-10-13T11-43-27_961.dumpstream, BEANUTILS-509.diff, WrapDynaCache.patch, 
> WrapDynaCache_after_svn_commit.patch, console.log.backup
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> We noticed that our application was using too much of CPU , all the 6 cores 
> were used. 
> On capturing the thread dump we saw that large number of threads were in the 
> running state and in :
> at java.util.WeakHashMap.get(WeakHashMap.java:403)
>  at 
> org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425)
>  
> So we are suspecting that the thread has entered into indefinite while loop 
> and hogging all the CPU resources.
> I have attached the thread dump for reference.  
>  
> what is the solution for this issue?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986918#comment-16986918
 ] 

Melloware commented on BEANUTILS-524:
-

Besides adding it in Javadoc that seems like a question for [~ggregory] maybe 
its something that can be put on the site documentation?

> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986912#comment-16986912
 ] 

Melloware edited comment on BEANUTILS-524 at 12/3/19 1:45 PM:
--

No what I am thinking is you will need an Interfaces in Commons BeanUtils for 
CopyUtils.  Then in BU the current Copy method will implements a CopyUtilsBean. 
and in BULL you will create one just like above in the BULL code that 
implements the same CopyUtils interface.

Then in the signature of BeanUtilsBean you will pass it a CopyUtils instance 
either the one from BULL or the one from BU (default).  That way you are 
passing in either your custom one or the default current behavior from 
BeanUtils.

However that will mean you will need an optional dependency in your BULL 
library like the following to have the BU interface.
{code:xml}

  org.apache.commons
  commons-beanutils2
  2.0.0
  true

{code}


was (Author: melloware):
No what I am thinking is you will need an Interfaces in Commons BeanUtils for 
CopyUtils.  Then in BU the current Copy method will implements a CopyUtilsBean. 
and in BULL you will create one just like above in the BULL code that 
implements the same CopyUtils interface.

Then in the signature of BeanUtilsBean you will pass it a CopyUtils instance 
either the one from BULL or the one from BU (default).  That way you are 
passing in either your custom one or the default current behavior from 
BeanUtils.

However that will mean you will need an optional dependency in your BULL 
library like...
{code:xml}

  org.apache.commons
  commons-beanutils2
  2.0.0
  true

{code}

> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986912#comment-16986912
 ] 

Melloware commented on BEANUTILS-524:
-

No what I am thinking is you will need an Interfaces in Commons BeanUtils for 
CopyUtils.  Then in BU the current Copy method will implements a CopyUtilsBean. 
and in BULL you will create one just like above in the BULL code that 
implements the same CopyUtils interface.

Then in the signature of BeanUtilsBean you will pass it a CopyUtils instance 
either the one from BULL or the one from BU (default).  That way you are 
passing in either your custom one or the default current behavior from 
BeanUtils.

However that will mean you will need an optional dependency in your BULL 
library like...
{code:xml}

  org.apache.commons
  commons-beanutils2
  2.0.0
  true

{code}

> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986872#comment-16986872
 ] 

Melloware edited comment on BEANUTILS-524 at 12/3/19 12:51 PM:
---

>From looking at BeanUtilsBean it has overloaded constructors that take 
>ConvertUtils and PropertyUtils.

{code:java}
/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
}
{code}

If you don't specify these you get the default.  You could makea new 
CopyUtilsBean and allow it to be inserted in the BeanutilsBean.  By default the 
CopyUtils will be the current BU verson.  However in BULL you could create your 
own CopyUtilsBean that does it the BULL way and then just instantiate 
BeanUtilsBean with your version like...

{code:java}
/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean
 final CopyUtilsBean copyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
this.copyUtilsBean= copyUtilsBean; 
}
{code}

Just a thought...  That way BULL code stays in BULL but gives you a hook for 
injecting your own copy in there.



was (Author: melloware):
>From looking at BeanUtilsBean it has overloaded constructors that take 
>ConvertUtils and PropertyUtils.

```java
/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
}
```

If you don't specify these you get the default.  You could makea new 
CopyUtilsBean and allow it to be inserted in the BeanutilsBean.  By default the 
CopyUtils will be the current BU verson.  However in BULL you could create your 
own CopyUtilsBean that does it the BULL way and then just instantiate 
BeanUtilsBean with your version like...

/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean
 final CopyUtilsBean copyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
this.copyUtilsBean= copyUtilsBean; 
}
```

Just a thought...  That way BULL code stays in BULL but gives you a hook for 
injecting your own copy in there.


> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 

[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986872#comment-16986872
 ] 

Melloware commented on BEANUTILS-524:
-

>From looking at BeanUtilsBean it has overloaded constructors that take 
>ConvertUtils and PropertyUtils.

```java
/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
}
```

If you don't specify these you get the default.  You could makea new 
CopyUtilsBean and allow it to be inserted in the BeanutilsBean.  By default the 
CopyUtils will be the current BU verson.  However in BULL you could create your 
own CopyUtilsBean that does it the BULL way and then just instantiate 
BeanUtilsBean with your version like...

/**
 * Constructs an instance using given property and conversion 
instances.
 *
 * @param convertUtilsBean use this {@code ConvertUtilsBean}
 * to perform conversions from one object to another
 * @param propertyUtilsBean use this {@code PropertyUtilsBean}
 * to access properties
 */
public BeanUtilsBean(
final ConvertUtilsBean convertUtilsBean,
final PropertyUtilsBean propertyUtilsBean
 final CopyUtilsBean copyUtilsBean) {

this.convertUtilsBean = convertUtilsBean;
this.propertyUtilsBean = propertyUtilsBean;
this.copyUtilsBean= copyUtilsBean; 
}
```

Just a thought...  That way BULL code stays in BULL but gives you a hook for 
injecting your own copy in there.


> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986285#comment-16986285
 ] 

Melloware commented on BEANUTILS-524:
-

[~fborriello] is there some way in BULL you could create a BU Transformer and 
somehow make the BU CopyProperties take an overloaded Transformer?  that way 
you can keep BU code clean and BULL code have what it needs and allow users to 
plug their BULL version of copyProperties in?

> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-531) Technical Support Expiration Date

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986020#comment-16986020
 ] 

Melloware commented on BEANUTILS-531:
-

This is an open source project. I don't think Apache ever offers "technical 
support dates".   Since the code is open you are always welcome to fork it and 
store it with  your code repository and build it yourself if you are concerned 
it will go away?

> Technical Support Expiration Date
> -
>
> Key: BEANUTILS-531
> URL: https://issues.apache.org/jira/browse/BEANUTILS-531
> Project: Commons BeanUtils
>  Issue Type: Bug
>Reporter: Sergi Comeche
>Priority: Major
>  Labels: beanutil
>
> Hello,
> I work for a long-term project which requires strong and stable technical 
> support for every software used.
> I want to know how long you are providing technical support for 
> Commons-beanutils 1.8.3.
> Please I appreciate so much that you can give me expiration dates for this 
> software product or expectations of its EOL.
> Thank you!
> Sergi



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16986019#comment-16986019
 ] 

Melloware commented on BEANUTILS-524:
-

I can't imagine this will be accepted because you are introducing a 3rd party 
library that is not from Apache Commons.

> Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java 
> Bean
> -
>
> Key: BEANUTILS-524
> URL: https://issues.apache.org/jira/browse/BEANUTILS-524
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: Locale BeanUtils / Converters
>Reporter: Fabio Borriello
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> h4. Overview
> the copyProperties method in the BeanUtils class, is able to copy only public 
> properties or the ones with a public setter method.
> it would be really useful if this functionality can be extended in order to 
> copy any kind of Java Bean: Mutable, Immutable, Mixed.
> h4. Solution 
> Evaluate  the possibility to use, behind the scenes, an open source library 
> that is able to copy Mutable, Immutable and Mixed Java Bean. The library In 
> object is [BULL|https://github.com/HotelsDotCom/bull]. 
> This would also make able to copy nested objects.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CODEC-263) Base64.decodeBase64 throw exception

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/CODEC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16968612#comment-16968612
 ] 

Melloware commented on CODEC-263:
-

Isnt that correct?  That is not a Base64 value you are decoding?

> Base64.decodeBase64 throw exception
> ---
>
> Key: CODEC-263
> URL: https://issues.apache.org/jira/browse/CODEC-263
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.13
> Environment: JDK 7/JDK 8 
> commons-codec 1.13
>Reporter: xie tao
>Priority: Critical
>
> Codec upgrade to 1.13, code  throw exception as follows：
> {code:java}
>   @Test
>   public  void test(){
> Base64.decodeBase64("publishMessage");
>   }
> {code}
> exception like：
> {code:java}
> java.lang.IllegalArgumentException: Last encoded character (before the 
> paddings if any) is a valid base 64 alphabet but not a possible value
>   at 
> org.apache.commons.codec.binary.Base64.validateCharacter(Base64.java:798)
>   at org.apache.commons.codec.binary.Base64.decode(Base64.java:472)
>   at 
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:412)
>   at 
> org.apache.commons.codec.binary.BaseNCodec.decode(BaseNCodec.java:395)
>   at org.apache.commons.codec.binary.Base64.decodeBase64(Base64.java:694)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-346) Enum type is not supported

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959953#comment-16959953
 ] 

Melloware commented on BEANUTILS-346:
-

This will be fixed in 2.0.0 I have submitted a PR

> Enum type is not supported
> --
>
> Key: BEANUTILS-346
> URL: https://issues.apache.org/jira/browse/BEANUTILS-346
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.8.0-BETA
> Environment: JDK6
>Reporter: Miroslav Nachev
>Priority: Major
> Fix For: 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When I try to set some property of type Enum the exception is thrown. This 
> can be fixed with the following code:
> private static class EnumConvertUtils extends ConvertUtilsBean {
> public EnumConvertUtils() {
> }
> @Override
> public Object convert(String value, Class clazz) {
> if(clazz.isEnum())
> return Enum.valueOf(clazz, value);
> return super.convert(value, clazz);
> }
> }



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-521) ConvertUtilsBean register no longer accepts a lambda

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958998#comment-16958998
 ] 

Melloware commented on BEANUTILS-521:
-

Ahh I found the fix.  
https://stackoverflow.com/questions/38118150/java-8-lambda-generic-interface-method

I will submit a PR.

> ConvertUtilsBean register no longer accepts a lambda
> 
>
> Key: BEANUTILS-521
> URL: https://issues.apache.org/jira/browse/BEANUTILS-521
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: ConvertUtils  Converters
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3
> Environment: Jenkins 2.173+
> commons-beanutils 1.9.3
>Reporter: Joseph Petersen
>Priority: Blocker
>
> [https://github.com/jenkinsci/configuration-as-code-plugin/pull/850/files#diff-7b37b740fa524c001a6701ca3800668aR130]
> [https://github.com/jenkinsci/jenkins/pull/3948#issuecomment-494196433]
> {noformat}
> src/main/java/io/jenkins/plugins/casc/ConfigurationContext.java:[129,40] 
> incompatible types: invalid functional descriptor for lambda expression
> method (java.lang.Class,java.lang.Object)T in interface 
> org.apache.commons.beanutils.Converter is generic
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-521) ConvertUtilsBean register no longer accepts a lambda

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958901#comment-16958901
 ] 

Melloware commented on BEANUTILS-521:
-

You are right when the Converter.convert method switched to generics  this 
is no longer allowed in Lambas.

{code:java}
/**
 * Convert the specified input object into an output object of the
 * specified type.
 *
 * @param  the desired result type
 * @param type Data type to which this value should be converted
 * @param value The input value to be converted
 * @return The converted value
 *
 * @throws ConversionException if conversion cannot be performed
 *  successfully
 */
public  T convert(Class type, Object value);
{code}

> ConvertUtilsBean register no longer accepts a lambda
> 
>
> Key: BEANUTILS-521
> URL: https://issues.apache.org/jira/browse/BEANUTILS-521
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: ConvertUtils  Converters
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3
> Environment: Jenkins 2.173+
> commons-beanutils 1.9.3
>Reporter: Joseph Petersen
>Priority: Blocker
>
> [https://github.com/jenkinsci/configuration-as-code-plugin/pull/850/files#diff-7b37b740fa524c001a6701ca3800668aR130]
> [https://github.com/jenkinsci/jenkins/pull/3948#issuecomment-494196433]
> {noformat}
> src/main/java/io/jenkins/plugins/casc/ConfigurationContext.java:[129,40] 
> incompatible types: invalid functional descriptor for lambda expression
> method (java.lang.Class,java.lang.Object)T in interface 
> org.apache.commons.beanutils.Converter is generic
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-521) ConvertUtilsBean register no longer accepts a lambda

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958020#comment-16958020
 ] 

Melloware commented on BEANUTILS-521:
-

Did this ever accept a Lamba?   We are just switching BeanUtils to Java8 now so 
not sure how 1.9.X accepted a Lamba?

> ConvertUtilsBean register no longer accepts a lambda
> 
>
> Key: BEANUTILS-521
> URL: https://issues.apache.org/jira/browse/BEANUTILS-521
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: ConvertUtils  Converters
>Affects Versions: 1.9.0, 1.9.1, 1.9.2, 1.9.3
> Environment: Jenkins 2.173+
> commons-beanutils 1.9.3
>Reporter: Joseph Petersen
>Priority: Blocker
>
> [https://github.com/jenkinsci/configuration-as-code-plugin/pull/850/files#diff-7b37b740fa524c001a6701ca3800668aR130]
> [https://github.com/jenkinsci/jenkins/pull/3948#issuecomment-494196433]
> {noformat}
> src/main/java/io/jenkins/plugins/casc/ConfigurationContext.java:[129,40] 
> incompatible types: invalid functional descriptor for lambda expression
> method (java.lang.Class,java.lang.Object)T in interface 
> org.apache.commons.beanutils.Converter is generic
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-514) Remove deprecated code for 2.0.0

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957983#comment-16957983
 ] 

Melloware commented on BEANUTILS-514:
-

[~ggregory] You can close BEANUTILS-361 as you deleted all deprecated code.

> Remove deprecated code for 2.0.0
> 
>
> Key: BEANUTILS-514
> URL: https://issues.apache.org/jira/browse/BEANUTILS-514
> Project: Commons BeanUtils
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 2.0.0
>
>
> Remove all code marked with {{@deprecated}} and {{@Deprecated}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-361) BeanMap.defaultTransformers should be final

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957982#comment-16957982
 ] 

Melloware commented on BEANUTILS-361:
-

This ticket can be closed as BEANUTILS-514 removed all deprecated code for 2.0.

> BeanMap.defaultTransformers should be final
> ---
>
> Key: BEANUTILS-361
> URL: https://issues.apache.org/jira/browse/BEANUTILS-361
> Project: Commons BeanUtils
>  Issue Type: Bug
>Reporter: Sebb
>Priority: Major
> Fix For: 2.0.0
>
>
> BeanMap.defaultTransformers should be final, otherwise it can be replaced 
> with a modifiable HashMap.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Closed] (BEANUTILS-528) Converters for URI, UUID, and Path

[Melloware (Jira)]

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

Melloware closed BEANUTILS-528.
---

Verrified.  Thanks!

> Converters for URI, UUID, and Path
> --
>
> Key: BEANUTILS-528
> URL: https://issues.apache.org/jira/browse/BEANUTILS-528
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: ConvertUtils  Converters
>Affects Versions: 2.0.0
>Reporter: Melloware
>Priority: Major
> Fix For: 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> As requested on the mailing list new converters for:
> java.nio.file.Path
> java.util.UUID
> java.net.URI



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-528) Converters for URI, UUID, and Path

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956158#comment-16956158
 ] 

Melloware commented on BEANUTILS-528:
-

PR Submitted.

> Converters for URI, UUID, and Path
> --
>
> Key: BEANUTILS-528
> URL: https://issues.apache.org/jira/browse/BEANUTILS-528
> Project: Commons BeanUtils
>  Issue Type: New Feature
>  Components: ConvertUtils  Converters
>Affects Versions: 2.0.0
>Reporter: Melloware
>Priority: Major
> Fix For: 2.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As requested on the mailing list new converters for:
> java.nio.file.Path
> java.util.UUID
> java.net.URI



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (BEANUTILS-528) Converters for URI, UUID, and Path

[Melloware (Jira)]

Melloware created BEANUTILS-528:
---

 Summary: Converters for URI, UUID, and Path
 Key: BEANUTILS-528
 URL: https://issues.apache.org/jira/browse/BEANUTILS-528
 Project: Commons BeanUtils
  Issue Type: New Feature
  Components: ConvertUtils  Converters
Affects Versions: 2.0.0
Reporter: Melloware
 Fix For: 2.0.0


As requested on the mailing list new converters for:

java.nio.file.Path
java.util.UUID
java.net.URI



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-527) Convert from Collections4 to java.util.function #8

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956039#comment-16956039
 ] 

Melloware commented on BEANUTILS-527:
-

I just submitted a PR with my suggestion.   Its a really simple comparator so I 
just called it NaturalOrderingComparator and moved it as a private inner static 
class of BeanComparator.

> Convert from Collections4 to java.util.function #8
> --
>
> Key: BEANUTILS-527
> URL: https://issues.apache.org/jira/browse/BEANUTILS-527
> Project: Commons BeanUtils
>  Issue Type: New Feature
>Reporter: Gary D. Gregory
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Convert from Collections4 to java.util.function #8
> Implement {{java.util.function.Predicate}} instead of 
> {{org.apache.commons.collections4.Predicate}}:
>  * {{org.apache.commons.beanutils2.BeanPropertyValueEqualsPredicateTestCase}}
>  * {{org.apache.commons.beanutils2.BeanPredicate}}
> Implement {{java.util.function.Consumer}} instead of 
> {{org.apache.commons.collections4.Closure}}:
>  * {{org.apache.commons.beanutils2.BeanPropertyValueChangeClosure}} renamed 
> to {{BeanPropertyValueChangeConsumer}}
> {{org.apache.commons.beanutils2.BeanMap.Entry}} extends 
> {{java.util.AbstractMap.SimpleEntry}} instead of 
> {{org.apache.commons.collections4.keyvalue.AbstractMapEntry}}.
> {{org.apache.commons.beanutils2.BeanToPropertyValueTransformer}} implements 
> {{java.util.function.Function}} instead of 
> {{org.apache.commons.collections4.Transformer}}.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (BEANUTILS-523) Release 1.9.4 has broken every single OSGi installation out there which uses it through Require-Bundle

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16936692#comment-16936692
 ] 

Melloware commented on BEANUTILS-523:
-

[~chtompki] Any thought on this one?

> Release 1.9.4 has broken every single OSGi installation out there which uses 
> it through Require-Bundle
> --
>
> Key: BEANUTILS-523
> URL: https://issues.apache.org/jira/browse/BEANUTILS-523
> Project: Commons BeanUtils
>  Issue Type: Bug
>Affects Versions: 1.9.4
>Reporter: Václav Haisman
>Priority: Blocker
>  Labels: OSGi
>
> The released Beanutils 1.9.4 OSGi manifest has changed Bundle-SymbolicName 
> from previous org.apache.commons.beanutils to 
> org.apache.commons.commons-beanutils. 
> Please release a patch version that reverses this change ASAP. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (CSV-251) CSVPrinter don't handle byte[] correctly for postgres

[Melloware (Jira)]

[ 
https://issues.apache.org/jira/browse/CSV-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924138#comment-16924138
 ] 

Melloware commented on CSV-251:
---

+1 for just adding Commons Codec dependency.

> CSVPrinter don't handle byte[] correctly for postgres
> -
>
> Key: CSV-251
> URL: https://issues.apache.org/jira/browse/CSV-251
> Project: Commons CSV
>  Issue Type: Improvement
>  Components: Printer
> Environment: java version
> ```
> openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~18.04.1-b10)
> OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
> ```
> apache.commons.csv: 1.6
> clojure: 1.9.0
> postgres: 10.7
>  
>Reporter: saitouena
>Priority: Minor
>
> I passed byte[] values for CSVPrinter.printRecords with 
> CSVFormat.POSTGRESQL_CSV, but it use Object.toString(printed [B@ in 
> clojure). As a result, data were discarded.
> I don't know about other RDBs, but at least postgres supports 
> [https://www.postgresql.org/docs/9.3/datatype-binary.html] hexstring format.
> Workaround: Wrap byte[] with the class that has proper toString method like 
> this.
> ```
> public string toString()
> { return "\\x" + encodeHexString(this.bytedata); }
> ```
> I used apache.commons.csv from Clojure. I'll make a minimal repro case in 
> Java if needed. I have clojure code for now.
> clojure code:
> ```
> (deftype ByteArrayForCopyIn [^"[B" bs]
>  Object
>  (toString [self] (str "\\x" (Hex/encodeHexString bs
> (let [sb (StringBuilder.)
>  values [(.getBytes "hoge")]]
>  (with-open [^CSVPrinter p (CSVPrinter. sb CSVFormat/POSTGRESQL_CSV)]
>  (.printRecords p values)))
> ```
>  



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910022#comment-16910022
 ] 

Melloware commented on BEANUTILS-520:
-

Those are good questions!

1. Looks like Commons Collections would not be insignificant changes to remove. 
At least from what I can see?

2. I don't see any @deprecated in the code to remove.

3. As for changing interfaces that I don't think I am qualified to answer.

to me this library has been around for 15+ years and is rock solid.  a 2.0 
release would get it up to Java 8 and in line with the rest of Apache releases.

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16910007#comment-16910007
 ] 

Melloware commented on BEANUTILS-520:
-

[~chtompki] Thank you so much!

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Assignee: Rob Tompkins
>Priority: Major
>  Labels: security
> Fix For: 1.9.4, 2.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (BEANUTILS-501) Very simple getter not found

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16907995#comment-16907995
 ] 

Melloware commented on BEANUTILS-501:
-

I agree with you, unfortunately i don't think there is any way to give a better 
message as to WHY it can't reach getShortName.  So yes you can probably close 
this issue. Thanks!

> Very simple getter not found
> 
>
> Key: BEANUTILS-501
> URL: https://issues.apache.org/jira/browse/BEANUTILS-501
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Daniel Süpke
>Priority: Major
>
> Hi,
> I'm hopefully not missing something very simple, but shouldn't this be 
> working?
> {code:java}
>   @Test
>   public void getStringWithVarsTest() {
>   Serializable entity = new Serializable() {
>   private String shortName = "foo";
>   public String getShortName() {
>   return shortName;
>   }
>   };
>   try {
>   PropertyUtils.getProperty(entity, "shortName");
>   }
>   catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
> {code}
> java.lang.NoSuchMethodException: Property 'shortName' has no getter method in 
> class 'class com.wesustain.hera.util.LocalizerTest$1'
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1274)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:808)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:884)
>   at 
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:464)
>   at 
> com.wesustain.hera.util.LocalizerTest.getStringWithVarsTest(LocalizerTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (BEANUTILS-501) Very simple getter not found

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905465#comment-16905465
 ] 

Melloware commented on BEANUTILS-501:
-

The error is exactly the problem.  The "getShortName" is not visible to the 
PropertyUtils.  And that is because you have declared an anonymous inner class 
which is not public. So thus the error "Property 'shortName' has no getter 
method in class 'class com.wesustain.hera.util.LocalizerTest$1'" is saying 
"com.wesustain.hera.util.LocalizerTest$1" is an anonymous class I am trying to 
access and I can't see a getter named ShortName.  Which is exactly what would 
happen if you used raw java.lang.reflect classes.


> Very simple getter not found
> 
>
> Key: BEANUTILS-501
> URL: https://issues.apache.org/jira/browse/BEANUTILS-501
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Daniel Süpke
>Priority: Major
>
> Hi,
> I'm hopefully not missing something very simple, but shouldn't this be 
> working?
> {code:java}
>   @Test
>   public void getStringWithVarsTest() {
>   Serializable entity = new Serializable() {
>   private String shortName = "foo";
>   public String getShortName() {
>   return shortName;
>   }
>   };
>   try {
>   PropertyUtils.getProperty(entity, "shortName");
>   }
>   catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
> {code}
> java.lang.NoSuchMethodException: Property 'shortName' has no getter method in 
> class 'class com.wesustain.hera.util.LocalizerTest$1'
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1274)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:808)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:884)
>   at 
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:464)
>   at 
> com.wesustain.hera.util.LocalizerTest.getStringWithVarsTest(LocalizerTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (BEANUTILS-501) Very simple getter not found

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905100#comment-16905100
 ] 

Melloware commented on BEANUTILS-501:
-

I think this message is fine and is telling you exactly what is wrong. I 
recommend CLOSING this ticket.

> Very simple getter not found
> 
>
> Key: BEANUTILS-501
> URL: https://issues.apache.org/jira/browse/BEANUTILS-501
> Project: Commons BeanUtils
>  Issue Type: Bug
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Daniel Süpke
>Priority: Major
>
> Hi,
> I'm hopefully not missing something very simple, but shouldn't this be 
> working?
> {code:java}
>   @Test
>   public void getStringWithVarsTest() {
>   Serializable entity = new Serializable() {
>   private String shortName = "foo";
>   public String getShortName() {
>   return shortName;
>   }
>   };
>   try {
>   PropertyUtils.getProperty(entity, "shortName");
>   }
>   catch (Exception e) {
>   e.printStackTrace();
>   }
>   }
> {code}
> java.lang.NoSuchMethodException: Property 'shortName' has no getter method in 
> class 'class com.wesustain.hera.util.LocalizerTest$1'
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getSimpleProperty(PropertyUtilsBean.java:1274)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getNestedProperty(PropertyUtilsBean.java:808)
>   at 
> org.apache.commons.beanutils.PropertyUtilsBean.getProperty(PropertyUtilsBean.java:884)
>   at 
> org.apache.commons.beanutils.PropertyUtils.getProperty(PropertyUtils.java:464)
>   at 
> com.wesustain.hera.util.LocalizerTest.getStringWithVarsTest(LocalizerTest.java:61)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
>   at 
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
>   at 
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (COMPRESS-470) ParallelScatterZipCreator leaks temporary files (and maybe more)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16904048#comment-16904048
 ] 

Melloware commented on COMPRESS-470:


Nice work and much appreciation for your continued work on this library!

> ParallelScatterZipCreator leaks temporary files (and maybe more)
> 
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
>  Labels: zip
> Fix For: 1.19
>
>
> As indicated by 
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679878#comment-16679878
>  COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some 
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like 
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16895298#comment-16895298
 ] 

Melloware commented on CODEC-134:
-

[~tmousaw] It was released last week and is in maven central.  
https://search.maven.org/artifact/commons-codec/commons-codec/1.13/jar

> Base32 would decode some invalid Base32 encoded string into arbitrary value
> ---
>
> Key: CODEC-134
> URL: https://issues.apache.org/jira/browse/CODEC-134
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: All
>Reporter: Hanson Char
>Assignee: Gary Gregory
>Priority: Major
>  Labels: security
> Fix For: 1.13
>
> Attachments: diff-120305-20.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Example, there is no byte array value that can be encoded into the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation 
> would not reject it but decode it into an arbitrary value which if re-encoded 
> again using the same implementation would result in the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===".
> Instead of blindly decoding the invalid string, the Base32 codec should 
> reject it (eg by throwing IlleglArgumentException) to avoid security 
> exploitation (such as tunneling additional information via seemingly valid 
> base 32 strings).



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (CODEC-236) Add MurmurHash Implementation

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881987#comment-16881987
 ] 

Melloware commented on CODEC-236:
-

PR Submitted on GitHub.

> Add MurmurHash Implementation
> -
>
> Key: CODEC-236
> URL: https://issues.apache.org/jira/browse/CODEC-236
> Project: Commons Codec
>  Issue Type: New Feature
>Affects Versions: 1.10
>Reporter: David Mollitor
>Priority: Minor
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://en.wikipedia.org/wiki/MurmurHash
> Already exists an Apache implementation:
> org.apache.hive.common.util.HashCodeUtil.murmurHash(byte[], int, int)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-254) ColognePhonetic does not treat the letter H correctly

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866636#comment-16866636
 ] 

Melloware commented on CODEC-254:
-

[~sebb] This looks awfully similar to this issue?  
https://issues.apache.org/jira/browse/CODEC-255  Is it possible it is fixed 
also?

> ColognePhonetic does not treat the letter H correctly
> -
>
> Key: CODEC-254
> URL: https://issues.apache.org/jira/browse/CODEC-254
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.12
>Reporter: Holger Grote
>Priority: Major
>
> With the fix in CODEC-250 the letter H is not treaten correct any more.
> A String 'shch' is coded as 8 and not as 84. (This string is sometimes in 
> foreign surnames)
> The reasen is the letter h is ignored completely and not stored in the 
> lastChar anymore.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-95) Base64: optionally allow strict parsing of base64 strings

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854540#comment-16854540
 ] 

Melloware commented on CODEC-95:


I think this is now fixed by https://issues.apache.org/jira/browse/CODEC-134 
which no longer allows invalid Base64?

> Base64: optionally allow strict parsing of base64 strings
> -
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Adam Rabung
>Priority: Minor
> Fix For: 1.x
>
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode 
> table.  I realize this is perfectly to spec, but I wonder if other users 
> might appreciate a "strict" mode that throws an exception when one of these 
> illegal characters are encountered.  For example, I would love an exception 
> to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-253) Upgrade to Java 8

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854002#comment-16854002
 ] 

Melloware commented on CODEC-253:
-

Isn't this issue technically closed by 
https://issues.apache.org/jira/browse/CODEC-257  ???

> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
>  Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.13
>
>
> Upgrade to java 8 as the target of of the build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CODEC-256) ColognePhonetic.encode() calculates wrong code

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852929#comment-16852929
 ] 

Melloware edited comment on CODEC-256 at 5/31/19 1:08 PM:
--

[~aschnur] I am creating a GitHub PR for your change.  You change works however 
one of the previous unit tests fails and I want to confirm it is failing.   
Right now it has..

{code}
hoffmann=0366
mönchengladbach=664645214
deutsch=28
Zacharias=8478
matsch=68
Eberhard=01772
Eberhardt=01772
Celsius=8558
{code}


And with your fix it now reports it should be...

{code}
hoffmann=036
mönchengladbach=64645214
deutsch=284
Zacharias=878
matsch=684
Eberhard=0172
Eberhardt=0172
Celsius=858
{code}

Can you confirm this is correct?


was (Author: melloware):
[~aschnur] I am creating a GitHub PR for your change.  You change works however 
one of the previous unit tests fails and I want to confirm it is failing.   
Right now it has..

hoffmann=0366
mönchengladbach=664645214
deutsch=28
Zacharias=8478
matsch=68
Eberhard=01772
Eberhardt=01772
Celsius=8558

And with your fix it now reports it should be...

hoffmann=036
mönchengladbach=64645214
deutsch=284
Zacharias=878
matsch=684
Eberhard=0172
Eberhardt=0172
Celsius=858


Can you confirm this is correct?

> ColognePhonetic.encode() calculates wrong code
> --
>
> Key: CODEC-256
> URL: https://issues.apache.org/jira/browse/CODEC-256
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.12
> Environment: Java 8u181 64, Windows 7 Professional 64
>Reporter: Andreas Schnur
>Priority: Major
> Attachments: ColognePhonetic.java
>
>
> Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore 
> is left out), Code of N is 6 and should be left out because 6 is previous, 
> but Code assumes wrongly 0 as previous (which was left out). So the result is 
> 07266, but has to be 0726 (see Description of algorithm in class).
> Solution: In method colognePhonetic() move the last two LOC into if-block 
> above, see attached version of class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CODEC-248) language.DaitchMokotoffSoundex gives overly broad results for tokens containing RS

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852963#comment-16852963
 ] 

Melloware edited comment on CODEC-248 at 5/31/19 1:04 PM:
--

[~bkazez] I am not sure this is correct.  If I remove "rs" from the table we 
get unit tests that fail.  Namely.

{code:java}
Assert.assertEquals("734000|739400", soundex("Peters"));
Assert.assertEquals("734600|739460", soundex("Peterson"));
{code}

Which according to this documentation are correct:

https://en.wikipedia.org/wiki/Daitch%E2%80%93Mokotoff_Soundex

Also this test fails..

{code:java}
// GERSCHFELD
// G-E-RS-CH-F-E-L-D
// 5--4/94-5/4-7-8-3 -> wrong
// 5--4/94-5/--7-8-3 -> correct
Assert.assertEquals("547830|545783|594783|594578", 
soundex("GERSCHFELD"));
{code}

GERSCHFELD would become just 594783




was (Author: melloware):
[~bkazez] I am not sure this is correct.  If I remove "rs" from the table we 
get unit tests that fail.  Namely.

Assert.assertEquals("734000|739400", soundex("Peters"));
Assert.assertEquals("734600|739460", soundex("Peterson"));

Which according to this documentation are correct:

https://en.wikipedia.org/wiki/Daitch%E2%80%93Mokotoff_Soundex

Also this test fails..

// GERSCHFELD
// G-E-RS-CH-F-E-L-D
// 5--4/94-5/4-7-8-3 -> wrong
// 5--4/94-5/--7-8-3 -> correct
Assert.assertEquals("547830|545783|594783|594578", 
soundex("GERSCHFELD"));

GERSCHFELD would become just 594783



> language.DaitchMokotoffSoundex gives overly broad results for tokens 
> containing RS
> --
>
> Key: CODEC-248
> URL: https://issues.apache.org/jira/browse/CODEC-248
> Project: Commons Codec
>  Issue Type: Bug
>Reporter: Ben Kazez
>Priority: Minor
>
> I am using Apache commons codec in Elasticsearch (via Lucene).
> # GIERSZLIK codes to 548500 or 594850
> # GOTSALK codes to 548500
> # These names don't sound alike, but the matching codes means a search for 
> one returns the other.
> Solution: I exchanged emails with Gary Mokotoff, co-creator of the algorithm, 
> who said:
> {quote}I would drop RS from the table. ... I cannot think of any language 
> where RS is pronounced "S" (4).{quote}
>  
>   



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852970#comment-16852970
 ] 

Melloware edited comment on CODEC-214 at 5/31/19 12:34 PM:
---

Or are you saying change...
{code:xml}

 
 Immutable
 a
 This class is immutable
 
 
 NotThreadSafe
 a
 This class is not thread-safe
 
 
 ThreadSafe
 a
 This class is thread-safe
 
 
 {code}


To..

{code:xml}

 
 org.apache.commons.Immutable
 a
 This class is immutable
 
 
 org.apache.commons.NotThreadSafe
 a
 This class is not thread-safe
 
 
 org.apache.commons.ThreadSafe
 a
 This class is thread-safe
 
 
{code}


was (Author: melloware):
Or are you saying change...

{{

  Immutable
  a
  This class is immutable


  NotThreadSafe
  a
  This class is not thread-safe


  ThreadSafe
  a
  This class is thread-safe

  }}

To

{{

  org.apache.commons.Immutable
  a
  This class is immutable


  org.apache.commons.NotThreadSafe
  a
  This class is not thread-safe


  org.apache.commons.ThreadSafe
  a
  This class is thread-safe

  }}

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852970#comment-16852970
 ] 

Melloware commented on CODEC-214:
-

Or are you saying change...


  Immutable
  a
  This class is immutable


  NotThreadSafe
  a
  This class is not thread-safe


  ThreadSafe
  a
  This class is thread-safe

  

To



  org.apache.commons.Immutable
  a
  This class is immutable


  org.apache.commons.NotThreadSafe
  a
  This class is not thread-safe


  org.apache.commons.ThreadSafe
  a
  This class is thread-safe

  

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852970#comment-16852970
 ] 

Melloware edited comment on CODEC-214 at 5/31/19 12:32 PM:
---

Or are you saying change...

{{

  Immutable
  a
  This class is immutable


  NotThreadSafe
  a
  This class is not thread-safe


  ThreadSafe
  a
  This class is thread-safe

  }}

To

{{

  org.apache.commons.Immutable
  a
  This class is immutable


  org.apache.commons.NotThreadSafe
  a
  This class is not thread-safe


  org.apache.commons.ThreadSafe
  a
  This class is thread-safe

  }}


was (Author: melloware):
Or are you saying change...


  Immutable
  a
  This class is immutable


  NotThreadSafe
  a
  This class is not thread-safe


  ThreadSafe
  a
  This class is thread-safe

  

To



  org.apache.commons.Immutable
  a
  This class is immutable


  org.apache.commons.NotThreadSafe
  a
  This class is not thread-safe


  org.apache.commons.ThreadSafe
  a
  This class is thread-safe

  

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852967#comment-16852967
 ] 

Melloware commented on CODEC-214:
-

I guess what I am saying is this ticket says "Change the pom to use Javadoc 
plugin like Commons Compress".

That is not accurate from what you are saying.  You are saying the ticket 
should just say "we should use custom annotations in our codebase such 
@org.apache.commons.Immutable".  So to me that is a completely new ticket 
making this ticket moot as changing the Javadoc plugin to be like Commons 
Compress is not accurate.

Or am I not understanding what you are saying?

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852953#comment-16852953
 ] 

Melloware commented on CODEC-214:
-

Then IMHO we should close this ticket...

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852942#comment-16852942
 ] 

Melloware commented on CODEC-214:
-

PR Submitted: https://github.com/apache/commons-codec/pull/20

> Update POM to support @NotThreadSafe @Immutable Javadoc tags
> 
>
> Key: CODEC-214
> URL: https://issues.apache.org/jira/browse/CODEC-214
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Sebb
>Priority: Major
> Attachments: pom.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Commons Compress uses @Immutable etc tags in Javadoc
> Codec could do the same



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (CODEC-256) ColognePhonetic.encode() calculates wrong code

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852929#comment-16852929
 ] 

Melloware edited comment on CODEC-256 at 5/31/19 11:41 AM:
---

[~aschnur] I am creating a GitHub PR for your change.  You change works however 
one of the previous unit tests fails and I want to confirm it is failing.   
Right now it has..

hoffmann=0366
mönchengladbach=664645214
deutsch=28
Zacharias=8478
matsch=68
Eberhard=01772
Eberhardt=01772
Celsius=8558

And with your fix it now reports it should be...

hoffmann=036
mönchengladbach=64645214
deutsch=284
Zacharias=878
matsch=684
Eberhard=0172
Eberhardt=0172
Celsius=858


Can you confirm this is correct?


was (Author: melloware):
[~aschnur] I am creating a GitHub PR for your change.  You change works however 
one of the previous unit tests fails and I want to confirm it is failing.   
Right now it has..

hoffmann=0366

And with your fix it now reports it should be...

hoffmann=036

Can you confirm this is correct?

> ColognePhonetic.encode() calculates wrong code
> --
>
> Key: CODEC-256
> URL: https://issues.apache.org/jira/browse/CODEC-256
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.12
> Environment: Java 8u181 64, Windows 7 Professional 64
>Reporter: Andreas Schnur
>Priority: Major
> Attachments: ColognePhonetic.java
>
>
> Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore 
> is left out), Code of N is 6 and should be left out because 6 is previous, 
> but Code assumes wrongly 0 as previous (which was left out). So the result is 
> 07266, but has to be 0726 (see Description of algorithm in class).
> Solution: In method colognePhonetic() move the last two LOC into if-block 
> above, see attached version of class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-256) ColognePhonetic.encode() calculates wrong code

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16852929#comment-16852929
 ] 

Melloware commented on CODEC-256:
-

[~aschnur] I am creating a GitHub PR for your change.  You change works however 
one of the previous unit tests fails and I want to confirm it is failing.   
Right now it has..

hoffmann=0366

And with your fix it now reports it should be...

hoffmann=036

Can you confirm this is correct?

> ColognePhonetic.encode() calculates wrong code
> --
>
> Key: CODEC-256
> URL: https://issues.apache.org/jira/browse/CODEC-256
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.12
> Environment: Java 8u181 64, Windows 7 Professional 64
>Reporter: Andreas Schnur
>Priority: Major
> Attachments: ColognePhonetic.java
>
>
> Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore 
> is left out), Code of N is 6 and should be left out because 6 is previous, 
> but Code assumes wrongly 0 as previous (which was left out). So the result is 
> 07266, but has to be 0726 (see Description of algorithm in class).
> Solution: In method colognePhonetic() move the last two LOC into if-block 
> above, see attached version of class.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BEANUTILS-463) Class loader vulnerability in DefaultResolver

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846330#comment-16846330
 ] 

Melloware commented on BEANUTILS-463:
-

Submitted PR: https://github.com/apache/commons-beanutils/pull/7

This will close this CVE for BeanUtils2 if accepted.

> Class loader vulnerability in DefaultResolver
> -
>
> Key: BEANUTILS-463
> URL: https://issues.apache.org/jira/browse/BEANUTILS-463
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Expression Syntax
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.9.0, 1.9.1
>Reporter: Patrick Trainor
>Priority: Major
> Fix For: 1.9.2
>
>
> There is no check for the "class" keyword when getting nested properties. 
> Please see here (and translate it) for a more detailed explanation:
> http://qiita.com/kawasima/items/670d2591bc8fea19dc1d



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846328#comment-16846328
 ] 

Melloware commented on BEANUTILS-520:
-

PR submitted: https://github.com/apache/commons-beanutils/pull/7

> BeanUtils2 mitigate CVE-2014-0114
> -
>
> Key: BEANUTILS-520
> URL: https://issues.apache.org/jira/browse/BEANUTILS-520
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 1.9.3
>Reporter: Melloware
>Priority: Major
>  Labels: security
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> https://nvd.nist.gov/vuln/detail/CVE-2014-0114
> Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
> marked as a security risk through most major checks from OWASP and Sonatype 
> IQ.
> "commons-beanutils added a SuppressPropertiesBeanIntrospector which includes 
> a specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
> version 1.9.2 that specifically suppresses the class property. +However, this 
> fix is not enabled by default.+"
> For BeanUtils2 why not make this the default and have people "enable" it if 
> it they want to get the feature.
> Thanks for your consideration.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845821#comment-16845821
 ] 

Melloware commented on CODEC-134:
-

[~ggregory] yep we use a ton of Apache Commons libraries and currently the only 
2 security issues being flagged are this one and the one I reported on 
BeanUtils https://issues.apache.org/jira/browse/BEANUTILS-520   I understand 
the approach taken for BU 1.9.3 but I made my case in that ticket to start off 
mor esecure and have people opt-in to insecurity!

i will let you know if I find any other issues reported but so far all the 
other Commons are looking pretty good.

> Base32 would decode some invalid Base32 encoded string into arbitrary value
> ---
>
> Key: CODEC-134
> URL: https://issues.apache.org/jira/browse/CODEC-134
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: All
>Reporter: Hanson Char
>Assignee: Gary Gregory
>Priority: Major
>  Labels: security
> Fix For: 1.13
>
> Attachments: diff-120305-20.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Example, there is no byte array value that can be encoded into the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation 
> would not reject it but decode it into an arbitrary value which if re-encoded 
> again using the same implementation would result in the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===".
> Instead of blindly decoding the invalid string, the Base32 codec should 
> reject it (eg by throwing IlleglArgumentException) to avoid security 
> exploitation (such as tunneling additional information via seemingly valid 
> base 32 strings).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845778#comment-16845778
 ] 

Melloware commented on CODEC-134:
-

Thank you [~ggregory] my company is on a big kick for production software to 
use only libraries that have no open CVE's against them.  This will be a big 
help.

> Base32 would decode some invalid Base32 encoded string into arbitrary value
> ---
>
> Key: CODEC-134
> URL: https://issues.apache.org/jira/browse/CODEC-134
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: All
>Reporter: Hanson Char
>Assignee: Gary Gregory
>Priority: Major
>  Labels: security
> Fix For: 1.13
>
> Attachments: diff-120305-20.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Example, there is no byte array value that can be encoded into the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation 
> would not reject it but decode it into an arbitrary value which if re-encoded 
> again using the same implementation would result in the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===".
> Instead of blindly decoding the invalid string, the Base32 codec should 
> reject it (eg by throwing IlleglArgumentException) to avoid security 
> exploitation (such as tunneling additional information via seemingly valid 
> base 32 strings).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CODEC-134) Base32 would decode some invalid Base32 encoded string into arbitrary value

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844920#comment-16844920
 ] 

Melloware commented on CODEC-134:
-

Any idea on release date of 1.13?

> Base32 would decode some invalid Base32 encoded string into arbitrary value
> ---
>
> Key: CODEC-134
> URL: https://issues.apache.org/jira/browse/CODEC-134
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.6
> Environment: All
>Reporter: Hanson Char
>Assignee: Gary Gregory
>Priority: Major
>  Labels: security
> Fix For: 1.13
>
> Attachments: diff-120305-20.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Example, there is no byte array value that can be encoded into the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4L===", but the existing Base32 implementation 
> would not reject it but decode it into an arbitrary value which if re-encoded 
> again using the same implementation would result in the string 
> "C5CYMIHWQUUZMKUGZHGEOSJSQDE4K===".
> Instead of blindly decoding the invalid string, the Base32 codec should 
> reject it (eg by throwing IlleglArgumentException) to avoid security 
> exploitation (such as tunneling additional information via seemingly valid 
> base 32 strings).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (BEANUTILS-520) BeanUtils2 mitigate CVE-2014-0114

[Melloware (JIRA)]

Melloware created BEANUTILS-520:
---

 Summary: BeanUtils2 mitigate CVE-2014-0114
 Key: BEANUTILS-520
 URL: https://issues.apache.org/jira/browse/BEANUTILS-520
 Project: Commons BeanUtils
  Issue Type: Improvement
  Components: Bean / Property Utils
Affects Versions: 1.9.3
Reporter: Melloware


https://nvd.nist.gov/vuln/detail/CVE-2014-0114

Due to the above CVE in 1.9.2 they added a Suppression but it is still being 
marked as a security risk through most major checks from OWASP and Sonatype IQ.

"commons-beanutils added a SuppressPropertiesBeanIntrospector which includes a 
specialized instance of itself as the SUPPRESS_CLASS constant beginning in 
version 1.9.2 that specifically suppresses the class property. +However, this 
fix is not enabled by default.+"

For BeanUtils2 why not make this the default and have people "enable" it if it 
they want to get the feature.

Thanks for your consideration.
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BEANUTILS-463) Class loader vulnerability in DefaultResolver

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844810#comment-16844810
 ] 

Melloware commented on BEANUTILS-463:
-

Is there any way for BeanUtils2 the default could be to have this OFF and make 
it an opt-in feature if people want to enable it.  My company gets this CVE 
report everyday from Sonatype IQ server.

> Class loader vulnerability in DefaultResolver
> -
>
> Key: BEANUTILS-463
> URL: https://issues.apache.org/jira/browse/BEANUTILS-463
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Expression Syntax
>Affects Versions: 1.8.0, 1.8.1, 1.8.2, 1.8.3, 1.9.0, 1.9.1
>Reporter: Patrick Trainor
>Priority: Major
> Fix For: 1.9.2
>
>
> There is no check for the "class" keyword when getting nested properties. 
> Please see here (and translate it) for a more detailed explanation:
> http://qiita.com/kawasima/items/670d2591bc8fea19dc1d



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16684043#comment-16684043
 ] 

Melloware commented on COMPRESS-446:


Just in case you were interested or wanted to review attached is what I did.  I 
basically start a timer and I cancel the timer if the delete succeeds.  IF the 
delete doesn't succeed it will try the delete again when the timer expires or 
if the delete was never called. [^FailSafeScatterGatherBackingStore.java] 

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --
>
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, 
> the JVM had about 1.7 GByte heap space.
>Reporter: Christoph Ludwig
>Priority: Major
>  Labels: zip
> Fix For: 1.17
>
> Attachments: FailSafeScatterGatherBackingStore.java
>
>
> Before it does anything else, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all 
> futures returned by the creator`s executor service and calls 
> {{Future#get()}}. This will block until the future's computation is 
> completed, respectively - i.e., until all entries have been written to the 
> thread-local scatter streams.
> However, if the computation of a future fails, then {{Future#get()}} can also 
> throw an exception. This exception escapes 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the 
> executor service is shut down. The latter means that also the thread-local 
> variables in the executor service's threads and all objects referenced by 
> them continue to exist and cannot be reclaimed by the GC.
> I encountered this situation when - while processing an archive with 130,000 
> documents - the JVM threw an {{OutOfMemoryError}}. The application was not 
> able to recover from this OOM error because most of the heap was occupied by 
> objects reachable from the executor service's threads.
> Of course, the OOM is mostly the fault of my own code; I will be able to work 
> around the "leaked" executor service because I supply it in the first place 
> and can therefore shut it down if I detect an error situation.  
> The effect would be the same, though, if, say, {{Future#get()}} throws an 
> {{InterruptedException}}. Therefore, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either 
> shut down and release all resources if it cannot complete its task due to an 
> Exception thrown by a future or it should offer a reasonable recovery 
> strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)

[Melloware (JIRA)]

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

Melloware updated COMPRESS-446:
---
Attachment: FailSafeScatterGatherBackingStore.java

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --
>
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, 
> the JVM had about 1.7 GByte heap space.
>Reporter: Christoph Ludwig
>Priority: Major
>  Labels: zip
> Fix For: 1.17
>
> Attachments: FailSafeScatterGatherBackingStore.java
>
>
> Before it does anything else, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all 
> futures returned by the creator`s executor service and calls 
> {{Future#get()}}. This will block until the future's computation is 
> completed, respectively - i.e., until all entries have been written to the 
> thread-local scatter streams.
> However, if the computation of a future fails, then {{Future#get()}} can also 
> throw an exception. This exception escapes 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the 
> executor service is shut down. The latter means that also the thread-local 
> variables in the executor service's threads and all objects referenced by 
> them continue to exist and cannot be reclaimed by the GC.
> I encountered this situation when - while processing an archive with 130,000 
> documents - the JVM threw an {{OutOfMemoryError}}. The application was not 
> able to recover from this OOM error because most of the heap was occupied by 
> objects reachable from the executor service's threads.
> Of course, the OOM is mostly the fault of my own code; I will be able to work 
> around the "leaked" executor service because I supply it in the first place 
> and can therefore shut it down if I detect an error situation.  
> The effect would be the same, though, if, say, {{Future#get()}} throws an 
> {{InterruptedException}}. Therefore, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either 
> shut down and release all resources if it cannot complete its task due to an 
> Exception thrown by a future or it should offer a reasonable recovery 
> strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682374#comment-16682374
 ] 

Melloware commented on COMPRESS-446:


OK I am using raw commons compress so we should be able to attempt this.

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --
>
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, 
> the JVM had about 1.7 GByte heap space.
>Reporter: Christoph Ludwig
>Priority: Major
>  Labels: zip
> Fix For: 1.17
>
>
> Before it does anything else, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all 
> futures returned by the creator`s executor service and calls 
> {{Future#get()}}. This will block until the future's computation is 
> completed, respectively - i.e., until all entries have been written to the 
> thread-local scatter streams.
> However, if the computation of a future fails, then {{Future#get()}} can also 
> throw an exception. This exception escapes 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the 
> executor service is shut down. The latter means that also the thread-local 
> variables in the executor service's threads and all objects referenced by 
> them continue to exist and cannot be reclaimed by the GC.
> I encountered this situation when - while processing an archive with 130,000 
> documents - the JVM threw an {{OutOfMemoryError}}. The application was not 
> able to recover from this OOM error because most of the heap was occupied by 
> objects reachable from the executor service's threads.
> Of course, the OOM is mostly the fault of my own code; I will be able to work 
> around the "leaked" executor service because I supply it in the first place 
> and can therefore shut it down if I detect an error situation.  
> The effect would be the same, though, if, say, {{Future#get()}} throws an 
> {{InterruptedException}}. Therefore, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either 
> shut down and release all resources if it cannot complete its task due to an 
> Exception thrown by a future or it should offer a reasonable recovery 
> strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681942#comment-16681942
 ] 

Melloware commented on COMPRESS-446:


I might be able to do that. Can you provide an example of 
ScatterGatherBackingStoreSupplier and how I would inject it into the process to 
clean up these temp files?   

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --
>
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, 
> the JVM had about 1.7 GByte heap space.
>Reporter: Christoph Ludwig
>Priority: Major
>  Labels: zip
> Fix For: 1.17
>
>
> Before it does anything else, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all 
> futures returned by the creator`s executor service and calls 
> {{Future#get()}}. This will block until the future's computation is 
> completed, respectively - i.e., until all entries have been written to the 
> thread-local scatter streams.
> However, if the computation of a future fails, then {{Future#get()}} can also 
> throw an exception. This exception escapes 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the 
> executor service is shut down. The latter means that also the thread-local 
> variables in the executor service's threads and all objects referenced by 
> them continue to exist and cannot be reclaimed by the GC.
> I encountered this situation when - while processing an archive with 130,000 
> documents - the JVM threw an {{OutOfMemoryError}}. The application was not 
> able to recover from this OOM error because most of the heap was occupied by 
> objects reachable from the executor service's threads.
> Of course, the OOM is mostly the fault of my own code; I will be able to work 
> around the "leaked" executor service because I supply it in the first place 
> and can therefore shut it down if I detect an error situation.  
> The effect would be the same, though, if, say, {{Future#get()}} throws an 
> {{InterruptedException}}. Therefore, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either 
> shut down and release all resources if it cannot complete its task due to an 
> Exception thrown by a future or it should offer a reasonable recovery 
> strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-470) ParallelScatterZipCreator leaks temporary files (and maybe more)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16681816#comment-16681816
 ] 

Melloware commented on COMPRESS-470:


Thank you for opening this issue.  We really appreciate you reviewing it!

And to confirm the only way right now we can delete these files is by stopping 
our app (JBoss) then deleting them and restarting our app.   because if we 
delete on Linux they are not truly deleted because it knows the original PID 
(Jboss) is holding references to them.  Thank you in advance to any fixes you 
can provide.

> ParallelScatterZipCreator leaks temporary files (and maybe more)
> 
>
> Key: COMPRESS-470
> URL: https://issues.apache.org/jira/browse/COMPRESS-470
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.18
>Reporter: Stefan Bodewig
>Priority: Major
>
> As indicated by 
> https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679878#comment-16679878
>  COMPRESS-446 may have closed one resource leak but not all of them.
> If an exception occurs in {{writeTo}} we may miss calling {{close}} on some 
> of the {{ScatterZipOutputStream}}s which in turn may leak resources like 
> temporary files opened by using {{FileBasedScatterGatherBackingStore}}.
> This affects all versions since 1.10



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679878#comment-16679878
 ] 

Melloware commented on COMPRESS-446:


We are still seeing this error on Commons Compress 1.18 intermittently leaving 
these TMP files for ParallelScatter.  Our system runs 24/7 and is zipping files 
hourly so over a 1 month period we have seen it leave say 4-6 of these files 
around.  The problem is they don't get cleaned up and fills our /TMP eventually 
to 100%.

Any thoughts?

> Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
> --
>
> Key: COMPRESS-446
> URL: https://issues.apache.org/jira/browse/COMPRESS-446
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.16.1
> Environment: The application was running inside a Docker container, 
> the JVM had about 1.7 GByte heap space.
>Reporter: Christoph Ludwig
>Priority: Major
>  Labels: zip
> Fix For: 1.17
>
>
> Before it does anything else, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all 
> futures returned by the creator`s executor service and calls 
> {{Future#get()}}. This will block until the future's computation is 
> completed, respectively - i.e., until all entries have been written to the 
> thread-local scatter streams.
> However, if the computation of a future fails, then {{Future#get()}} can also 
> throw an exception. This exception escapes 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the 
> executor service is shut down. The latter means that also the thread-local 
> variables in the executor service's threads and all objects referenced by 
> them continue to exist and cannot be reclaimed by the GC.
> I encountered this situation when - while processing an archive with 130,000 
> documents - the JVM threw an {{OutOfMemoryError}}. The application was not 
> able to recover from this OOM error because most of the heap was occupied by 
> objects reachable from the executor service's threads.
> Of course, the OOM is mostly the fault of my own code; I will be able to work 
> around the "leaked" executor service because I supply it in the first place 
> and can therefore shut it down if I detect an error situation.  
> The effect would be the same, though, if, say, {{Future#get()}} throws an 
> {{InterruptedException}}. Therefore, 
> {{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}}  should either 
> shut down and release all resources if it cannot complete its task due to an 
> Exception thrown by a future or it should offer a reasonable recovery 
> strategy. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BEANUTILS-500) Upgrade from Apache Commons Collections 3 to 4

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16470203#comment-16470203
 ] 

Melloware commented on BEANUTILS-500:
-

+1 Dave Brosius.  I think it would be great to get a public release of this out 
there!

> Upgrade from Apache Commons Collections 3 to 4
> --
>
> Key: BEANUTILS-500
> URL: https://issues.apache.org/jira/browse/BEANUTILS-500
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 2.0.0
>Reporter: Dave Brosius
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: BEANUTILS-500.2.txt, BEANUTILS-500.3.txt, 
> BEANUTILS-500.txt
>
>
> uptake commons-collections4.
> The main difference is the removal of 'FastHashMap', and replacement with 
> ConcurrentHashMap.
> There are a few breaking changes for deprecated methods that return a 
> FastHashMap, that are exposed.
> I made them package private, and undeprecated them, thus 2.0



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (BEANUTILS-500) Upgrade commons-collections to 4

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159988#comment-16159988
 ] 

Melloware commented on BEANUTILS-500:
-

After applying this patch to trunk I get 7 failing unit tests...

Failed tests:
  Jira61TestCase.testIssue_BEANUTILS_61_PropertyUtils_getProperty_Mapped:360 
mappedReadOnly Threw exception: java.lang.NoSuchMethodException: Unknown 
property 'mappedReadOnly'+ on bean class 'class 
org.apache.commons.beanutils.WrapDynaBean'
  Jira61TestCase.testIssue_BEANUTILS_61_PropertyUtils_setProperty_Mapped:387 
mappedReadOnly Threw exception: java.lang.NoSuchMethodException: Unknown 
property 'mappedReadOnly' on bean class 'class 
org.apache.commons.beanutils.WrapDynaBean'
  MemoryLeakTestCase.testConvertUtilsBean_converters_memoryLeak:389 
ConvertUtilsBean is holding a reference to the classLoader expected null, but 
was:
  MemoryLeakTestCase.testLocaleConvertUtilsBean_converters_memoryLeak:437 
LocaleConvertUtilsBean is holding a reference to the classLoader expected null, 
but was:
  MemoryLeakTestCase.testPropertyUtilsBean_descriptorsCache_memoryLeak:91 
PropertyUtilsBean is holding a reference to the classLoader expected null, but 
was:
  
MemoryLeakTestCase.testPropertyUtilsBean_mappedDescriptorsCache_memoryLeak:144 
PropertyUtilsBean is holding a reference to the classLoader expected null, but 
was:
  MemoryLeakTestCase.testWrapDynaClass_dynaClasses_memoryLeak:341 WrapDynaClass 
is holding a reference to the classLoader expected null, but 
was:

Tests run: 1291, Failures: 7, Errors: 0, Skipped: 3

> Upgrade commons-collections to 4
> 
>
> Key: BEANUTILS-500
> URL: https://issues.apache.org/jira/browse/BEANUTILS-500
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 2.0
>Reporter: Dave Brosius
>Priority: Minor
> Fix For: 2.0
>
> Attachments: BEANUTILS-500.txt
>
>
> uptake commons-collections4.
> The main difference is the removal of 'FastHashMap', and replacement with 
> ConcurrentHashMap.
> There are a few breaking changes for deprecated methods that return a 
> FastHashMap, that are exposed.
> I made them package private, and undeprecated them, thus 2.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BEANUTILS-475) beanutils could use commons-collections4 instead of commons-collections 3

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159984#comment-16159984
 ] 

Melloware commented on BEANUTILS-475:
-

Patch provided in https://issues.apache.org/jira/browse/BEANUTILS-500

> beanutils could use commons-collections4 instead of commons-collections 3
> -
>
> Key: BEANUTILS-475
> URL: https://issues.apache.org/jira/browse/BEANUTILS-475
> Project: Commons BeanUtils
>  Issue Type: Bug
>Reporter: Thibault Kruse
>Priority: Minor
> Fix For: 2.0
>
>
> just curious.
> collections4 seems to be out since 2013, maybe could be advertized more 
> inside apache



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (BEANUTILS-500) Upgrade commons-collections to 4

[Melloware (JIRA)]

[ 
https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159249#comment-16159249
 ] 

Melloware commented on BEANUTILS-500:
-

Definitely would love this change as my project only dependency on the regular 
commons collections is BeanUtils.  Once it is switched all of mine will be on 
Collections4 and I can remove old Collections from my WAR.  Right now I need 
both collections with BeanUtils 1.9.3

> Upgrade commons-collections to 4
> 
>
> Key: BEANUTILS-500
> URL: https://issues.apache.org/jira/browse/BEANUTILS-500
> Project: Commons BeanUtils
>  Issue Type: Improvement
>  Components: Bean / Property Utils
>Affects Versions: 2.0
>Reporter: Dave Brosius
>Priority: Minor
> Fix For: 2.0
>
> Attachments: BEANUTILS-500.txt
>
>
> uptake commons-collections4.
> The main difference is the removal of 'FastHashMap', and replacement with 
> ConcurrentHashMap.
> There are a few breaking changes for deprecated methods that return a 
> FastHashMap, that are exposed.
> I made them package private, and undeprecated them, thus 2.0



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CONFIGURATION-462) Update dependency Lang 2.xx to Lang 3

[Melloware (JIRA)]

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

Melloware commented on CONFIGURATION-462:
-

The sooner we get this the better.  Is there a release schedule for 2.0 in 
Maven Central.  I have Commons-Lang3 everywhere except this is the only 
dependency I have left pulling in the old commons-lang.  

 Update dependency Lang 2.xx to Lang 3
 -

 Key: CONFIGURATION-462
 URL: https://issues.apache.org/jira/browse/CONFIGURATION-462
 Project: Commons Configuration
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.7
Reporter: Victor Pineda
Priority: Minor
 Fix For: 2.x


 Update commons lang dependency 2.xx, the new commons lang 3. To avoid the 2 
 units. Lang version 3 is better. Why not update the dependency?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira