[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639023#comment-16639023
]
Gilles commented on RNG-57:
---
Nit about PR 11: No need to insert paragraph formatting tags (...) in
the Javadoc; in particular for private fields or methods (that won't appear in
the generated doc for the web site). IMO, the tags are visual noise that makes
it more difficult to read the source file.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CRYPTO-142) Native library does not load if ENGINE_load_rdrand is not available
[
https://issues.apache.org/jira/browse/CRYPTO-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638996#comment-16638996
]
Marcelo Vanzin commented on CRYPTO-142:
---
It seems that things are already reasonably separate, and just the
{{OpenSslCryptoRandomNative.initSR}} fails in that build image. We could just
disable these tests based on some build-time flag so we could have OS X in the
CI matrix.
> Native library does not load if ENGINE_load_rdrand is not available
> ---
>
> Key: CRYPTO-142
> URL: https://issues.apache.org/jira/browse/CRYPTO-142
> Project: Commons Crypto
> Issue Type: Bug
> Components: Native
>Affects Versions: 1.0.0
>Reporter: Marcelo Vanzin
>Priority: Major
>
> Found this when running tests on Travis:
> {noformat}
> java.security.GeneralSecurityException: CryptoRandom:
> [org.apache.commons.crypto.random.OpenSslCryptoRandom] failed with
> java.lang.reflect.InvocationTargetException
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
> Caused by: java.lang.RuntimeException:
> java.lang.reflect.InvocationTargetException
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
> Caused by: java.lang.reflect.InvocationTargetException
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
> Caused by: java.security.GeneralSecurityException: Native library could not
> be initialised
> at
> org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
> Caused by: java.lang.UnsatisfiedLinkError: ENGINE_load_rdrand
> {noformat}
> It seems that the OpenSSL library available on the build machine does not
> have that function. It would be nice to allow the rest of the native code
> (e.g. the ciphers) to still work in that situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638968#comment-16638968
]
Gilles commented on RNG-57:
---
bq. when master has moved on
Please review the changes made for RNG-58.
All tests pass, but there isn't any actual state yet other than at the bottom
of the hierarchy...
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-58) Allow part of the RNG state to be stored in base classes of the hierarchy
[ https://issues.apache.org/jira/browse/RNG-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638963#comment-16638963 ] Gilles commented on RNG-58: --- Commit 65abc5dcfe4198b4244d4083d790ea870edbebe5 adds the required functionality. > Allow part of the RNG state to be stored in base classes of the hierarchy > -- > > Key: RNG-58 > URL: https://issues.apache.org/jira/browse/RNG-58 > Project: Commons RNG > Issue Type: Sub-task > Components: core >Affects Versions: 1.0, 1.1 >Reporter: Gilles >Assignee: Gilles >Priority: Major > Labels: inheritance > Fix For: 1.2 > > > In order to allow caching to be implemented higher up in the hierarchy, the > save/restore functionality must be refactored so that part of the state can > be stored in base classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RNG-58) Allow part of the RNG state to be stored in base classes of the hierarchy
Gilles created RNG-58: - Summary: Allow part of the RNG state to be stored in base classes of the hierarchy Key: RNG-58 URL: https://issues.apache.org/jira/browse/RNG-58 Project: Commons RNG Issue Type: Sub-task Components: core Affects Versions: 1.1, 1.0 Reporter: Gilles Assignee: Gilles Fix For: 1.2 In order to allow caching to be implemented higher up in the hierarchy, the save/restore functionality must be refactored so that part of the state can be stored in base classes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-715) PropertiesConfiguration should not trim whitespace from the property value
[
https://issues.apache.org/jira/browse/CONFIGURATION-715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638820#comment-16638820
]
Patrick Schmidt commented on CONFIGURATION-715:
---
I created a [pull
request|https://github.com/apache/commons-configuration/pull/14] for the user's
guide and an incomplete Javadoc on JupIOFactory that I missed. For the
contributors section just take the name and email address from my commit.
> PropertiesConfiguration should not trim whitespace from the property value
> --
>
> Key: CONFIGURATION-715
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-715
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Patrick Schmidt
>Priority: Major
>
> Currently, PropertiesConfiguration will trim all trailing whitespace from
> property values. This is different from how java.util.Properties behaves. The
> Javadoc explicitly states
> {code:java}
> All remaining characters on the line become part of the associated element
> string{code}
> The responsible code is in the method _readProperty()_ of _PropertiesReader_.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-726) Add support for Commons Text 1.5 new string lookups as default lookups
[
https://issues.apache.org/jira/browse/CONFIGURATION-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CONFIGURATION-726.
--
Resolution: Fixed
In svn trunk.
> Add support for Commons Text 1.5 new string lookups as default lookups
> --
>
> Key: CONFIGURATION-726
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-726
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Interpolation
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Since we depend on Apache Commons Text for string lookups, add support for
> Commons Text 1.5's new string lookup as default lookups.
> Provides access to lookups defined in Apache Commons Text:
> * "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
> * "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
> * "date" for the {{DateStringLookup}}.
> * "env" for the {{EnvironmentVariableStringLookup}}.
> * "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
> * "java" for the {{JavaPlatformStringLookup}}.
> * "localhost" for the {{LocalHostStringLookup}}, see
> {{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
> * "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
> 1.5.
> * "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache
> Commons Text 1.5.
> * "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
> * "sys" for the {{SystemPropertyStringLookup}}.
> * "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
> * "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CONFIGURATION-726) Add support for Commons Text 1.5 new string lookups as default lookups
[
https://issues.apache.org/jira/browse/CONFIGURATION-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-726:
---
Description:
Since we depend on Apache Commons Text for string lookups, add support for
Commons Text 1.5's new string lookup as default lookups.
Provides access to lookups defined in Apache Commons Text:
* "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
* "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
* "date" for the {{DateStringLookup}}.
* "env" for the {{EnvironmentVariableStringLookup}}.
* "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
* "java" for the {{JavaPlatformStringLookup}}.
* "localhost" for the {{LocalHostStringLookup}}, see
{{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
* "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
1.5.
* "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache Commons
Text 1.5.
* "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
* "sys" for the {{SystemPropertyStringLookup}}.
* "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
* "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
was:
Since we depend on Apache Commons Text for string lookups, add support for
Commons Text 1.5's new string lookup as default lookups.
Provides access to lookups defined in Apache Commons Text:
* "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
* "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
* "date" for the {{DateStringLookup}}.
* "env" for the {{EnvironmentVariableStringLookup}}.
* "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
* "java" for the {{JavaPlatformStringLookup}}.
* "localhost" for the {{LocalHostStringLookup}}, see
{{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
* "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
1.5.
* "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache Commons
Text 1.5.
* "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
* "sys" for the {{SystemPropertyStringLookup}}.
* "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
* "urlEncode" for the {{UrlEncoderStringLookup}} since Apache Commons Text 1.6.
* "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
> Add support for Commons Text 1.5 new string lookups as default lookups
> --
>
> Key: CONFIGURATION-726
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-726
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Interpolation
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Since we depend on Apache Commons Text for string lookups, add support for
> Commons Text 1.5's new string lookup as default lookups.
> Provides access to lookups defined in Apache Commons Text:
> * "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
> * "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
> * "date" for the {{DateStringLookup}}.
> * "env" for the {{EnvironmentVariableStringLookup}}.
> * "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
> * "java" for the {{JavaPlatformStringLookup}}.
> * "localhost" for the {{LocalHostStringLookup}}, see
> {{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
> * "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
> 1.5.
> * "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache
> Commons Text 1.5.
> * "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
> * "sys" for the {{SystemPropertyStringLookup}}.
> * "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
> * "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CONFIGURATION-726) Add support for Commons Text 1.5 new string lookups as default lookups
[
https://issues.apache.org/jira/browse/CONFIGURATION-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-726:
---
Description:
Since we depend on Apache Commons Text for string lookups, add support for
Commons Text 1.5's new string lookup as default lookups.
Provides access to lookups defined in Apache Commons Text:
* "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
* "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
* "date" for the {{DateStringLookup}}.
* "env" for the {{EnvironmentVariableStringLookup}}.
* "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
* "java" for the {{JavaPlatformStringLookup}}.
* "localhost" for the {{LocalHostStringLookup}}, see
{{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
* "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
1.5.
* "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache Commons
Text 1.5.
* "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
* "sys" for the {{SystemPropertyStringLookup}}.
* "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
* "urlEncode" for the {{UrlEncoderStringLookup}} since Apache Commons Text 1.6.
* "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
was:Since we depend on Apache Commons Text for string lookups, add support
for Commons Text 1.5's new string lookup as default lookups.
> Add support for Commons Text 1.5 new string lookups as default lookups
> --
>
> Key: CONFIGURATION-726
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-726
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Interpolation
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Since we depend on Apache Commons Text for string lookups, add support for
> Commons Text 1.5's new string lookup as default lookups.
> Provides access to lookups defined in Apache Commons Text:
> * "base64" for the {{Base64StringLookup}} since Apache Commons Text 1.5.
> * "const" for the {{ConstantStringLookup}} since Apache Commons Text 1.5.
> * "date" for the {{DateStringLookup}}.
> * "env" for the {{EnvironmentVariableStringLookup}}.
> * "file" for the {{FileStringLookup}} since Apache Commons Text 1.5.
> * "java" for the {{JavaPlatformStringLookup}}.
> * "localhost" for the {{LocalHostStringLookup}}, see
> {{#localHostStringLookup()}} for key names; since Apache Commons Text 1.3.
> * "properties" for the {{PropertiesStringLookup}} since Apache Commons Text
> 1.5.
> * "resourceBundle" for the {{ResourceBundleStringLookup}} since Apache
> Commons Text 1.5.
> * "script" for the {{ScriptStringLookup}} since Apache Commons Text 1.5.
> * "sys" for the {{SystemPropertyStringLookup}}.
> * "url" for the {{UrlStringLookup}} since Apache Commons Text 1.5.
> * "urlEncode" for the {{UrlEncoderStringLookup}} since Apache Commons Text
> 1.6.
> * "xml" for the {{XmlStringLookup}} since Apache Commons Text 1.5.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TEXT-146) org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup() should reuse a singleton instance
[
https://issues.apache.org/jira/browse/TEXT-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed TEXT-146.
-
Resolution: Fixed
> org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup()
> should reuse a singleton instance
> ---
>
> Key: TEXT-146
> URL: https://issues.apache.org/jira/browse/TEXT-146
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.6
>
>
> The factory method
> {{org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup()}}
> should reuse a singleton instance instead of creating a new instance on each
> call.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TEXT-146) org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup() should reuse a singleton instance
Gary Gregory created TEXT-146:
-
Summary:
org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup()
should reuse a singleton instance
Key: TEXT-146
URL: https://issues.apache.org/jira/browse/TEXT-146
Project: Commons Text
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 1.6
The factory method
{{org.apache.commons.text.lookup.StringLookupFactory.interpolatorStringLookup()}}
should reuse a singleton instance instead of creating a new instance on each
call.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (TEXT-145) Add StringLookupFactory methods for the URL encoder and decoder string lookups.
[
https://issues.apache.org/jira/browse/TEXT-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed TEXT-145.
-
Resolution: Fixed
In git master.
> Add StringLookupFactory methods for the URL encoder and decoder string
> lookups.
> ---
>
> Key: TEXT-145
> URL: https://issues.apache.org/jira/browse/TEXT-145
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.6
>
>
> Add StringLookupFactory methods for the URL encoder and decoder string
> lookups:
> -
> {{org.apache.commons.text.lookup.StringLookupFactory.*urlDecoderStringLookup()*}}
> -
> {{org.apache.commons.text.lookup.StringLookupFactory.*urlEncoderStringLookup()*}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TEXT-145) Add StringLookupFactory methods for the URL encoder and decoder string lookups.
[
https://issues.apache.org/jira/browse/TEXT-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated TEXT-145:
--
Description:
Add StringLookupFactory methods for the URL encoder and decoder string lookups:
-
{{org.apache.commons.text.lookup.StringLookupFactory.*urlDecoderStringLookup()*}}
-
{{org.apache.commons.text.lookup.StringLookupFactory.*urlEncoderStringLookup()*}}
was:Add StringLookupFactory methods for the URL encoder and decoder string
lookups.
> Add StringLookupFactory methods for the URL encoder and decoder string
> lookups.
> ---
>
> Key: TEXT-145
> URL: https://issues.apache.org/jira/browse/TEXT-145
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 1.6
>
>
> Add StringLookupFactory methods for the URL encoder and decoder string
> lookups:
> -
> {{org.apache.commons.text.lookup.StringLookupFactory.*urlDecoderStringLookup()*}}
> -
> {{org.apache.commons.text.lookup.StringLookupFactory.*urlEncoderStringLookup()*}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TEXT-145) Add StringLookupFactory methods for the URL encoder and decoder string lookups.
Gary Gregory created TEXT-145: - Summary: Add StringLookupFactory methods for the URL encoder and decoder string lookups. Key: TEXT-145 URL: https://issues.apache.org/jira/browse/TEXT-145 Project: Commons Text Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 1.6 Add StringLookupFactory methods for the URL encoder and decoder string lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TEXT-144) Add the resource string bundle string lookup to the default set of lookups
Gary Gregory created TEXT-144: - Summary: Add the resource string bundle string lookup to the default set of lookups Key: TEXT-144 URL: https://issues.apache.org/jira/browse/TEXT-144 Project: Commons Text Issue Type: Improvement Affects Versions: 1.5 Reporter: Gary Gregory Assignee: Gary Gregory Add the resource string bundle string lookup to the default set of lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TEXT-144) Add the resource string bundle string lookup to the default set of lookups
[ https://issues.apache.org/jira/browse/TEXT-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed TEXT-144. - Resolution: Fixed Fix Version/s: 1.6 In git master. > Add the resource string bundle string lookup to the default set of lookups > -- > > Key: TEXT-144 > URL: https://issues.apache.org/jira/browse/TEXT-144 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.5 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.6 > > > Add the resource string bundle string lookup to the default set of lookups. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TEXT-135) Add a script string lookup
[ https://issues.apache.org/jira/browse/TEXT-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated TEXT-135: -- Fix Version/s: (was: 1.5) 1.6 > Add a script string lookup > -- > > Key: TEXT-135 > URL: https://issues.apache.org/jira/browse/TEXT-135 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.6 > > > Add a script file string lookup. > Example key: "javascript:\"Hello World!\"" > The lookup key is "script". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TEXT-134) Add a Properties file string lookup
[ https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated TEXT-134: -- Fix Version/s: (was: 1.5) 1.6 > Add a Properties file string lookup > --- > > Key: TEXT-134 > URL: https://issues.apache.org/jira/browse/TEXT-134 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.6 > > > Add a Properties file String Lookup to look up the value for a given key in > the format "Document:Key". > For example: "com/domain/document.properties::key". > Note the use of the separator "::" instead of ":" to allow for path > containing ":" like "C:\path\to\file.properties". > The lookup key is "properties". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638676#comment-16638676 ] Allon Mureinik commented on SCXML-283: -- I've proposed [https://github.com/apache/commons-scxml/pull/3] to handle this upgrade. > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Priority: Minor > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SCXML-283) Upgrade testing framework to JUnit Jupiter
[ https://issues.apache.org/jira/browse/SCXML-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638675#comment-16638675 ] ASF GitHub Bot commented on SCXML-283: -- Github user mureinik commented on the issue: https://github.com/apache/commons-scxml/pull/3 @woonsan I've opened https://issues.apache.org/jira/browse/SCXML-283 for this task and updated the PR's message as well as the individual commit messages accordingly. > Upgrade testing framework to JUnit Jupiter > -- > > Key: SCXML-283 > URL: https://issues.apache.org/jira/browse/SCXML-283 > Project: Commons SCXML > Issue Type: Task >Reporter: Allon Mureinik >Priority: Minor > > commons-scxml already requires Java 8, so there's nothing inhibiting the > upgrade to a modern JUnit version, and taking advantage of Jupiter's newer > features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-scxml issue #3: SCXML-283 Upgrade to JUnit jupiter
Github user mureinik commented on the issue: https://github.com/apache/commons-scxml/pull/3 @woonsan I've opened https://issues.apache.org/jira/browse/SCXML-283 for this task and updated the PR's message as well as the individual commit messages accordingly. ---
[jira] [Created] (SCXML-283) Upgrade testing framework to JUnit Jupiter
Allon Mureinik created SCXML-283: Summary: Upgrade testing framework to JUnit Jupiter Key: SCXML-283 URL: https://issues.apache.org/jira/browse/SCXML-283 Project: Commons SCXML Issue Type: Task Reporter: Allon Mureinik commons-scxml already requires Java 8, so there's nothing inhibiting the upgrade to a modern JUnit version, and taking advantage of Jupiter's newer features. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-scxml issue #3: Upgrade to JUnit jupiter
Github user mureinik commented on the issue: https://github.com/apache/commons-scxml/pull/3 @woonsan Will do, and I'll update the PR with its details once its done ---
[jira] [Updated] (CONFIGURATION-726) Add support for Commons Text 1.5 new string lookups as default lookups
[
https://issues.apache.org/jira/browse/CONFIGURATION-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CONFIGURATION-726:
---
Description: Since we depend on Apache Commons Text for string lookups, add
support for Commons Text 1.5's new string lookup as default lookups. (was:
Since we depend on Apache Commons Text for string lookups, add support for
Commons Text 1.4's {{localhost}} string lookup as a default lookup.
I anticipate that once Commons Text 1.5 is released, Commons Configuration will
be updated again to support the new string lookups from Commons Text 1.5.)
> Add support for Commons Text 1.5 new string lookups as default lookups
> --
>
> Key: CONFIGURATION-726
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-726
> Project: Commons Configuration
> Issue Type: Improvement
> Components: Interpolation
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Since we depend on Apache Commons Text for string lookups, add support for
> Commons Text 1.5's new string lookup as default lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CONFIGURATION-726) Add support for Commons Text 1.5 new string lookups as default lookups
Gary Gregory created CONFIGURATION-726:
--
Summary: Add support for Commons Text 1.5 new string lookups as
default lookups
Key: CONFIGURATION-726
URL: https://issues.apache.org/jira/browse/CONFIGURATION-726
Project: Commons Configuration
Issue Type: Improvement
Components: Interpolation
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.4
Since we depend on Apache Commons Text for string lookups, add support for
Commons Text 1.4's {{localhost}} string lookup as a default lookup.
I anticipate that once Commons Text 1.5 is released, Commons Configuration will
be updated again to support the new string lookups from Commons Text 1.5.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-720) Replace use of deprecated Commons Lang string substitution code for Commons Text
[ https://issues.apache.org/jira/browse/CONFIGURATION-720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-720. -- Resolution: Fixed In git master. > Replace use of deprecated Commons Lang string substitution code for Commons > Text > > > Key: CONFIGURATION-720 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-720 > Project: Commons Configuration > Issue Type: Improvement > Components: Interpolation >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > > Replace use of deprecated Commons Lang string substitution code for Commons > Text. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (CONFIGURATION-725) Update Apache Commons Text from 1.4 to 1.5
[ https://issues.apache.org/jira/browse/CONFIGURATION-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-725. -- Resolution: Fixed Fix Version/s: 2.4 In git master. > Update Apache Commons Text from 1.4 to 1.5 > -- > > Key: CONFIGURATION-725 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-725 > Project: Commons Configuration > Issue Type: Improvement > Components: Interpolation >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.4 > > > Update Apache Commons Text from 1.4 to 1.5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CRYPTO-142) Native library does not load if ENGINE_load_rdrand is not available
Marcelo Vanzin created CRYPTO-142:
-
Summary: Native library does not load if ENGINE_load_rdrand is not
available
Key: CRYPTO-142
URL: https://issues.apache.org/jira/browse/CRYPTO-142
Project: Commons Crypto
Issue Type: Bug
Components: Native
Affects Versions: 1.0.0
Reporter: Marcelo Vanzin
Found this when running tests on Travis:
{noformat}
java.security.GeneralSecurityException: CryptoRandom:
[org.apache.commons.crypto.random.OpenSslCryptoRandom] failed with
java.lang.reflect.InvocationTargetException
at
org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
Caused by: java.lang.RuntimeException:
java.lang.reflect.InvocationTargetException
at
org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
Caused by: java.lang.reflect.InvocationTargetException
at
org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
Caused by: java.security.GeneralSecurityException: Native library could not be
initialised
at
org.apache.commons.crypto.random.OpenSslCryptoRandomTest.getCryptoRandom(OpenSslCryptoRandomTest.java:37)
Caused by: java.lang.UnsatisfiedLinkError: ENGINE_load_rdrand
{noformat}
It seems that the OpenSSL library available on the build machine does not have
that function. It would be nice to allow the rest of the native code (e.g. the
ciphers) to still work in that situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CONFIGURATION-725) Update Apache Commons Text from 1.4 to 1.5
Gary Gregory created CONFIGURATION-725: -- Summary: Update Apache Commons Text from 1.4 to 1.5 Key: CONFIGURATION-725 URL: https://issues.apache.org/jira/browse/CONFIGURATION-725 Project: Commons Configuration Issue Type: Improvement Components: Interpolation Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Text from 1.4 to 1.5. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JXPATH-194) Support for JDOM 2
Daria Spescha created JXPATH-194:
Summary: Support for JDOM 2
Key: JXPATH-194
URL: https://issues.apache.org/jira/browse/JXPATH-194
Project: Commons JXPath
Issue Type: Bug
Affects Versions: 1.3
Environment: * Java 8 (Windows)
* jdom2
Reporter: Daria Spescha
JXPath does not correctly recognize JDOM 2 documents (since namespace changed
to org.jdom*2*) and treats them as "normal" Java objects which results in an
infinite loop on evaluating XPath expression.
My workaround was copying all classes from package
org.apache.commons.jxpath.ri.model.jdom to a new package and replacing all
occurences of "org.jdom" by "org.jdom2" (and renaming classes accordingly).
Additionally, I added the copied Pointer Factory to the context:
{code:java}
JXPathContextReferenceImpl.addNodePointerFactory(new JDOM2PointerFactory());
{code}
XPath evaluation now works again as expected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-scxml issue #3: Upgrade to JUnit jupiter
Github user woonsan commented on the issue: https://github.com/apache/commons-scxml/pull/3 Hi @mureinik , Could you also create a JIRA ticket for this PR at https://issues.apache.org/jira/projects/SCXML/? Then your contribution will be recognized better as those JIRA ticket numbers will be included in the release notes in the future. Thanks, Woonsan ---
[jira] [Updated] (CRYPTO-60) opensslCipher support GCM mode
[ https://issues.apache.org/jira/browse/CRYPTO-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcelo Vanzin updated CRYPTO-60: - Fix Version/s: 1.1.0 > opensslCipher support GCM mode > --- > > Key: CRYPTO-60 > URL: https://issues.apache.org/jira/browse/CRYPTO-60 > Project: Commons Crypto > Issue Type: Sub-task >Reporter: Xianda Ke >Assignee: Xianda Ke >Priority: Major > Fix For: 1.1.0 > > Attachments: gcm_design_doc.pdf > > > The interface would look like JCE. In encryption mode, the authenticated tag > information is appended at the end of output. > In decryption mode, the authenticated tag should appended at the end of > input. If the encrypted data is tampered, it will throw an > AEADBadTagException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CRYPTO-135) CryptoOutputStream is always blocking
[ https://issues.apache.org/jira/browse/CRYPTO-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcelo Vanzin resolved CRYPTO-135. --- Resolution: Won't Fix See discussion in the PR for this: https://github.com/apache/commons-crypto/pull/74 Short summary: it's very hard to provide non-blocking semantics and still return reasonable values to the callers of the WritableByteChannel API. So instead I just commented on the class javadocs that they should only be used with blocking I/O. > CryptoOutputStream is always blocking > - > > Key: CRYPTO-135 > URL: https://issues.apache.org/jira/browse/CRYPTO-135 > Project: Commons Crypto > Issue Type: Bug > Components: Stream >Affects Versions: 1.1.0 >Reporter: Marcelo Vanzin >Priority: Major > > CRYPTO-125 described a bug where not all data written to the > CryptoOutputStream would make it to the underlying channel if that channel > was non-blocking. > The fix added in that bug makes CryptoOutputStream blocking by doing a busy > loop. This makes it a poor match (not to say unusable) for applications that > use non-blocking channels, since it will turn non-blocking streams into > blocking streams that waste a lot of CPU. > Instead, CryptoOutputStream should correctly implement non-blocking semantics > in its implementation of WritableByteChannel. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638343#comment-16638343 ] Akshay Gehi commented on BEANUTILS-509: --- Hi Gary, It times out because the test case iterates 1 billion times. To be safe, we can change that to 1 million on line 69 of your checked in class. Regards, Akshay Gehi > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638317#comment-16638317 ] Gary Gregory commented on BEANUTILS-509: [~akshaygehi] Thank you for your patch. I've applied a slightly modified version of the new test case class and '@Ignore'd it: it always fails with a JUnit test timeout; with or without the change applied to WrapDynaClass. Therefore, I did not apply changes to WrapDynaClass. Please pick up svn trunk for any subsequent patches. Thank you! Gary > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-scxml pull request #3: Upgrade to JUnit jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-scxml/pull/3 Upgrade to JUnit jupiter This PR migrates the project to the modern JUnit Jupiter 5.3.1 testing framework. Since JUnit Jupiter is not backwards compatible to JUnit 4.x, or even JUnit Vintage 5.x, the patch is a tad large, although most of the changes are just cosmetic. 1. Maven changes: 1. `org.junit.jupiter:junit-jupiter-api` was added to provide the new APIs used. 1. `org.junit.jupiter:junit-jupiter-engine` was added as a testing engine. Its presence allows `maven-surefire-plugin` to use the Jupiter provider in order to execute tests. 1. `junit:junit` was removed, as it's no longer in use. 1. The parent module, `org.apache.commons:commons-parent` was upgraded to the latest version, `47`, in order to consume `org.apache.maven.plugins:maven-surefire-plugin:2.22.0` that natively supports Jupiter tests. 1. Annotations: 1. `org.junit.jupiter.api.Test` was used as a drop in replacement for `org.juit.Test` without arguments. See 3.b for handling of the `@Test` annotation with an `expected` argument. 1. `org.junit.jupiter.api.BeforeEach` was used as an drop in replacement for `org.junit.Before`. 1. `org.junit.jupiter.api.AfterEach` was used as a drop in replacement for `org.junit.After`. 1. `org.junit.jupiter.api.BeforeAll` was used as a drop in replacement for `org.junit.BeforeClass`. 1. `org.junit.jupiter.api.AfterAll` was used as a drop in replacement for `org.junit.AfterClass`. 3. Assertions: 1. `org.junit.jupiter.api.Assertions`' methods were used as a drop in replacements for `org.junit.Assert`'s methods with the same name in the simple case of an assertion without a message. In the case of an assertion with a message, `org.junit.jupiter.api.Assertions`' methods were used, but the argument order was changed - `Assert`'s methods take the message as the first argument, while `Assertions`' methods take the message as the last argument. 1. `org.junit.jupiter.api.Assertions#assertThrows` was used to assert a specific exception was thrown instead of an `org.junit.Test` annotation with an `expected` argument. This technique has a side bonus of making the tests slightly stricter, as now they assert the exception was thrown from a specific line and prevent false posivites where the test's "set-up" code accidentally threw that exception. The `throws` clauses of these methods were cleaned up from exceptions that can no longer be thrown in order to avoid compilation warnings. 4. Miscelanious 1. The redundant `main` methods in the test classes of the `org.apache.commons.scxml2.env.javascript` package were removed, and the Javadoc was updated accordingly. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-scxml junit-jupiter Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-scxml/pull/3.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 #3 commit 3d133ce5490a26252622c14d34460501770506e0 Author: Allon Mureinik Date: 2018-10-04T09:55:34Z Remove unused main methods Remove unused main methods of in the org.apache.commons.scxml2.env.javascript package. These tests do not need tham, as they are run via maven-surefire-plugin which picks up the annotated tests. commit 73462b0538755f838ea47fd6c83e31b393e6762d Author: Allon Mureinik Date: 2018-10-04T09:56:36Z javadoc fix Fix org.apache.commons.scxml2.env.javascript tests' javadocs - the test methods are clearly annotaed with JUnit 4 annotations, and therefore these are not a JUnit 3 tests. commit 521518be32d3b1ab1f28e3509347702c1d7a3c8d Author: Allon Mureinik Date: 2018-10-04T11:04:03Z org.apache.commons:commons-parent dependency Upgraded to the latest available org.apache.commons:commons-parent in order to consume the latest maven-surefire-plugin required for the JUnit Jupiter upgarde. commit 8444b30a11e87e8b8e990d9c145ea4b1e617a0d0 Author: Allon Mureinik Date: 2018-10-04T10:59:39Z Upgrade to JUnit Jupiter This PR migrates the project to the modern JUnit Jupiter 5.3.1 testing framework. Since JUnit Jupiter is not backwards compatible to JUnit 4.x, or even JUnit Vintage 5.x, the patch is a tad large, although most of the changes are just cosmetic. 1. Maven changes: a. org.junit.jupiter:junit-jupiter-api was added to provide the new APIs used. b. org.junit.jupiter:junit-jupiter-engine was added as a testing engine. Its presence allows maven-surefire-plugin to use the Jupiter provider in order to execute tests. c.
[jira] [Comment Edited] (JEXL-257) Function throwing IllegalArgumentException may called twice
[
https://issues.apache.org/jira/browse/JEXL-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638095#comment-16638095
]
Dmitri Blinov edited comment on JEXL-257 at 10/4/18 11:57 AM:
--
I think the problem lies in the code of {{MethodExecutor.tryInvoke()}}, as it
catches {{InvocationTargetException}} and returns {{TRY_FAILED}}, which is a
signal to retry method execution later. So the cached method will be called
twice. I think {{InvocationTargetException}} should not be catched by
{{tryInvoke}}, as {{InvocationTargetException}} means that we have successfully
resolved the method, but for some reason it throwed an exception. The original
problem seem not to be necessarily related to the method throwing
{{IllegalArgumentException}} per se, any exception thrown by the cached method
will lead to this, which is clearly should not be the case.
was (Author: dmitri_blinov):
I think the problem lies in the code of {{MethodExecutor.tryInvoke()}}, as it
catches {{InvocationTargetException}} and returns {{TRY_FAILED}}, which is a
signal to retry method execution later. So the cached method will be called
twice. I think {{InvocationTargetException}} should not be catched by
{{tryInvoke}}
> Function throwing IllegalArgumentException may called twice
> ---
>
> Key: JEXL-257
> URL: https://issues.apache.org/jira/browse/JEXL-257
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> With regard to JEXL-256 I have noticed that a function which once had throw
> IllegalArgumentException may be called immediately once again in script. The
> problem is not always reproducible so I think it is somehow related to
> caching and {{tryInvoke()}} being called first and {{invoke()}} called
> afterwards.
> I can't produce test case at the moment but try to describe on the example. I
> ommited some irrelevant details for the sake of simplicity...
> First I have a function that evaluates Jexl script within script.
> {code:java}
> eval("java = 1")
> {code}
> Then I have a {{Context.set()}} that works like this
> {code:java}
> public void set(String name) {
> if (name.equals("java"))
>throw new IllegalArgumentException("java");
> ...
> {code}
> As I stated in JEXL-256, when {{Context.set()}} throws
> IllegalArgumentException then script execution immediately terminates with
> this exception, and not with JexlException. So, the function {{eval()}} im my
> case terminates with IllegalArgumentException also.
> Then I have two stack traces in the log, one for the first invocation
> {quote}java.lang.IllegalArgumentException: java
> at MyDefaultContext.set(MyDefaultContext.java:279)
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1189)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:190)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:185)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at EvaluationContext.evalScript(EvaluationContext.java:1078)
> at EvaluationContext.evaluateScript(EvaluationContext.java:1043)
> at MyDefaultContext.eval(MyDefaultContext.java:736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_162]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_162]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.tryInvoke(MethodExecutor.java:104)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter$Funcall.tryInvoke(Interpreter.java:1436)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1545)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1357)
>
[jira] [Commented] (JEXL-257) Function throwing IllegalArgumentException may called twice
[
https://issues.apache.org/jira/browse/JEXL-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638095#comment-16638095
]
Dmitri Blinov commented on JEXL-257:
I think the problem lies in the code of {{MethodExecutor.tryInvoke()}}, as it
catches {{InvocationTargetException}} and returns {{TRY_FAILED}}, which is a
signal to retry method execution later. So the cached method will be called
twice. I think {{InvocationTargetException}} should not be catched by
{{tryInvoke}}
> Function throwing IllegalArgumentException may called twice
> ---
>
> Key: JEXL-257
> URL: https://issues.apache.org/jira/browse/JEXL-257
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> With regard to JEXL-256 I have noticed that a function which once had throw
> IllegalArgumentException may be called immediately once again in script. The
> problem is not always reproducible so I think it is somehow related to
> caching and {{tryInvoke()}} being called first and {{invoke()}} called
> afterwards.
> I can't produce test case at the moment but try to describe on the example. I
> ommited some irrelevant details for the sake of simplicity...
> First I have a function that evaluates Jexl script within script.
> {code:java}
> eval("java = 1")
> {code}
> Then I have a {{Context.set()}} that works like this
> {code:java}
> public void set(String name) {
> if (name.equals("java"))
>throw new IllegalArgumentException("java");
> ...
> {code}
> As I stated in JEXL-256, when {{Context.set()}} throws
> IllegalArgumentException then script execution immediately terminates with
> this exception, and not with JexlException. So, the function {{eval()}} im my
> case terminates with IllegalArgumentException also.
> Then I have two stack traces in the log, one for the first invocation
> {quote}java.lang.IllegalArgumentException: java
> at MyDefaultContext.set(MyDefaultContext.java:279)
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1189)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:890)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTJexlScript.jjtAccept(ASTJexlScript.java:58)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.interpret(Interpreter.java:190)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Script.execute(Script.java:185)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at EvaluationContext.evalScript(EvaluationContext.java:1078)
> at EvaluationContext.evaluateScript(EvaluationContext.java:1043)
> at MyDefaultContext.eval(MyDefaultContext.java:736)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_162]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:1.8.0_162]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:1.8.0_162]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_162]
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.invoke(MethodExecutor.java:93)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.tryInvoke(MethodExecutor.java:104)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter$Funcall.tryInvoke(Interpreter.java:1436)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at org.apache.commons.jexl3.internal.Interpreter.call(Interpreter.java:1545)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1357)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTFunctionNode.jjtAccept(ASTFunctionNode.java:18)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1149)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1094)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.parser.ASTAssignment.jjtAccept(ASTAssignment.java:18)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter.processAnnotation(Interpreter.java:1907)
> ~[commons-jexl-3.2.jar:3.2-SNAPSHOT]
> at
> org.apache.commons.jexl3.internal.Interpreter$1.call(Interpreter.java:1917)
>
[jira] [Created] (IO-586) FileUtils.copyFile fails with java.io.IOException: No such device
Andy created IO-586:
---
Summary: FileUtils.copyFile fails with java.io.IOException: No
such device
Key: IO-586
URL: https://issues.apache.org/jira/browse/IO-586
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.6
Reporter: Andy
When trying to copy file on CEPH filesystem, FileUtils.copyFile fails with
exception. I don't see any workaround except of replacing that call and
rebuilding the project.
*Test Case*:
Here's a simple class to reproduce the issue:
{code:java}
import org.apache.commons.io.FileUtils;
import java.io.File;
import java.io.IOException;
import java.io.PrintWriter;
import java.nio.file.Files;
public class Test3 {
public static void main(String[] args) throws IOException {
PrintWriter writer = new PrintWriter("file.txt", "UTF-8");
writer.println("test input " + Math.random());
writer.close();
FileUtils.copyFile(new File("file.txt"), new File("file-copy.txt"));
}
}
{code}
below is the stacktrace:
{code:java}
Exception in thread "main" java.io.IOException: No such device at
sun.nio.ch.FileChannelImpl.map0(Native Method) at
sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:926) at
sun.nio.ch.FileChannelImpl.transferFromFileChannel(FileChannelImpl.java:634) at
sun.nio.ch.FileChannelImpl.transferFrom(FileChannelImpl.java:708) at
org.apache.commons.io.FileUtils.doCopyFile(FileUtils.java:1131) at
org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1076) at
org.apache.commons.io.FileUtils.copyFile(FileUtils.java:1028) at
ztst.Test3.main(Test3.java:17)
{code}
Here's our server's file system configuration:
{code:java}
1. a squashfs (read only) image stored on a ceph's rbd
2. a directory on cephfs (read/write)
1 is the lower layer and 2 is the upper layer of an unionfs mount with the
following options:
cow
max_files=32768
allow_other
use_ino
direct_io
statfs_omit_ro
nonempty
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay Gehi updated BEANUTILS-509: -- Attachment: WrapDynaCache.patch > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16638044#comment-16638044 ] Akshay Gehi commented on BEANUTILS-509: --- Hi Gary, Please have a look at the revised patch with a concurrency test case. Unfortunately its not an easily replicable issue so the Junit will not always face before the fix is applied > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akshay Gehi updated BEANUTILS-509: -- Attachment: (was: WrapDynaCache.patch) > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
