[jira] [Updated] (CODEC-213) Support JEP 287: SHA-3 Hash Algorithms

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-213:
---
Attachment: CODEC-SHA3.diff

> Support JEP 287: SHA-3 Hash Algorithms
> --
>
> Key: CODEC-213
> URL: https://issues.apache.org/jira/browse/CODEC-213
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+115)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+115, mixed mode)
>Reporter: Gary Gregory
> Attachments: CODEC-SHA3.diff
>
>
> Support JEP 287: SHA-3 Hash Algorithms: SHA3-224, SHA3-256, SHA3-384, 
> SHA3-512.



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

[jira] [Commented] (CODEC-213) Support JEP 287: SHA-3 Hash Algorithms

[Gary Gregory (JIRA)]

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

Gary Gregory commented on CODEC-213:


These do not appear to have shown up in Java 9 EA build as of 115.

> Support JEP 287: SHA-3 Hash Algorithms
> --
>
> Key: CODEC-213
> URL: https://issues.apache.org/jira/browse/CODEC-213
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: java version "9-ea"
> Java(TM) SE Runtime Environment (build 9-ea+115)
> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+115, mixed mode)
>Reporter: Gary Gregory
>
> Support JEP 287: SHA-3 Hash Algorithms: SHA3-224, SHA3-256, SHA3-384, 
> SHA3-512.



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

[jira] [Created] (CODEC-213) Support JEP 287: SHA-3 Hash Algorithms

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-213:
--

 Summary: Support JEP 287: SHA-3 Hash Algorithms
 Key: CODEC-213
 URL: https://issues.apache.org/jira/browse/CODEC-213
 Project: Commons Codec
  Issue Type: New Feature
 Environment: java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+115)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+115, mixed mode)
Reporter: Gary Gregory


Support JEP 287: SHA-3 Hash Algorithms: SHA3-224, SHA3-256, SHA3-384, SHA3-512.



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

[jira] [Updated] (CODEC-212) Create a minimal Digest command line utility: org.apache.commons.codec.digest.Digesta

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-212:
---
Description: Create a minimal Digest command line utility: 
org.apache.commons.codec.digest.Digest.  (was: Create a minimal Digest command 
line utility as a convenience.)

> Create a minimal Digest command line utility: 
> org.apache.commons.codec.digest.Digesta
> -
>
> Key: CODEC-212
> URL: https://issues.apache.org/jira/browse/CODEC-212
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Create a minimal Digest command line utility: 
> org.apache.commons.codec.digest.Digest.



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

[jira] [Updated] (CODEC-212) Create a minimal Digest command line utility: org.apache.commons.codec.digest.Digesta

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-212:
---
Summary: Create a minimal Digest command line utility: 
org.apache.commons.codec.digest.Digesta  (was: Create a minimal Digest command 
line utility)

> Create a minimal Digest command line utility: 
> org.apache.commons.codec.digest.Digesta
> -
>
> Key: CODEC-212
> URL: https://issues.apache.org/jira/browse/CODEC-212
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Create a minimal Digest command line utility as a convenience.



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

[jira] [Updated] (CODEC-212) Create a minimal Digest command line utility: org.apache.commons.codec.digest.Digest

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-212:
---
Summary: Create a minimal Digest command line utility: 
org.apache.commons.codec.digest.Digest  (was: Create a minimal Digest command 
line utility: org.apache.commons.codec.digest.Digesta)

> Create a minimal Digest command line utility: 
> org.apache.commons.codec.digest.Digest
> 
>
> Key: CODEC-212
> URL: https://issues.apache.org/jira/browse/CODEC-212
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Create a minimal Digest command line utility: 
> org.apache.commons.codec.digest.Digest.



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

[jira] [Created] (CODEC-212) Create a minimal Digest command line utility

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-212:
--

 Summary: Create a minimal Digest command line utility
 Key: CODEC-212
 URL: https://issues.apache.org/jira/browse/CODEC-212
 Project: Commons Codec
  Issue Type: New Feature
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Create a minimal Digest command line utility as a convenience.



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

[jira] [Created] (CODEC-211) Create enum MessageDigestAlgorithm and deprecate class MessageDigestAlgorithms

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-211:
--

 Summary: Create enum MessageDigestAlgorithm and deprecate class 
