[GitHub] [commons-codec] coveralls edited a comment on issue #31: Added RandomAccessFile digest methods
coveralls edited a comment on issue #31: Added RandomAccessFile digest methods URL: https://github.com/apache/commons-codec/pull/31#issuecomment-559906891 [](https://coveralls.io/builds/27403492) Coverage increased (+0.01%) to 93.339% when pulling **8ee651060a20c67ccec3f185e4d7d3633ccdb0b8 on behrangsa:master** into **3ab9ce4b76848afd2da7dca3e37c46259dd70866 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] behrangsa commented on a change in pull request #31: Added RandomAccessFile digest methods
behrangsa commented on a change in pull request #31: Added RandomAccessFile digest methods URL: https://github.com/apache/commons-codec/pull/31#discussion_r353582342 ## File path: src/main/java/org/apache/commons/codec/digest/DigestUtils.java ## @@ -99,6 +101,20 @@ return updateDigest(messageDigest, data).digest(); } +/** + * Reads through a RandomAccessFile using non-blocking-io (NIO) and returns the digest for the data Review comment: Fixed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] behrangsa commented on a change in pull request #31: Added RandomAccessFile digest methods
behrangsa commented on a change in pull request #31: Added RandomAccessFile
digest methods
URL: https://github.com/apache/commons-codec/pull/31#discussion_r353582432
##
File path:
src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
##
@@ -151,6 +156,25 @@ public void testDigestFile() throws IOException {
Assert.assertArrayEquals(digestTestData(),
DigestUtils.digest(DigestUtils.getDigest(messageDigestAlgorithm),getTestFile()));
}
+@Test
+public void testNonBlockingDigestRandomAccessFile() throws IOException {
+Assume.assumeTrue(DigestUtils.isAvailable(messageDigestAlgorithm));
+
+final byte[] expected = digestTestData();
+
+Assert.assertArrayEquals(expected,
Review comment:
Fixed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-codec] behrangsa commented on a change in pull request #31: Added RandomAccessFile digest methods
behrangsa commented on a change in pull request #31: Added RandomAccessFile
digest methods
URL: https://github.com/apache/commons-codec/pull/31#discussion_r353582383
##
File path: src/test/java/org/apache/commons/codec/digest/DigestUtilsTest.java
##
@@ -63,23 +67,37 @@ File getTestFile() {
return testFile;
}
+RandomAccessFile getTestRandomAccessFile() {
+return testRandomAccessFileWrapper;
+}
+
@Before
public void setUp() throws Exception {
new Random().nextBytes(testData);
testFile = File.createTempFile(DigestUtilsTest.class.getName(),
".dat");
try (final FileOutputStream fos = new FileOutputStream(testFile)) {
fos.write(testData);
}
+
+testRandomAccessFile =
File.createTempFile(DigestUtilsTest.class.getName(), ".dat");
+try (final FileOutputStream fos = new
FileOutputStream(testRandomAccessFile)) {
+fos.write(testData);
+}
+testRandomAccessFileWrapper = new
RandomAccessFile(testRandomAccessFile, "rw");
}
@After
public void tearDown() {
if (!testFile.delete()) {
testFile.deleteOnExit();
}
+
+if (!testRandomAccessFile.delete()) {
+testRandomAccessFile.deleteOnExit();
+}
}
-@Test(expected=IllegalArgumentException.class)
+@Test(expected = IllegalArgumentException.class)
Review comment:
Fixed.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-codec] behrangsa commented on a change in pull request #31: Added non-blocking File digest methods
behrangsa commented on a change in pull request #31: Added non-blocking File
digest methods
URL: https://github.com/apache/commons-codec/pull/31#discussion_r353579915
##
File path: src/test/java/org/apache/commons/codec/digest/DigestUtilsTest.java
##
@@ -63,23 +67,37 @@ File getTestFile() {
return testFile;
}
+RandomAccessFile getTestRandomAccessFile() {
+return testRandomAccessFileWrapper;
+}
+
@Before
public void setUp() throws Exception {
new Random().nextBytes(testData);
testFile = File.createTempFile(DigestUtilsTest.class.getName(),
".dat");
try (final FileOutputStream fos = new FileOutputStream(testFile)) {
fos.write(testData);
}
+
+testRandomAccessFile =
File.createTempFile(DigestUtilsTest.class.getName(), ".dat");
+try (final FileOutputStream fos = new
FileOutputStream(testRandomAccessFile)) {
+fos.write(testData);
+}
+testRandomAccessFileWrapper = new
RandomAccessFile(testRandomAccessFile, "rw");
}
@After
public void tearDown() {
if (!testFile.delete()) {
testFile.deleteOnExit();
}
+
+if (!testRandomAccessFile.delete()) {
+testRandomAccessFile.deleteOnExit();
+}
}
-@Test(expected=IllegalArgumentException.class)
+@Test(expected = IllegalArgumentException.class)
Review comment:
It is possible to ignore white-space changes in GitHub reviews:
https://github.blog/2018-05-01-ignore-white-space-in-code-review/
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-collections] dota17 opened a new pull request #122: Improve MapUtils with the null checks, add Javadoc for the parameter indent and add JUnit for it.
dota17 opened a new pull request #122: Improve MapUtils with the null checks, add Javadoc for the parameter indent and add JUnit for it. URL: https://github.com/apache/commons-collections/pull/122 Improve MapUtils with the null checks, add Javadoc for the parameter indent and add JUnit for it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout
[ https://issues.apache.org/jira/browse/TEXT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated TEXT-109: --- Attachment: (was: 8A14350C-87F1-4A58-8AF0-4E1742ED8D64.jpeg) > Implement or document how to use edit distances that consider the keyboard > layout > - > > Key: TEXT-109 > URL: https://issues.apache.org/jira/browse/TEXT-109 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: discussion, edit-distance, help-wanted > > Most edit distances take into consideration number of "changes" required in > one string to match with another string. And they give you a value that > represent the distance between the words. > While it is helpful, when working with datasets and corpora that have been > created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have > mistakes. In some cases a letter was accidentally mistyped. But the character > used is normally close to the correct character. > For example, given the word "one", and two incorrect misspellings "onr" and > "oni". The Levenshtein distance for both would be 1. But if you are aware > that the keyboard layout is English with the QUERTY layout (notice the E and > the R), so the distance between "one" and "onr", would be greater than the > distance between "one" and "oni", because in the English keyboard the letter > 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand, > but by the right hand. > Here's some reference links for further research. > * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/ > * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/ > * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf > * https://github.com/wsong/Typo-Distance > * > https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard > Ideally such edit distance would be extensible to support other keyboard > layouts. > There is some indication that perhaps an existing edit distance like > levenshtein could be extended to take into consideration the keyboard layout. > So perhaps a new edit distance is not entirely necessary. > We could come with the the decision that it is too hard to implement, and it > would be better done in a spell checker, or that it would require some > statistics and would be out of the scope of Text. Or we could simply add > documentation on how to do it, without adding any code. Or, perhaps we add a > new edit distance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout
[ https://issues.apache.org/jira/browse/TEXT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated TEXT-109: --- Attachment: (was: 63B28BEB-F040-46D9-8997-3E09DA2C94C5.jpeg) > Implement or document how to use edit distances that consider the keyboard > layout > - > > Key: TEXT-109 > URL: https://issues.apache.org/jira/browse/TEXT-109 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: discussion, edit-distance, help-wanted > > Most edit distances take into consideration number of "changes" required in > one string to match with another string. And they give you a value that > represent the distance between the words. > While it is helpful, when working with datasets and corpora that have been > created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have > mistakes. In some cases a letter was accidentally mistyped. But the character > used is normally close to the correct character. > For example, given the word "one", and two incorrect misspellings "onr" and > "oni". The Levenshtein distance for both would be 1. But if you are aware > that the keyboard layout is English with the QUERTY layout (notice the E and > the R), so the distance between "one" and "onr", would be greater than the > distance between "one" and "oni", because in the English keyboard the letter > 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand, > but by the right hand. > Here's some reference links for further research. > * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/ > * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/ > * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf > * https://github.com/wsong/Typo-Distance > * > https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard > Ideally such edit distance would be extensible to support other keyboard > layouts. > There is some indication that perhaps an existing edit distance like > levenshtein could be extended to take into consideration the keyboard layout. > So perhaps a new edit distance is not entirely necessary. > We could come with the the decision that it is too hard to implement, and it > would be better done in a spell checker, or that it would require some > statistics and would be out of the scope of Text. Or we could simply add > documentation on how to do it, without adding any code. Or, perhaps we add a > new edit distance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout
[ https://issues.apache.org/jira/browse/TEXT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated TEXT-109: --- Attachment: (was: 328DADB9-2465-45E4-B36C-953BFF7C2B9F.jpeg) > Implement or document how to use edit distances that consider the keyboard > layout > - > > Key: TEXT-109 > URL: https://issues.apache.org/jira/browse/TEXT-109 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: discussion, edit-distance, help-wanted > > Most edit distances take into consideration number of "changes" required in > one string to match with another string. And they give you a value that > represent the distance between the words. > While it is helpful, when working with datasets and corpora that have been > created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have > mistakes. In some cases a letter was accidentally mistyped. But the character > used is normally close to the correct character. > For example, given the word "one", and two incorrect misspellings "onr" and > "oni". The Levenshtein distance for both would be 1. But if you are aware > that the keyboard layout is English with the QUERTY layout (notice the E and > the R), so the distance between "one" and "onr", would be greater than the > distance between "one" and "oni", because in the English keyboard the letter > 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand, > but by the right hand. > Here's some reference links for further research. > * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/ > * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/ > * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf > * https://github.com/wsong/Typo-Distance > * > https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard > Ideally such edit distance would be extensible to support other keyboard > layouts. > There is some indication that perhaps an existing edit distance like > levenshtein could be extended to take into consideration the keyboard layout. > So perhaps a new edit distance is not entirely necessary. > We could come with the the decision that it is too hard to implement, and it > would be better done in a spell checker, or that it would require some > statistics and would be out of the scope of Text. Or we could simply add > documentation on how to do it, without adding any code. Or, perhaps we add a > new edit distance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout
[
https://issues.apache.org/jira/browse/TEXT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Andrunas updated TEXT-109:
---
Comment: was deleted
(was:
{code:java}
// Some comments here
public String getFoo()
{
return foo;
}
{code}
)
> Implement or document how to use edit distances that consider the keyboard
> layout
> -
>
> Key: TEXT-109
> URL: https://issues.apache.org/jira/browse/TEXT-109
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Bruno P. Kinoshita
>Priority: Minor
> Labels: discussion, edit-distance, help-wanted
> Attachments: 328DADB9-2465-45E4-B36C-953BFF7C2B9F.jpeg,
> 63B28BEB-F040-46D9-8997-3E09DA2C94C5.jpeg,
> 8A14350C-87F1-4A58-8AF0-4E1742ED8D64.jpeg
>
>
> Most edit distances take into consideration number of "changes" required in
> one string to match with another string. And they give you a value that
> represent the distance between the words.
> While it is helpful, when working with datasets and corpora that have been
> created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have
> mistakes. In some cases a letter was accidentally mistyped. But the character
> used is normally close to the correct character.
> For example, given the word "one", and two incorrect misspellings "onr" and
> "oni". The Levenshtein distance for both would be 1. But if you are aware
> that the keyboard layout is English with the QUERTY layout (notice the E and
> the R), so the distance between "one" and "onr", would be greater than the
> distance between "one" and "oni", because in the English keyboard the letter
> 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand,
> but by the right hand.
> Here's some reference links for further research.
> * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/
> * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/
> * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf
> * https://github.com/wsong/Typo-Distance
> *
> https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard
> Ideally such edit distance would be extensible to support other keyboard
> layouts.
> There is some indication that perhaps an existing edit distance like
> levenshtein could be extended to take into consideration the keyboard layout.
> So perhaps a new edit distance is not entirely necessary.
> We could come with the the decision that it is too hard to implement, and it
> would be better done in a spell checker, or that it would require some
> statistics and would be out of the scope of Text. Or we could simply add
> documentation on how to do it, without adding any code. Or, perhaps we add a
> new edit distance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (TEXT-109) Implement or document how to use edit distances that consider the keyboard layout
[ https://issues.apache.org/jira/browse/TEXT-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Andrunas updated TEXT-109: --- Comment: was deleted (was: Begin war in eu union benelux come for 1 country nederland België luxenburg = 1 bundesland) > Implement or document how to use edit distances that consider the keyboard > layout > - > > Key: TEXT-109 > URL: https://issues.apache.org/jira/browse/TEXT-109 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: discussion, edit-distance, help-wanted > Attachments: 328DADB9-2465-45E4-B36C-953BFF7C2B9F.jpeg, > 63B28BEB-F040-46D9-8997-3E09DA2C94C5.jpeg, > 8A14350C-87F1-4A58-8AF0-4E1742ED8D64.jpeg > > > Most edit distances take into consideration number of "changes" required in > one string to match with another string. And they give you a value that > represent the distance between the words. > While it is helpful, when working with datasets and corpora that have been > created with keyboards (e.g. SMS, e-mail, transcripts) it is common to have > mistakes. In some cases a letter was accidentally mistyped. But the character > used is normally close to the correct character. > For example, given the word "one", and two incorrect misspellings "onr" and > "oni". The Levenshtein distance for both would be 1. But if you are aware > that the keyboard layout is English with the QUERTY layout (notice the E and > the R), so the distance between "one" and "onr", would be greater than the > distance between "one" and "oni", because in the English keyboard the letter > 'E' is neighbouring 'R'. Whereas 'I' is not even covered by the left hand, > but by the right hand. > Here's some reference links for further research. > * https://findsomethingnewtoday.wordpress.com/2013/07/20/986/ > * https://www.joyofdata.de/blog/comparison-of-string-distance-algorithms/ > * http://www.nada.kth.se/~ann/exjobb/axel_samuelsson.pdf > * https://github.com/wsong/Typo-Distance > * > https://stackoverflow.com/questions/29233888/edit-distance-such-as-levenshtein-taking-into-account-proximity-on-keyboard > Ideally such edit distance would be extensible to support other keyboard > layouts. > There is some indication that perhaps an existing edit distance like > levenshtein could be extended to take into consideration the keyboard layout. > So perhaps a new edit distance is not entirely necessary. > We could come with the the decision that it is too hard to implement, and it > would be better done in a spell checker, or that it would require some > statistics and would be out of the scope of Text. Or we could simply add > documentation on how to do it, without adding any code. Or, perhaps we add a > new edit distance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (NUMBERS-136) "log10" inconsistent with "log"
[
https://issues.apache.org/jira/browse/NUMBERS-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Barnhill updated NUMBERS-136:
--
Assignee: Eric Barnhill
> "log10" inconsistent with "log"
> ---
>
> Key: NUMBERS-136
> URL: https://issues.apache.org/jira/browse/NUMBERS-136
> Project: Commons Numbers
> Issue Type: Bug
> Components: complex
>Reporter: Gilles Sadowski
>Assignee: Eric Barnhill
>Priority: Major
> Fix For: 1.0
>
>
> For special cases (containing NaN or infinities), method {{log10}} does not
> return the same values as {{log()}} (cf. case commented out below).
> {code}
> @Test
> public void testLog10Consistency() {
> // Infinities should map to the same values as computed with "log()".
> // Assertions.assertEquals(infInf.log(), infInf.log10());
> Assertions.assertEquals(infNegInf.log(), infNegInf.log10());
> Assertions.assertEquals(negInfInf.log(), negInfInf.log10());
> // Assertions.assertEquals(infNaN.log(), infNaN.log10());
> Assertions.assertEquals(negInfNaN.log(), negInfNaN.log10());
> // Assertions.assertEquals(nanInf.log(), nanInf.log10());
> Assertions.assertEquals(nanNegInf.log(), nanNegInf.log10());
> }
> {code}
> To avoid duplication, I suggest that {{log10}} calls {{log}} as part of its
> implementation.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (POOL-382) Release 2.7.1
Sergei Titov created POOL-382: - Summary: Release 2.7.1 Key: POOL-382 URL: https://issues.apache.org/jira/browse/POOL-382 Project: Commons Pool Issue Type: Task Affects Versions: 2.7.0 Reporter: Sergei Titov Please release 2.7.1. The latest version 2.7.0 was released in July and since then there were bug fixes committed to master that were never released. We are especially interested in POOL-376 which happens in Prod for us periodically. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987267#comment-16987267
]
Henri Biestro commented on JEXL-307:
Changeset: 0d51930407eed691e11dc2767f34ef5df6cbf4b8
Author:henrib
Date: 2019-12-03 22:08
Message: JEXL-307: fixed lexical feature handling of variable scope in for
units (take 3)
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (VFS-748) TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache
[ https://issues.apache.org/jira/browse/VFS-748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim updated VFS-748: Description: A Tar FileObject becomes unusable once it is removed from the filesCache. The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed. The following code snippet will repeatedly access the the tarball until garbage collection occurs. When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that incorrectly marks the file as "IMAGINARY". All subsequent access to this file is are not possible in the VM. Output from the class provided looks like this 97 98 99 100 tgz:[file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/] did not exist The number of successful iterations may vary depending upon the behavior of the GC. Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true. The stack trace for this appears below. at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320) - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300) at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82) - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711) at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648) was: A Tar FileObject becomes unusable once it is removed from the filesCache. The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed. The following code snippet will repeatedly access the the tarball until garbage collection occurs. When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that is incorrectly marks the file as "IMAGINARY". All subsequent access to this file is are not possible in the VM. Output from the class provided looks like this 97 98 99 100 tgz:file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/ did not exist The number of successful iterations may vary depending upon the behavior of the GC. Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true. The stack trace for this appears below. at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320) - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300) at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82) - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711) at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648) > TarProvider Incorrectly marks file IMAGINARY after garbage collection with > weakRefFilesCache > > > Key: VFS-748 > URL: https://issues.apache.org/jira/browse/VFS-748 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.2 > Environment: commons-vfs2.
[jira] [Created] (VFS-748) TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache
Tim created VFS-748: --- Summary: TarProvider Incorrectly marks file IMAGINARY after garbage collection with weakRefFilesCache Key: VFS-748 URL: https://issues.apache.org/jira/browse/VFS-748 Project: Commons VFS Issue Type: Bug Affects Versions: 2.2 Environment: commons-vfs2.2.jar commons-compress-1.18.jar Reporter: Tim Attachments: TarBug.java, test.tar.gz A Tar FileObject becomes unusable once it is removed from the filesCache. The example provided here uses the the WeakRefFilesCache but I suspect the bug is not limited to this cache type only, since it is the recreation of the entry after removal that is flawed. The following code snippet will repeatedly access the the tarball until garbage collection occurs. When this happens the cache entry is dropped but upon reaccess, a new cache entry is created that is incorrectly marks the file as "IMAGINARY". All subsequent access to this file is are not possible in the VM. Output from the class provided looks like this 97 98 99 100 tgz:file:///C:/env/ws/vfsTarBug/target/classes/test.tar.gz!/ did not exist The number of successful iterations may vary depending upon the behavior of the GC. Tracing the run, the culprit appears to be a createFile method which hard codes the tarExists argument to false when it should be true. The stack trace for this appears below. at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210)at org.apache.commons.vfs2.provider.tar.TarFileSystem.createFile(TarFileSystem.java:210) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:320) - locked <0x53d2> (a org.apache.commons.vfs2.provider.tar.TarFileSystem) at org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:300) at org.apache.commons.vfs2.provider.AbstractFileSystem.getRoot(AbstractFileSystem.java:274) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.createFileSystem(AbstractLayeredFileProvider.java:82) - locked <0x53e2> (a org.apache.commons.vfs2.provider.tar.TarFileProvider) at org.apache.commons.vfs2.provider.AbstractLayeredFileProvider.findFile(AbstractLayeredFileProvider.java:56) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:711) at org.pentaho.di.core.vfs.ConcurrentFileSystemManager.resolveFile(ConcurrentFileSystemManager.java:91) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:648) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-77) BoundsXD
Matt Juntunen created GEOMETRY-77:
-
Summary: BoundsXD
Key: GEOMETRY-77
URL: https://issues.apache.org/jira/browse/GEOMETRY-77
Project: Apache Commons Geometry
Issue Type: New Feature
Components: Euclidean 2D, Euclidean 3D
Reporter: Matt Juntunen
Add classes containing min and max vectors defining axis-aligned bounding boxes
for Euclidean 2D and 3D space.
Ex:
{code:java}
public final class Bounds3D {
private final Vector3D min;
private final Vector3D max;
public Vector3D getMin(){ ... }
public Vector3D getMax(){ ... }
public double getMinX(){ ... }
public double getMaxX(){ ... }
// ...
public boolean contains(Vector3D pt) { ... }
public boolean intersects(Bounds3D other) { ... }
public static Bounds3D from(final Vector3D... pts) {
// compute the min and max coordinate values from the input
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEOMETRY-76) Example code module
Matt Juntunen created GEOMETRY-76: - Summary: Example code module Key: GEOMETRY-76 URL: https://issues.apache.org/jira/browse/GEOMETRY-76 Project: Apache Commons Geometry Issue Type: Task Reporter: Matt Juntunen Add a module for example code. This can contain example code for users as well as beta-level functionality that is not yet ready for inclusion in the main modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-75) Performance Test Module
Matt Juntunen created GEOMETRY-75: - Summary: Performance Test Module Key: GEOMETRY-75 URL: https://issues.apache.org/jira/browse/GEOMETRY-75 Project: Apache Commons Geometry Issue Type: Task Reporter: Matt Juntunen Add a module for executing performance tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-74) Region BSP Tree Structural Split
Matt Juntunen created GEOMETRY-74: - Summary: Region BSP Tree Structural Split Key: GEOMETRY-74 URL: https://issues.apache.org/jira/browse/GEOMETRY-74 Project: Apache Commons Geometry Issue Type: Improvement Reporter: Matt Juntunen Add the concept of "structural" splits to the region BSP tree classes. A "structural" split would split a tree node without changing the inside/outside states of the child nodes. This will allow the creation of shallower, more efficient tree structures, especially for convex regions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-73) Create User Guide
Matt Juntunen created GEOMETRY-73: - Summary: Create User Guide Key: GEOMETRY-73 URL: https://issues.apache.org/jira/browse/GEOMETRY-73 Project: Apache Commons Geometry Issue Type: Task Reporter: Matt Juntunen Fix For: 1.0 -- 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=16987087#comment-16987087 ] Gary D. Gregory commented on BEANUTILS-524: --- Darn, I had typed in a long reply and lost it, so I'll cut to the chase. I propose: - No dependency on BULL - Add a CopyUtilsBean class that implements a new interface called TBDCopyUtilsBean (IOW the name is To Be Determined.) - Define interfaces for ConvertUtilsBean and PropertyUtilsBean called TBDConvertUtilsBean, TBDPropertyUtlisBean Ideally: - Add a ctor BeanUtilsBean(ConvertUtilsBean, PropertyUtilsBean, CopyUtilsBean) - Add a ctor BeanUtilsBean(TBDConvertUtilsBean, TBDPropertyUtilsBean, TBDCopyUtilsBean) - Retype guts of BeanUtilsBean to the interfaces We might not even need the class-based ctor since this is 2.0 and we need not keep binary compatibility. This means that CopyUtilsBean needs a default implementation, whatever that is, simple as it may be. Then we can also consider porting the functionality from BULL or not. > 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] (GEOMETRY-63) Review "SonarQube" report
[ https://issues.apache.org/jira/browse/GEOMETRY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987085#comment-16987085 ] Gilles Sadowski commented on GEOMETRY-63: - bq. Any ideas? I tried to "fix" but the code wouldn't compile; so obviously, it was not a good idea... ;-) If there is a definite purpose (and IIUC, users would never directly manipulate the "crude" interface but only the concrete subclasses), it should be mentioned in the Javadoc (not checked, perhaps it's done already). And then you can use the hints provided [there| https://stackoverflow.com/questions/10971968/turning-sonar-off-for-certain-code] in order to silence SonarQube (with a little explanation if possible/necessary). > Review "SonarQube" report > - > > Key: GEOMETRY-63 > URL: https://issues.apache.org/jira/browse/GEOMETRY-63 > Project: Apache Commons Geometry > Issue Type: Task >Reporter: Gilles Sadowski >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > https://sonarcloud.io/dashboard?id=commons-geometry -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-72) Boundary API
Matt Juntunen created GEOMETRY-72:
-
Summary: Boundary API
Key: GEOMETRY-72
URL: https://issues.apache.org/jira/browse/GEOMETRY-72
Project: Apache Commons Geometry
Issue Type: New Feature
Components: Euclidean 2D, Euclidean 3D
Reporter: Matt Juntunen
Fix For: 1.0
Geometric models are often specified as a set of boundaries. These boundaries
may also contain additional data beyond pure geometric information, such as an
identifier, color, reflectance, etc. In order to allow these additional
properties to be used by commons-geometry, we should make a general interface
for region boundaries in Euclidean 2D and 3D. Users could then have their own
classes implement this interface and take advantage of commons-geometry
algorithms.
Here is part of the proposed API for 3D. A similar one would exist for 2D.
{code:java}
public interface Boundary3D {
// Return a convex subplane representing the same boundary as this instance
ConvexSubPlane toSubPlane();
}
{code}
{code:java}
public interface BoundarySource3D {
// get a stream of boundary instances
Stream boundaryStream();
}
{code}
{code:java}
// add additional methods to RegionBSPTree3D
public class RegionBSPTree3D {
// insert a boundary stream into the tree
public void insert(BoundarySource3D src) {
try (Stream stream = src.boundaryStream()) {
stream.forEach(b -> insert(b.toSubPlane());
}
}
}
{code}
This API would also be used for raycasting (see GEOMETRY-68).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEOMETRY-71) Investigate Spherical Barycenter Accuracy
Matt Juntunen created GEOMETRY-71:
-
Summary: Investigate Spherical Barycenter Accuracy
Key: GEOMETRY-71
URL: https://issues.apache.org/jira/browse/GEOMETRY-71
Project: Apache Commons Geometry
Issue Type: Task
Reporter: Matt Juntunen
The current code for computing spherical barycenters in
{{ConvexArea2S.getBarycenter()}} seems to suffer from floating point accuracy
issues. The {{ConvexArea2STest.checkBarycenterConsistency()}} method checks the
consistency of the barycenter computation of a region by splitting the region
into two sections, computing the area and barycenter of each section, and then
computing the combined barycenter of the sections by adding the barycenter of
each scaled by its corresponding area. It is expected that the combined
barycenter computed in this way should equal the barycenter computed for the
region as a whole. However, in practice, a large epsilon value is needed in the
comparison in order for the tests to pass. We need to investigate why this is
the case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEOMETRY-70) Use MathJax
[ https://issues.apache.org/jira/browse/GEOMETRY-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated GEOMETRY-70: -- Fix Version/s: 1.0 > Use MathJax > --- > > Key: GEOMETRY-70 > URL: https://issues.apache.org/jira/browse/GEOMETRY-70 > Project: Apache Commons Geometry > Issue Type: Task >Reporter: Matt Juntunen >Priority: Minor > Fix For: 1.0 > > > Use MathJax in JavaDocs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-70) Use MathJax
Matt Juntunen created GEOMETRY-70: - Summary: Use MathJax Key: GEOMETRY-70 URL: https://issues.apache.org/jira/browse/GEOMETRY-70 Project: Apache Commons Geometry Issue Type: Task Reporter: Matt Juntunen Use MathJax in JavaDocs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-69) BSPTreeVisitor stop visit
Matt Juntunen created GEOMETRY-69:
-
Summary: BSPTreeVisitor stop visit
Key: GEOMETRY-69
URL: https://issues.apache.org/jira/browse/GEOMETRY-69
Project: Apache Commons Geometry
Issue Type: Improvement
Reporter: Matt Juntunen
Fix For: 1.0
Update the BSPTreeVisitor interface to allow implementations to stop the node
visit process when desired. The current implementation always visits all nodes
in the tree. The JDK {{FileVisitor}} interface might be a good reference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEOMETRY-68) Raycast/Linecast API
Matt Juntunen created GEOMETRY-68: - Summary: Raycast/Linecast API Key: GEOMETRY-68 URL: https://issues.apache.org/jira/browse/GEOMETRY-68 Project: Apache Commons Geometry Issue Type: New Feature Reporter: Matt Juntunen Fix For: 1.0 We should add a general API for performing raycast (or "line-cast") operations in Euclidean 2D and 3D. The API should be flexible enough to work with multiple object types, eg RegionBSPTree3D, ConvexSubPlane, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEOMETRY-67) Add Back OutlineExtractor
Matt Juntunen created GEOMETRY-67:
-
Summary: Add Back OutlineExtractor
Key: GEOMETRY-67
URL: https://issues.apache.org/jira/browse/GEOMETRY-67
Project: Apache Commons Geometry
Issue Type: Improvement
Reporter: Matt Juntunen
Fix For: 1.0
The class {{o.a.c.g.euclidean.threed.OutlineExtractor}} was not included in the
refactor from GEOEMTRY-32. The functionality should be added back.
Previous implementation:
https://github.com/apache/commons-geometry/blob/443057b8bbe6955f8baf54e0661e1dc89bdf35ac/commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/threed/OutlineExtractor.java
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-16) Reassess Classes in Exception API
[
https://issues.apache.org/jira/browse/GEOMETRY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987039#comment-16987039
]
Gilles Sadowski commented on GEOMETRY-16:
-
If there is no way to recover from the exception (e.g. error is in caller's
input), I'd think that we should not make specific exceptions part of the
public API, i.e. methods should advertize the JDK's {{IllegalAgumentException}}.
If necessary (e.g. to avoid duplication in message formatting), custom
exception classes should be defined in an "internal" package".
> Reassess Classes in Exception API
> -
>
> Key: GEOMETRY-16
> URL: https://issues.apache.org/jira/browse/GEOMETRY-16
> Project: Apache Commons Geometry
> Issue Type: Task
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.0
>
>
> Before releasing v1.0 of this project, we should reassess the exception types
> that are included in the public API to ensure that each class is actually
> worth including on its own. The overall goal is to keep the exception
> hierarchy useful but with the smallest possible footprint.
> Some examples of existing types that could be combined are the
> CardanSingularityException and EulerSingularityException in the Rotation
> class. It is very unlikely that differentiating between these two types of
> singularities will be important to users.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-63) Review "SonarQube" report
[
https://issues.apache.org/jira/browse/GEOMETRY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16987054#comment-16987054
]
Matt Juntunen commented on GEOMETRY-63:
---
Several of the "critical" code smells are related to my use of generic wildcard
return types in the core interfaces. For example, {{SubHyperplane}} contains
the following method:
{code:java}
List> toConvex();
{code}
I did this to allow implementation classes to return a list of actual
implementation types instead of just {{ConvexSubHyperplane}}. For example,
{{ConvexSubPlane}} overrides this method with
{code:java}
public List toConvex(){ ... }
{code}
which allows callers immediate access to the convex implementation type without
casting. However, I'm not sure how to achieve the same effect without the code
smell. Any ideas?
> Review "SonarQube" report
> -
>
> Key: GEOMETRY-63
> URL: https://issues.apache.org/jira/browse/GEOMETRY-63
> Project: Apache Commons Geometry
> Issue Type: Task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> https://sonarcloud.io/dashboard?id=commons-geometry
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEOMETRY-25) Class "Geometry"
[
https://issues.apache.org/jira/browse/GEOMETRY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved GEOMETRY-25.
-
Resolution: Resolved
Class removed in commit f95363f4abee463123a6c14b706f7efc9aa223e5 ("master").
> Class "Geometry"
>
>
> Key: GEOMETRY-25
> URL: https://issues.apache.org/jira/browse/GEOMETRY-25
> Project: Apache Commons Geometry
> Issue Type: Task
> Components: core
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.0
>
>
> Class only holds trivial constants.
> Better move to an "internal" package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEOMETRY-35) Use "PlaneAngle" from "Commons Numbers"
[
https://issues.apache.org/jira/browse/GEOMETRY-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved GEOMETRY-35.
-
Resolution: Done
commit f95363f4abee463123a6c14b706f7efc9aa223e5
> Use "PlaneAngle" from "Commons Numbers"
> ---
>
> Key: GEOMETRY-35
> URL: https://issues.apache.org/jira/browse/GEOMETRY-35
> Project: Apache Commons Geometry
> Issue Type: Wish
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: reuse
> Fix For: 1.0
>
>
> Module
> [{{commons-numbers-angle}}|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-angle]
> contains utilities that should not be duplicated here. \[Anything general
> enough that is missing there should be the object of a "feature request".\]
> In particular, should we consider having an argument of type
> [{{PlaneAngle}}|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-angle/src/main/java/org/apache/commons/numbers/angle/PlaneAngle.java]
> wherever an angle is used?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1416) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/MATH-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1416.
---
Resolution: Done
> Depend on "Commons Numbers"
> ---
>
> Key: MATH-1416
> URL: https://issues.apache.org/jira/browse/MATH-1416
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: dependency, deprecated
> Fix For: 4.0
>
>
> The following codes with an equivalent in ["Commons
> Numbers"|http://commons.apache.org/proper/commons-numbers] must be deleted
> before the next major release (4.0):
> * Package {{o.a.c.math4.fraction}}
> * Package {{o.a.c.math4.complex}}
> * Package {{o.a.c.math4.primes}}
> Codes that depend on these functionalities must be updated with corresponding
> calls to "Commons Numbers" classes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-imaging] christoffer-rydberg commented on issue #62: Add disposal method to GIF metadata
christoffer-rydberg commented on issue #62: Add disposal method to GIF metadata URL: https://github.com/apache/commons-imaging/pull/62#issuecomment-561203112 Thanks. A bit busy the next few days but I'll add a unit test when I get time over. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (MATH-1395) MathParseException when parsing fractions on Android
[
https://issues.apache.org/jira/browse/MATH-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1395.
---
Fix Version/s: (was: 4.0)
Resolution: Cannot Reproduce
Class {{Fraction}} was removed.
Fraction functionality is now developed in ["Commons
Numbers"|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=tree;f=commons-numbers-fraction].
> MathParseException when parsing fractions on Android
>
>
> Key: MATH-1395
> URL: https://issues.apache.org/jira/browse/MATH-1395
> Project: Commons Math
> Issue Type: Bug
>Reporter: Brian Zable
>Priority: Major
>
> I'm seeing a strange issue when trying to work with the Fraction classes on
> Android. In my tests, which are standard JUnit tests, the following code
> performs flawlessly;
> {code:java}
> String amount = "1 1/2";
> ProperFractionFormat ff = new ProperFractionFormat();
> Fraction f = ff.parse(amount.trim());
> {code}
> However, at run time in an Android application, the same code throws an
> Exception:
> {noformat}
>Caused by:
> org.apache.commons.math3.exception.MathParseException: illegal state: string
> "1 1/2" unparseable (from position 3) as an object of type
> org.apache.commons.math3.fraction.Fraction
> at
> org.apache.commons.math3.fraction.FractionFormat.parse(FractionFormat.java:199)
> {noformat}
> I am testing on a Nexus 5X emulator with API level 23 for reference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1504) Delete "BigFraction"
[
https://issues.apache.org/jira/browse/MATH-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1504.
---
Resolution: Done
Commit cf2b9e7479179bff9111df99b7fa9f30a1bd5a8b ("master" branch).
> Delete "BigFraction"
>
>
> Key: MATH-1504
> URL: https://issues.apache.org/jira/browse/MATH-1504
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Assignee: Gilles Sadowski
>Priority: Major
> Labels: deprecation, remove
> Fix For: 4.0
>
>
> {{BigFraction}} functionality has been ported to ["Commons
> Numbers"|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/BigFraction.java].
--
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] [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=16986915#comment-16986915 ] Fabio Borriello commented on BEANUTILS-524: --- ok, thanks for the clarification, now it's clear and I can do it. Just the last question: how we can inform the end-users that one implementation of that interface has been done in BULL? > 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] [Created] (MATH-1504) Delete "BigFraction"
Gilles Sadowski created MATH-1504:
-
Summary: Delete "BigFraction"
Key: MATH-1504
URL: https://issues.apache.org/jira/browse/MATH-1504
Project: Commons Math
Issue Type: Sub-task
Reporter: Gilles Sadowski
Assignee: Gilles Sadowski
Fix For: 4.0
{{BigFraction}} functionality has been ported to ["Commons
Numbers"|https://gitbox.apache.org/repos/asf?p=commons-numbers.git;a=blob;f=commons-numbers-fraction/src/main/java/org/apache/commons/numbers/fraction/BigFraction.java].
--
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] [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=16986906#comment-16986906
]
Fabio Borriello commented on BEANUTILS-524:
---
[~melloware] sounds good! but, with this approach, the common bean util will
still have the BULL dependency right?
If I understood well the CopyUtilsBean will be something like:
{code}
package org.apache.commons.beanutils2;
import com.hotels.beans.BeanUtils;
import com.hotels.beans.transformer.BeanTransformer;
import com.hotels.transformer.error.InvalidBeanException;
/**
*
*/
public class CopyUtilsBean {
private final BeanTransformer beanTransformer;
public CopyUtilsBean() {
this.beanTransformer = new BeanUtils().getTransformer();
}
public CopyUtilsBean(final BeanTransformer beanTransformer) {
this.beanTransformer = beanTransformer;
}
/**
* Copy property values from the origin bean to the destination bean
* class for all cases where the property names are the same. For each
* property, a conversion is attempted as necessary. All combinations of
* standard JavaBeans and DynaBeans as origin and destination are
* supported. Properties that exist in the origin bean, but do not exist
* in the destination bean (or are read-only in the destination bean) are
* silently ignored and the default value for that type is set.
*
* To define specific mappings please refer to {@link
com.hotels.beans.BeanUtils}
* documentation available see:
* @see https://hotelsdotcom.github.io/bull/transformer/bean/samples.html";>Bean
Transformer documentation
*
*
* @param destClass Destination bean class
* @param orig Origin bean whose properties are retrieved
*
* @throws InvalidBeanException if the destination bean is not valid
*/
public T copyProperties(final Class destClass, final Object orig) {
return beanTransformer.transform(orig, destClass);
}
}
{code}
is this what you mean?
> 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)
[GitHub] [commons-codec] coveralls edited a comment on issue #31: Added non-blocking File digest methods
coveralls edited a comment on issue #31: Added non-blocking File digest methods URL: https://github.com/apache/commons-codec/pull/31#issuecomment-559906891 [](https://coveralls.io/builds/27383567) Coverage increased (+0.01%) to 93.339% when pulling **5b19b1b54a45c728a239946051a87cafef149800 on behrangsa:master** into **3ab9ce4b76848afd2da7dca3e37c46259dd70866 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on a change in pull request #31: Added non-blocking File digest methods
aherbert commented on a change in pull request #31: Added non-blocking File
digest methods
URL: https://github.com/apache/commons-codec/pull/31#discussion_r353159063
##
File path: src/test/java/org/apache/commons/codec/digest/DigestUtilsTest.java
##
@@ -63,23 +67,37 @@ File getTestFile() {
return testFile;
}
+RandomAccessFile getTestRandomAccessFile() {
+return testRandomAccessFileWrapper;
+}
+
@Before
public void setUp() throws Exception {
new Random().nextBytes(testData);
testFile = File.createTempFile(DigestUtilsTest.class.getName(),
".dat");
try (final FileOutputStream fos = new FileOutputStream(testFile)) {
fos.write(testData);
}
+
+testRandomAccessFile =
File.createTempFile(DigestUtilsTest.class.getName(), ".dat");
+try (final FileOutputStream fos = new
FileOutputStream(testRandomAccessFile)) {
+fos.write(testData);
+}
+testRandomAccessFileWrapper = new
RandomAccessFile(testRandomAccessFile, "rw");
}
@After
public void tearDown() {
if (!testFile.delete()) {
testFile.deleteOnExit();
}
+
+if (!testRandomAccessFile.delete()) {
+testRandomAccessFile.deleteOnExit();
+}
}
-@Test(expected=IllegalArgumentException.class)
+@Test(expected = IllegalArgumentException.class)
Review comment:
You have reformatted whitespace for the rest of this class.
It makes it hard to see that you have not actually changed anything below
this line other than whitespace. Can you unformat please.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-codec] aherbert commented on a change in pull request #31: Added non-blocking File digest methods
aherbert commented on a change in pull request #31: Added non-blocking File digest methods URL: https://github.com/apache/commons-codec/pull/31#discussion_r353158195 ## File path: src/main/java/org/apache/commons/codec/digest/DigestUtils.java ## @@ -99,6 +101,20 @@ return updateDigest(messageDigest, data).digest(); } +/** + * Reads through a RandomAccessFile using non-blocking-io (NIO) and returns the digest for the data Review comment: First line of javadoc should end with a period. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on a change in pull request #31: Added non-blocking File digest methods
aherbert commented on a change in pull request #31: Added non-blocking File digest methods URL: https://github.com/apache/commons-codec/pull/31#discussion_r353158280 ## File path: src/main/java/org/apache/commons/codec/digest/DigestUtils.java ## @@ -1207,6 +1223,29 @@ public static MessageDigest updateDigest(final MessageDigest digest, final File } } +/** + * Reads through a RandomAccessFile and updates the digest for the data + * using non-blocking-io (NIO) Review comment: First line of javadoc should end with a period. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on a change in pull request #31: Added non-blocking File digest methods
aherbert commented on a change in pull request #31: Added non-blocking File
digest methods
URL: https://github.com/apache/commons-codec/pull/31#discussion_r353160091
##
File path:
src/test/java/org/apache/commons/codec/digest/MessageDigestAlgorithmsTest.java
##
@@ -151,6 +156,25 @@ public void testDigestFile() throws IOException {
Assert.assertArrayEquals(digestTestData(),
DigestUtils.digest(DigestUtils.getDigest(messageDigestAlgorithm),getTestFile()));
}
+@Test
+public void testNonBlockingDigestRandomAccessFile() throws IOException {
+Assume.assumeTrue(DigestUtils.isAvailable(messageDigestAlgorithm));
+
+final byte[] expected = digestTestData();
+
+Assert.assertArrayEquals(expected,
Review comment:
In keeping with the rest of the class can you reformat the assertions to a
single line. The 5 lines per assertion are very explicit.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[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)
[GitHub] [commons-codec] behrangsa commented on issue #31: Added non-blocking File digest methods
behrangsa commented on issue #31: Added non-blocking File digest methods URL: https://github.com/apache/commons-codec/pull/31#issuecomment-561149352 > Let's step back and ask: Why would we want two implementations for `File` objects? If NIO does the job better, then let's change the implementation to do that. I thought using NIO would improve performance but in my limited tests I didn't notice a meaningful difference. It would be great if some NIO experts could chime in. However we can: * Get rid of `nonblockingDigest(final MessageDigest messageDigest, final File data)` * Rename `nonblockingDigest(final MessageDigest messageDigest, final RandomAccessFile data)` to `digest(final MessageDigest messageDigest, final RandomAcessFile data)` as the first method calls wraps the File in a RandomAccessFile and passes it to the 2nd method anyway. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (MATH-1446) Delete class "Fraction"
[
https://issues.apache.org/jira/browse/MATH-1446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1446.
---
Fix Version/s: 4.0
Resolution: Done
Commit b8d96de5871d938f678b4702c2fcc306bdf1f34d ("master" branch).
> Delete class "Fraction"
> ---
>
> Key: MATH-1446
> URL: https://issues.apache.org/jira/browse/MATH-1446
> Project: Commons Math
> Issue Type: Sub-task
>Reporter: Gilles Sadowski
>Priority: Major
> Labels: dependency, refactoring
> Fix For: 4.0
>
>
> Replace all occurrences of that class by its equivalent in "Commons Numbers"
> (defined in module {{commons-numbers-fraction}}).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CODEC-268) Deprecate methods in MurmurHash3 with no equivalent in the reference c++ source.
[
https://issues.apache.org/jira/browse/CODEC-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986828#comment-16986828
]
Alex Herbert commented on CODEC-268:
I have deprecated the hash64 methods as they are not part of MurmurHash3
implementation. We do not know the hash collision rate properties of these
methods and it is best to recommend not using them.
I deprecated the methods that accept a String and convert using the default
encoding. The method now recommends to use the bytes from
String.getBytes(Charset). The user will have type about 20 extra characters:
{code:java}
String s;
long[] h1 = MurmurHash3.hash128(s);
long[] h2 = MurmurHash3.hash128x64(s.getBytes(StandardCharsets.UTF_8));
{code}
I deprecated the NULL_HASHCODE. This is not used and can be removed in the
future.
A lot of the hash32 methods with the mix and match of position, length and seed
are deprecated anyway in favour of the hash32x86 method which fixed a bug in
hash32.
I have not deprecated the hash32 methods that use primitives and a default seed
of 104729. Although strange the methods are not broken. I updated the
documentation to state they are the same as calling hash32x86 with the big
endian bytes.
Ideally these should use little endian bytes and a seed of zero. But
deprecating them for argument choices is harsher than deprecating the others
which are plain wrong.
The public API without deprecation is now:
{code:java}
public static final int DEFAULT_SEED = 104729;
public static int hash32(final long data1, final long data2) {
public static int hash32(final long data1, final long data2, final int seed) {
public static int hash32(final long data) {
public static int hash32(final long data, final int seed) {
public static int hash32x86(final byte[] data) {
public static int hash32x86(final byte[] data, final int offset, final int
length, final int seed) {
public static long[] hash128x64(final byte[] data) {
public static long[] hash128x64(final byte[] data, final int offset, final int
length, final int seed) {
{code}
The hash32 methods with the primitives seem out-of-place. But since they are
not incorrect I will leave them for now.
> Deprecate methods in MurmurHash3 with no equivalent in the reference c++
> source.
>
>
> Key: CODEC-268
> URL: https://issues.apache.org/jira/browse/CODEC-268
> Project: Commons Codec
> Issue Type: Wish
>Affects Versions: 1.13
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
>
> The following methods have no equivalent in the [MurmurHash3 c++ source
> code|https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp]
> {code:java}
> public static long hash64(final long data) {
> public static long hash64(final int data) {
> public static long hash64(final short data) {
> public static long hash64(final byte[] data) {
> public static long hash64(final byte[] data, final int offset, final int
> length) {
> public static long hash64(final byte[] data, final int offset, final int
> length, final int seed) {
> {code}
> They are documented to return the upper 64-bits of the 128-bit hash method.
> This is false as the code neglects to mix in alternating blocks of 64-bits
> with the corresponding other hash that would be built in the 128-bit method.
> Thus this passes using a NotEquals check:
> {code:java}
> @Test
> public void testHash64InNotEqualToHash128() {
> for (int i = 0; i < 32; i++) {
> final byte[] bytes = Arrays.copyOf(RANDOM_BYTES, i);
> final long h1 = MurmurHash3.hash64(bytes);
> final long[] hash = MurmurHash3.hash128(bytes);
> Assert.assertNotEquals("Did not expect hash64 to match upper bits of
> hash128", hash[0], h1);
> Assert.assertNotEquals("Did not expect hash64 to match lower bits of
> hash128", hash[1], h1);
> }
> }
> {code}
> The following methods are convenience methods that use an arbitrary default
> seed:
> {code:java}
> public static final int DEFAULT_SEED = 104729;
> public static int hash32(final long data1, final long data2) {
> public static int hash32(final long data1, final long data2, final int
> seed) {
> public static int hash32(final long data) {
> public static int hash32(final long data, final int seed) {
> {code}
> Although they match calling hash32() with the equivalent bytes this assumes
> big-endian format. The reference c++ code is designed for little endian. If
> you hash the corresponding values using a Google Guava implementation with
> the same seed then they do not match as Guava faithfully converts primitives
> as little endian. Also note that the available methods for hashing primitives
> are not the same as those in hash64.
> These methods thus
[GitHub] [commons-codec] ken-kentan closed pull request #33: Added string helper method to MurmurHash3.hash64
ken-kentan closed pull request #33: Added string helper method to MurmurHash3.hash64 URL: https://github.com/apache/commons-codec/pull/33 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] ken-kentan commented on issue #33: Added string helper method to MurmurHash3.hash64
ken-kentan commented on issue #33: Added string helper method to MurmurHash3.hash64 URL: https://github.com/apache/commons-codec/pull/33#issuecomment-561134974 ok🙆 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on issue #33: Added string helper method to MurmurHash3.hash64
aherbert commented on issue #33: Added string helper method to MurmurHash3.hash64 URL: https://github.com/apache/commons-codec/pull/33#issuecomment-561106482 I am against this: - It adds more convenience methods which do not save very much typing - It promotes the hash64 method which is not part of MurmurHash3 - It uses String::getBytes without a character encoding This method saves a few characters over the alternative: ``` String s; long h1 = MurmurHash3.hash64(s); long h2 = MurmurHash3.hash64(s.getBytes()); ``` The hash64 methods are not part of the original MurmurHash3 implementation. We do not know the statistical properties of these methods, i.e. the hash collision rate. The methods were ported from Apache Hive but the original reason for the method and its usage is unknown. The javadoc should be more clear that these methods do not return the same as either the upper of lower 64-bits of the hash128 method: ``` String s; long[] h = MurmurHash3.hash128(s.getBytes()); long h2 = MurmurHash3.hash64(s.getBytes()); // This is not true only due to random hash collision: // h[0] != h2 && h[1] != h2; ``` The main javadoc for hash64 states this but the other helper methods do not. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-imaging] kinow commented on issue #62: Add disposal method to GIF metadata
kinow commented on issue #62: Add disposal method to GIF metadata URL: https://github.com/apache/commons-imaging/pull/62#issuecomment-561097033 Hi @christoffer-rydberg I still need to read the links and the code. But from your list of options, I'd be +1 for C), and +0 for D). C would be my favourite as we would minimize changes to the API - unless there is some good reason anyway for this change, then we can discuss D too :+1: This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-imaging] christoffer-rydberg commented on issue #62: Add disposal method to GIF metadata
christoffer-rydberg commented on issue #62: Add disposal method to GIF metadata URL: https://github.com/apache/commons-imaging/pull/62#issuecomment-561063850 @kinow Any suggestions how to unit test this PR? Basically the only added logic is a private method to convert from internal gif int value to an enum. I could: A) Make it public (bad since it is only needed by the parser). B) Test it using reflection (not a fan) C) Test it indirectly by adding more test gifs with different disposal methods (need to find such gifs). D) Move the method to another class (e.g. MethodDisposalConverter) with a public testable method and inject it into the parser. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986701#comment-16986701
]
Dmitri Blinov edited comment on JEXL-307 at 12/3/19 8:37 AM:
-
Maybe I do not fully understand what the lexical feature is all about, but from
the previous test case I've learned the idea was to control the access to
undeclared local variables. If I'm right, then the following test case should
also pass, but it doesn't.
{code:java}
@Test
public void testForVariable() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
try {
JexlScript script = jexl.createScript("for(var x : 1..3) { var c =
0}; return x");
Assert.fail("Should not have been parsed");
} catch (Exception ex) {
// OK
}
}
{code}
Compare this to test case that passes correctly:
{code:java}
@Test
public void testUndeclaredVariable() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
try {
JexlScript script = jexl.createScript("{var x = 0}; return x");
Assert.fail("Should not have been parsed");
} catch (Exception ex) {
// OK
}
}
{code}
was (Author: dmitri_blinov):
Maybe I do not fully understand what the lexical feature is all about, but from
the previous test case I've learned the idea was to control the access to
undeclared local variables. If I'm right, then the following test case should
also pass, but it doesn't.
{code:java}
@Test
public void testForVariable() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
try {
JexlScript script = jexl.createScript("for(var x : 1..3) { var c =
0}; return x");
Assert.fail("Should not have been parsed");
} catch (Exception ex) {
// OK
}
}
{code}
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16986701#comment-16986701
]
Dmitri Blinov commented on JEXL-307:
Maybe I do not fully understand what the lexical feature is all about, but from
the previous test case I've learned the idea was to control the access to
undeclared local variables. If I'm right, then the following test case should
also pass, but it doesn't.
{code:java}
@Test
public void testForVariable() throws Exception {
JexlFeatures f = new JexlFeatures();
f.lexical(true);
JexlEngine jexl = new JexlBuilder().strict(true).features(f).create();
try {
JexlScript script = jexl.createScript("for(var x : 1..3) { var c =
0}; return x");
Assert.fail("Should not have been parsed");
} catch (Exception ex) {
// OK
}
}
{code}
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
