[jira] [Commented] (BEANUTILS-532) Require commons-beanutils library which supports commons-collections-4.x version
[ https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/BEANUTILS-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/IO-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CONFIGURATION-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ 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 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
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 ope
[jira] [Commented] (BEANUTILS-524) Make BeanUtils copyProperties able to copy Immutable, Mutable and Mixed Java Bean
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/BEANUTILS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/BEANUTILS-527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CSV-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-520) BeanUtils2 mitigate CVE-2014-0114
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16909995#comment-16909995 ] Melloware commented on BEANUTILS-520: - [~ggregory] or [~chtompki] what needs to be done to get a Beanutils 2.0 released? What open work is left? The reason I am interested is it uses Commons Collections 4 and allows me to stop using Collections 3. It will also allow for upgrade of Commons Configuration2 to use Beanutils2 and also stop relying on Commons Collection 3. > 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
[ https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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-248) language.DaitchMokotoffSoundex gives overly broad results for tokens containing RS
[ https://issues.apache.org/jira/browse/CODEC-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16852963#comment-16852963 ] Melloware commented on CODEC-248: - [~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] [Commented] (CODEC-214) Update POM to support @NotThreadSafe @Immutable Javadoc tags
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CODEC-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/BEANUTILS-463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ 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)
[ https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/COMPRESS-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&focusedCommentId=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)
[ https://issues.apache.org/jira/browse/COMPRESS-446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/CONFIGURATION-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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