MessageDigestAlgorithms
 Key: CODEC-211
 URL: https://issues.apache.org/jira/browse/CODEC-211
 Project: Commons Codec
  Issue Type: New Feature
Affects Versions: 1.10
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Create enum MessageDigestAlgorithm and deprecate class MessageDigestAlgorithms.



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

[jira] [Closed] (CODEC-210) Add DigestUtils.getDigest(String, MessageDigest)

[Gary Gregory (JIRA)]

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

Gary Gregory closed CODEC-210.
--
Resolution: Fixed

In svn trunk.

> Add DigestUtils.getDigest(String, MessageDigest)
> 
>
> Key: CODEC-210
> URL: https://issues.apache.org/jira/browse/CODEC-210
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Add DigestUtils.getDigest(String algo, MessageDigest):
> {code:java}
> /**
>  * Returns a MessageDigest for the given 
> algorithm or a default if there is a problem getting the 
> algorithm.
>  *
>  * @param algorithm
>  *the name of the algorithm requested. See   *
> href="http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA;
>  *>Appendix A in the Java Cryptography Architecture Reference 
> Guide for information about standard
>  *algorithm names.
>  * @param defaultMessageDigest The default MessageDigest.
>  * @return A digest instance.
>  * @see MessageDigest#getInstance(String)
>  * @throws IllegalArgumentException
>  * when a {@link NoSuchAlgorithmException} is caught.
>  * @since 1.11
>  */
> {code}



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

[jira] [Created] (CODEC-210) Add DigestUtils.getDigest(String, MessageDigest)

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-210:
--

 Summary: Add DigestUtils.getDigest(String, MessageDigest)
 Key: CODEC-210
 URL: https://issues.apache.org/jira/browse/CODEC-210
 Project: Commons Codec
  Issue Type: New Feature
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Add DigestUtils.getDigest(String algo, MessageDigest):

{code:java}
/**
 * Returns a MessageDigest for the given 
algorithm or a default if there is a problem getting the algorithm.
 *
 * @param algorithm
 *the name of the algorithm requested. See http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html#AppA;
 *>Appendix A in the Java Cryptography Architecture Reference 
Guide for information about standard
 *algorithm names.
 * @param defaultMessageDigest The default MessageDigest.
 * @return A digest instance.
 * @see MessageDigest#getInstance(String)
 * @throws IllegalArgumentException
 * when a {@link NoSuchAlgorithmException} is caught.
 * @since 1.11
 */
{code}



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

[jira] [Closed] (CODEC-209) Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction instead of 1.4.0

[Gary Gregory (JIRA)]

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

Gary Gregory closed CODEC-209.
--
Resolution: Fixed

Committed revision 1743772.

> Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction 
> instead of 1.4.0
> --
>
> Key: CODEC-209
> URL: https://issues.apache.org/jira/browse/CODEC-209
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 restriction instead 
> of 1.4.0.



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

[jira] [Updated] (CODEC-209) Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction instead of 1.4.0

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-209:
---
Summary: Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 
restriction instead of 1.4.0  (was: Javadoc for SHA-224 DigestUtils methods 
should mention Java 1.8.0 restriction instead of 1.4.0.)

> Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction 
> instead of 1.4.0
> --
>
> Key: CODEC-209
> URL: https://issues.apache.org/jira/browse/CODEC-209
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 restriction instead 
> of 1.4.0.



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

[jira] [Updated] (CODEC-209) Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction instead of 1.4.0.

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-209:
---
Summary: Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 
restriction instead of 1.4.0.  (was: Javadoc for SHA-224 DigestUtils should 
mention Java 1.8.0 restriction instead of 1.4.0.)

> Javadoc for SHA-224 DigestUtils methods should mention Java 1.8.0 restriction 
> instead of 1.4.0.
> ---
>
> Key: CODEC-209
> URL: https://issues.apache.org/jira/browse/CODEC-209
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 restriction instead 
> of 1.4.0.



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

[jira] [Created] (CODEC-209) Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 restriction instead of 1.4.0.

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-209:
--

 Summary: Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 
restriction instead of 1.4.0.
 Key: CODEC-209
 URL: https://issues.apache.org/jira/browse/CODEC-209
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.10
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Javadoc for SHA-224 DigestUtils should mention Java 1.8.0 restriction instead 
of 1.4.0.



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

[jira] [Closed] (CODEC-208) Make some DigestUtils APIs public

[Gary Gregory (JIRA)]

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

Gary Gregory closed CODEC-208.
--
Resolution: Fixed

Committed revision 1743770.

> Make some DigestUtils APIs public
> -
>
> Key: CODEC-208
> URL: https://issues.apache.org/jira/browse/CODEC-208
> Project: Commons Codec
>  Issue Type: New Feature
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Make some DigestUtils private APIs public
> - digest(MessageDigest, ByteBuffer)
> - digest(MessageDigest, InputStream)



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

[jira] [Created] (CODEC-208) Make some DigestUtils APIs public

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-208:
--

 Summary: Make some DigestUtils APIs public
 Key: CODEC-208
 URL: https://issues.apache.org/jira/browse/CODEC-208
 Project: Commons Codec
  Issue Type: New Feature
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory


Make some DigestUtils private APIs public
- digest(MessageDigest, ByteBuffer)
- digest(MessageDigest, InputStream)



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

[jira] [Updated] (VFS-610) Resource leak in CombinedResources.loadResources(String)

[Lae (JIRA)]

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

Lae updated VFS-610:

Description: 
{{org.apache.commons.vfs2.util.CombinedResources.loadResources(String)}} 
doesn't close the streams it creates:
{code:java}
protected void loadResources(String resourceName)
{
...
properties.load(resource.openConnection().getInputStream());
...
}
{code}

  was:
{{org.apache.commons.vfs2.util.CombinedResources.loadResources(String)}} 
doesn't close the {{InputStream}}s it created:
{code:java}
protected void loadResources(String resourceName)
{
...
properties.load(resource.openConnection().getInputStream());
...
}
{code}


> Resource leak in CombinedResources.loadResources(String)
> 
>
> Key: VFS-610
> URL: https://issues.apache.org/jira/browse/VFS-610
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Lae
>
> {{org.apache.commons.vfs2.util.CombinedResources.loadResources(String)}} 
> doesn't close the streams it creates:
> {code:java}
> protected void loadResources(String resourceName)
> {
> ...
> 
> properties.load(resource.openConnection().getInputStream());
> ...
> }
> {code}



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

[jira] [Created] (VFS-610) Resource leak in CombinedResources.loadResources(String)

[Lae (JIRA)]

Lae created VFS-610:
---

 Summary: Resource leak in CombinedResources.loadResources(String)
 Key: VFS-610
 URL: https://issues.apache.org/jira/browse/VFS-610
 Project: Commons VFS
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Lae


{{org.apache.commons.vfs2.util.CombinedResources.loadResources(String)}} 
doesn't close the {{InputStream}}s it created:
{code:java}
protected void loadResources(String resourceName)
{
...
properties.load(resource.openConnection().getInputStream());
...
}
{code}



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

[jira] [Resolved] (WEAVER-10) Tests problems

[Matt Benson (JIRA)]

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

Matt Benson resolved WEAVER-10.
---
Resolution: Cannot Reproduce

> Tests problems
> --
>
> Key: WEAVER-10
> URL: https://issues.apache.org/jira/browse/WEAVER-10
> Project: Commons Weaver
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: gil cattaneo
> Attachments: build.log, root.log, xbean-4.6-SNAPSHOT-build.log
>
>
> Hi
> I'm getting (commons-weaver 1.1 and 1.2_RC1, and 1.2):
> ---
>  T E S T S
> ---
> Running org.apache.commons.weaver.test.WeaveProcessorTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.106 sec <<< 
> FAILURE! - in org.apache.commons.weaver.test.WeaveProcessorTest
> testWeaveVisiting(org.apache.commons.weaver.test.WeaveProcessorTest) Time 
> elapsed: 0.099 sec <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.commons.weaver.test.WeaveProcessorTest.testWeaveVisiting(WeaveProcessorTest.java:55)
> Running org.apache.commons.weaver.test.CleanProcessorTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec <<< 
> FAILURE! - in org.apache.commons.weaver.test.CleanProcessorTest
> testWeaveVisiting(org.apache.commons.weaver.test.CleanProcessorTest) Time 
> elapsed: 0.015 sec <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at 
> org.apache.commons.weaver.test.CleanProcessorTest.testWeaveVisiting(CleanProcessorTest.java:46)
> Running org.apache.commons.weaver.utils.ArgsTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
> org.apache.commons.weaver.utils.ArgsTest
> Running org.apache.commons.weaver.utils.ProvidersTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
> org.apache.commons.weaver.utils.ProvidersTest
> Running org.apache.commons.weaver.FinderTest
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec <<< 
> FAILURE! - in org.apache.commons.weaver.FinderTest
> testElements(org.apache.commons.weaver.FinderTest) Time elapsed: 0.008 sec 
> <<< FAILURE!
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.commons.weaver.FinderTest.testElements(FinderTest.java:75)
> Environment:
> Apache Maven 3.3.3 (NON-CANONICAL_2015-07-10T12:37:52_mockbuild; 
> 2015-07-10T14:37:52+02:00)
> Maven home: /usr/share/maven
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-13.b17.fc23.i386/jre
> Default locale: it_IT, platform encoding: UTF-8
> OS name: "linux", version: "4.2.7-300.fc23.i686", arch: "i386", family: "unix"
> Any ideas as to why? 
> what wrong on jira? I can't  insert a commet without use "Edit" button ...



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

[jira] [Closed] (CODEC-206) Add java.io.File APIs to DigestUtils

[Gary Gregory (JIRA)]

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

Gary Gregory closed CODEC-206.
--
Resolution: Fixed

In svn trunk.

> Add java.io.File APIs to DigestUtils
> 
>
> Key: CODEC-206
> URL: https://issues.apache.org/jira/browse/CODEC-206
> Project: Commons Codec
>  Issue Type: New Feature
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Add java.io.File APIs to DigestUtils.
> - md2(File)
> - md2Hex(File)
> - md5(File)
> - md5Hex(File)
> - sha1(File)
> - sha1Hex(File)
> - sha224(File)
> - sha224Hex(File)
> - sha256(File)
> - sha256Hex(File)
> - sha384(File)
> - sha384Hex(File)
> - sha512(File)
> - sha512Hex(File)
> - updateDigest(MessageDigest, File)



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

[jira] [Closed] (CODEC-207) Charsets Javadoc breaks build when using Java 8

[Gary Gregory (JIRA)]

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

Gary Gregory closed CODEC-207.
--
Resolution: Fixed

In svn trunk.

> Charsets Javadoc breaks build when using Java 8
> ---
>
> Key: CODEC-207
> URL: https://issues.apache.org/jira/browse/CODEC-207
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Some Javadocs in {{Charsets}} use a period instead of a hash to separate 
> class and field in {{@link}} references.
> Specifically:
> {noformat}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 40.598 s
> [INFO] Finished at: 2016-05-13T13:33:29-07:00
> [INFO] Final Memory: 67M/658M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
> commons-codec: Error generating maven-javadoc-plugin:2.10.3:javadoc:
> [ERROR] Exit code: 1 - 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:96:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.ISO_8859_1} instead
> [ERROR] ^
> [ERROR] 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:107:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.US_ASCII} instead
> [ERROR] ^
> [ERROR] 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:119:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.UTF_16} instead
> [ERROR] ^
> [ERROR] 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:130:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.UTF_16BE} instead
> [ERROR] ^
> [ERROR] 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:141:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.UTF_16LE} instead
> [ERROR] ^
> [ERROR] 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:152:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.UTF_8}
> [ERROR] ^
> [ERROR]
> [ERROR] Command line was: "C:\Program 
> Files\Java\jdk1.8.0_91\jre\..\bin\javadoc.exe" @options @packages
> [ERROR]
> [ERROR] Refer to the generated Javadoc files in 
> 'E:\vcs\svn\apache\commons\trunks-proper\codec\target\site\apidocs' dir.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> {noformat}



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

[jira] [Updated] (CODEC-207) Charsets Javadoc breaks build when using Java 8

[Gary Gregory (JIRA)]

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

Gary Gregory updated CODEC-207:
---
Description: 
Some Javadocs in {{Charsets}} use a period instead of a hash to separate class 
and field in {{@link}} references.

Specifically:

{noformat}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 40.598 s
[INFO] Finished at: 2016-05-13T13:33:29-07:00
[INFO] Final Memory: 67M/658M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
commons-codec: Error generating maven-javadoc-plugin:2.10.3:javadoc:
[ERROR] Exit code: 1 - 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:96:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.ISO_8859_1} instead
[ERROR] ^
[ERROR] 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:107:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.US_ASCII} instead
[ERROR] ^
[ERROR] 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:119:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.UTF_16} instead
[ERROR] ^
[ERROR] 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:130:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.UTF_16BE} instead
[ERROR] ^
[ERROR] 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:141:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.UTF_16LE} instead
[ERROR] ^
[ERROR] 
E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:152:
 error: reference not found
[ERROR] * @deprecated Use Java 7's {@link 
java.nio.charset.StandardCharsets.UTF_8}
[ERROR] ^
[ERROR]
[ERROR] Command line was: "C:\Program 
Files\Java\jdk1.8.0_91\jre\..\bin\javadoc.exe" @options @packages
[ERROR]
[ERROR] Refer to the generated Javadoc files in 
'E:\vcs\svn\apache\commons\trunks-proper\codec\target\site\apidocs' dir.
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

  was:Some Javadocs in {{Charsets}} use a period instead of a hash to separate 
class and field in {{@link}} references.


> Charsets Javadoc breaks build when using Java 8
> ---
>
> Key: CODEC-207
> URL: https://issues.apache.org/jira/browse/CODEC-207
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.11
>
>
> Some Javadocs in {{Charsets}} use a period instead of a hash to separate 
> class and field in {{@link}} references.
> Specifically:
> {noformat}
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 40.598 s
> [INFO] Finished at: 2016-05-13T13:33:29-07:00
> [INFO] Final Memory: 67M/658M
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on project 
> commons-codec: Error generating maven-javadoc-plugin:2.10.3:javadoc:
> [ERROR] Exit code: 1 - 
> E:\vcs\svn\apache\commons\trunks-proper\codec\src\main\java\org\apache\commons\codec\Charsets.java:96:
>  error: reference not found
> [ERROR] * @deprecated Use Java 7's {@link 
> java.nio.charset.StandardCharsets.ISO_8859_1} instead
> [ERROR] ^
> [ERROR] 
> 

[jira] [Created] (CODEC-207) Charsets Javadoc breaks build when using Java 8

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-207:
--

 Summary: Charsets Javadoc breaks build when using Java 8
 Key: CODEC-207
 URL: https://issues.apache.org/jira/browse/CODEC-207
 Project: Commons Codec
  Issue Type: Bug
Affects Versions: 1.10
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.8.0_91, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_91\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Some Javadocs in {{Charsets}} use a period instead of a hash to separate class 
and field in {{@link}} references.



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

[jira] [Created] (CODEC-206) Add java.io.File APIs to DigestUtils

[Gary Gregory (JIRA)]

Gary Gregory created CODEC-206:
--

 Summary: Add java.io.File APIs to DigestUtils
 Key: CODEC-206
 URL: https://issues.apache.org/jira/browse/CODEC-206
 Project: Commons Codec
  Issue Type: New Feature
Affects Versions: 1.10
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9\bin\..
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Gary Gregory
Assignee: Gary Gregory
 Fix For: 1.11


Add java.io.File APIs to DigestUtils.

- md2(File)
- md2Hex(File)
- md5(File)
- md5Hex(File)
- sha1(File)
- sha1Hex(File)
- sha224(File)
- sha224Hex(File)
- sha256(File)
- sha256Hex(File)
- sha384(File)
- sha384Hex(File)
- sha512(File)
- sha512Hex(File)
- updateDigest(MessageDigest, File)




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

[jira] [Commented] (MATH-1341) "RandomDataGenerator" is brittle

[Luc Maisonobe (JIRA)]

[ 
https://issues.apache.org/jira/browse/MATH-1341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282935#comment-15282935
 ] 

Luc Maisonobe commented on MATH-1341:
-

Seems good to me.

> "RandomDataGenerator" is brittle
> 
>
> Key: MATH-1341
> URL: https://issues.apache.org/jira/browse/MATH-1341
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
>  Labels: API, cleanup, deprecation, thread-safety
> Fix For: 4.0
>
> Attachments: RandomUtils.java
>
>
> Class {{RandomDataGenerator}} can easily be misused as it advertizes a method 
> to access its internal RNG (which is _not_ thread-safe).
> The class is also a mixed bag of "data generators" that are either "secure" 
> or not.
> Moreover it uses the "lazy initialization" pattern (for the RNG instance) 
> solely because of this duality; otherwise users that need one or the other 
> form of data generation will obviously always use the RNG since all data 
> generation methods need it.
> This entails also a performance hit (albeit tiny) as each call checks whether 
> the RNG has been initialized already.
> The clean solution would be to separate the two types of data generation 
> (secure vs not) into different classes.



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

[jira] [Commented] (JEXL-194) synchronize on iterableValue in foreach statement

[Dmitri Blinov (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282778#comment-15282778
 ] 

Dmitri Blinov commented on JEXL-194:


Thanks for the hint, I'll give it a try

> synchronize on iterableValue in foreach statement
> -
>
> Key: JEXL-194
> URL: https://issues.apache.org/jira/browse/JEXL-194
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> Since it is a requirement to synchronize on simple Collections and 
> synchronized Collections while iterating over them and since jexl has no 
> instrument to control synchronization in script, I think its reasonable to 
> implement synchronization in jexl itself on iterableValue. In case of 
> concurrent collections it will possibly block other threads only if they are 
> synchronizing on those collections themselves, which will be complementary to 
> required synchronization in jexl.



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

[jira] [Commented] (WEAVER-10) Tests problems

[gil cattaneo (JIRA)]

[ 
https://issues.apache.org/jira/browse/WEAVER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282694#comment-15282694
 ] 

gil cattaneo commented on WEAVER-10:


Hi
Thanks, fixed.
The problem is caused by our  xbean (Fedora packaging gudeline until a short 
time ago not allow shade/bundle libraries) customization. After enable 
xbean-asm-util  module this issues disappear
One less problem to figure out things that cause 
https://issues.apache.org/jira/browse/BVAL-142
Again thanks


> Tests problems
> --
>
> Key: WEAVER-10
> URL: https://issues.apache.org/jira/browse/WEAVER-10
> Project: Commons Weaver
>  Issue Type: Bug
>Affects Versions: 1.2
>Reporter: gil cattaneo
> Attachments: build.log, root.log, xbean-4.6-SNAPSHOT-build.log
>
>
> Hi
> I'm getting (commons-weaver 1.1 and 1.2_RC1, and 1.2):
> ---
>  T E S T S
> ---
> Running org.apache.commons.weaver.test.WeaveProcessorTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.106 sec <<< 
> FAILURE! - in org.apache.commons.weaver.test.WeaveProcessorTest
> testWeaveVisiting(org.apache.commons.weaver.test.WeaveProcessorTest) Time 
> elapsed: 0.099 sec <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.commons.weaver.test.WeaveProcessorTest.testWeaveVisiting(WeaveProcessorTest.java:55)
> Running org.apache.commons.weaver.test.CleanProcessorTest
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec <<< 
> FAILURE! - in org.apache.commons.weaver.test.CleanProcessorTest
> testWeaveVisiting(org.apache.commons.weaver.test.CleanProcessorTest) Time 
> elapsed: 0.015 sec <<< FAILURE!
> java.lang.AssertionError: null
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertFalse(Assert.java:64)
> at org.junit.Assert.assertFalse(Assert.java:74)
> at 
> org.apache.commons.weaver.test.CleanProcessorTest.testWeaveVisiting(CleanProcessorTest.java:46)
> Running org.apache.commons.weaver.utils.ArgsTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
> org.apache.commons.weaver.utils.ArgsTest
> Running org.apache.commons.weaver.utils.ProvidersTest
> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec - in 
> org.apache.commons.weaver.utils.ProvidersTest
> Running org.apache.commons.weaver.FinderTest
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec <<< 
> FAILURE! - in org.apache.commons.weaver.FinderTest
> testElements(org.apache.commons.weaver.FinderTest) Time elapsed: 0.008 sec 
> <<< FAILURE!
> java.lang.AssertionError: expected:<2> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.commons.weaver.FinderTest.testElements(FinderTest.java:75)
> Environment:
> Apache Maven 3.3.3 (NON-CANONICAL_2015-07-10T12:37:52_mockbuild; 
> 2015-07-10T14:37:52+02:00)
> Maven home: /usr/share/maven
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-13.b17.fc23.i386/jre
> Default locale: it_IT, platform encoding: UTF-8
> OS name: "linux", version: "4.2.7-300.fc23.i686", arch: "i386", family: "unix"
> Any ideas as to why? 
> what wrong on jira? I can't  insert a commet without use "Edit" button ...



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

[jira] [Updated] (MATH-1341) "RandomDataGenerator" is brittle

[Gilles (JIRA)]

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

Gilles updated MATH-1341:
-
Attachment: RandomUtils.java

I attached a new {{RandomUtils}} class which I propose as a replacement for 
{{RandomDataGenerator}}.

Having removed all methods that are _trivial_ syntactic sugar for the sampler 
API in {{o.a.c.m.distribution}}, the number of lines in {{RandomUtils}} is ~60% 
of the old {{RandomDataGenerator}}.

The "nextSecureXxx" methods were also removed as most were identical to their 
"non-secure" counterpart, except for the underlying RNG (secure vs not). In 
{{RandomUtils}}, secure versions are thus "automatically" achieved by passing a 
secure RNG to the class's constructor.

Methods {{nextHexString}} and {{nextSecureHexString}} were different in that 
the latter uses a {{MessageDigest}} object in its processing.
The two codes were merged in a single method and a boolean argument selects one 
or the other behaviour.

{{RandomUtils}} also obsoletes class {{RandomGeneratorFactory}} whose 
functionality is replaced by the following factory method:
{noformat}
public static UniformRandomProvider asUniformRandomProvider(final Random rng) {
  // 
}
{noformat}

Old "features" intentionally left out:
* Lazy initialization (if you don't need the RNG, you don't need an instance of 
this class)
* Reseeding of the RNG (if necessary - although a bad idea - the caller can 
hold a reference to the {{Random}} object being wrapped, and call "setSeed" on 
it)


Please have a look, and let me know of any functionality I may have missed to 
port to the new class.


> "RandomDataGenerator" is brittle
> 
>
> Key: MATH-1341
> URL: https://issues.apache.org/jira/browse/MATH-1341
> Project: Commons Math
>  Issue Type: Bug
>Reporter: Gilles
>Priority: Minor
>  Labels: API, cleanup, deprecation, thread-safety
> Fix For: 4.0
>
> Attachments: RandomUtils.java
>
>
> Class {{RandomDataGenerator}} can easily be misused as it advertizes a method 
> to access its internal RNG (which is _not_ thread-safe).
> The class is also a mixed bag of "data generators" that are either "secure" 
> or not.
> Moreover it uses the "lazy initialization" pattern (for the RNG instance) 
> solely because of this duality; otherwise users that need one or the other 
> form of data generation will obviously always use the RNG since all data 
> generation methods need it.
> This entails also a performance hit (albeit tiny) as each call checks whether 
> the RNG has been initialized already.
> The clean solution would be to separate the two types of data generation 
> (secure vs not) into different classes.



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

[GitHub] commons-lang pull request: Lang 1195: Enhance MethodUtils to allow...

[Derek-Ashmore]

Github user Derek-Ashmore commented on the pull request:

https://github.com/apache/commons-lang/pull/141#issuecomment-219016359
  
Thanks for taking time to respond.  I should be challenged on the need 
for this.  I grant your point-- over-exposing methods is technically 
possible.  I've issues with that, however.

 From an design perspective, you should only expose fields (through 
accessors/mutators) and methods you intend to expose.  That is, that are 
being made available for use by other classes or by inheritance. 
Over-exposing methods and fields in the way you describe violates OO 
design principles.  Creating an easy way for test code to access 
privates is less of a principle breach; test classes presumably know 
exactly how a class is supposed to operate and are tightly coupled to 
that class anyway.

Why create FieldUtils?  That logic should also have been used to not 
implement the methods on FieldUtils that allow you to manipulate private 
fields. Doesn't that run into the same issue?

I don't like over-exposing fields and methods just to be able to cover 
them in testing.  I'm not alone.

Thanks for taking a look at this request and taking time to comment.  
Thanks, also, for the most interesting discussion.
Derek  
 
Please note that my email address has changed to 
derek.ashm...@dvtconsulting.com
On 5/13/2016 5:23 AM, sebbASF wrote:
>
> Note that an alternative solution for testing private methods is to 
> make them package-protected.
> (and document why they are not private!)
>
> The test code needs to access it from the same package, but that is 
> not usually a problem.
> If necessary create a public method in the same package which can be 
> used by all the test code.
> A similar approach can be used for private fields; create a 
> package-protected getter.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly or view it on GitHub 
> 
>




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

[GitHub] commons-lang pull request: Lang 1195: Enhance MethodUtils to allow...

[sebbASF]

Github user sebbASF commented on the pull request:

https://github.com/apache/commons-lang/pull/141#issuecomment-219006770
  
Note that an alternative solution for testing private methods is to make 
them package-protected.
(and document why they are not private!)

The test code needs to access it from the same package, but that is not 
usually a problem.
If necessary create a public method in the same package which can be used 
by all the test code.
A similar approach can be used for private fields; create a 
package-protected getter.


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

[GitHub] commons-lang pull request: Lang 1195: Enhance MethodUtils to allow...

[Derek-Ashmore]

GitHub user Derek-Ashmore opened a pull request:

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

Lang 1195: Enhance MethodUtils to allow invocation of private methods

Currently, MethodUtils is restricted to finding and invoking accessible 
methods. Frequently, developers have a need to test 'private' methods. What I 
see is that they escalate access to 'protected' in order to more easily provide 
test coverage for these methods. From a design perspective, this is bad.

I propose to enhance MethodUtils so that it can easily invoke private 
methods. I'm not suggesting that developers should do this in production code, 
merely test code. Much as FieldUtils provides access to private fields via the 
'forceAccess' overload on many of its methods. I've copied a utility like this 
around for years. It would be much more convenient to simply include it with 
Commons Lang. See [LANG-1195](https://issues.apache.org/jira/browse/LANG-1195) 
for details.

I made sure that I used space indentation and tried to adhere closely to 
your standards.  I've also signed the Contributor License Agreement.

Assuming you like the enhancement, I'm willing to contribute additional 
work if you see issues with what I've done.

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

$ git pull https://github.com/Force66/commons-lang LANG-1195

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

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

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

This closes #141


commit f53fb65535232962ccd35ba9ad66e2e4c248f92e
Author: Derek Ashmore 
Date:   2016-01-01T14:31:47Z

See LANG-1195; Enhance MethodUtils to allow invocation of private
methods

commit 4a256e62529fbc57dfb55a99e222ec3591cee7ec
Author: Derek Ashmore 
Date:   2016-05-13T09:42:32Z

See LANG-1195; Removed accidental tab indentation




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

[jira] [Commented] (JEXL-194) synchronize on iterableValue in foreach statement

[Henri Biestro (JIRA)]

[ 
https://issues.apache.org/jira/browse/JEXL-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282561#comment-15282561
 ] 

Henri Biestro commented on JEXL-194:


As a temporary workaround, you already can run code under a 'synchronized' 
monitor as in :
{code}

public static class Synchronizer extends MapContext {
private final JexlContext context;

public Synchronizer(JexlContext ctxt) {
this.context =  ctxt;
}
public Object call(Object var, JexlScript script) {
String[] parms = script.getParameters();
boolean varisarg = parms != null && parms.length == 1;
if (var == null) {
return varisarg? script.execute(context, var) : 
script.execute(context);
} else {
synchronized (var) {
return varisarg? script.execute(context, var) : 
script.execute(context);
}
}
}
}

@Test
public void test196() throws Exception {
Map ns = new TreeMap();
ns.put("synchronized", Synchronizer.class);
JexlContext jc = new MapContext();
JexlEngine jexl = new JexlBuilder().namespaces(ns).create();
JexlScript js0 = jexl.createScript("synchronized:call(x, 
(y)->{y.size()})", "x");
Object size = js0.execute(jc, "foobar");
Assert.assertEquals(6, size);
}
{code}

> synchronize on iterableValue in foreach statement
> -
>
> Key: JEXL-194
> URL: https://issues.apache.org/jira/browse/JEXL-194
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> Since it is a requirement to synchronize on simple Collections and 
> synchronized Collections while iterating over them and since jexl has no 
> instrument to control synchronization in script, I think its reasonable to 
> implement synchronization in jexl itself on iterableValue. In case of 
> concurrent collections it will possibly block other threads only if they are 
> synchronizing on those collections themselves, which will be complementary to 
> required synchronization in jexl.



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