[jira] [Commented] (BCEL-304) ClassPath.getClassFile() and friends do not work with JDK 9 and higher
[
https://issues.apache.org/jira/browse/BCEL-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640562#comment-16640562
]
Gary Gregory commented on BCEL-304:
---
[~epavlak],
We do not have a release planned ATM. You might want to ping the dev mailing
list and raise awareness for your need for a release.
Gary
> ClassPath.getClassFile() and friends do not work with JDK 9 and higher
> --
>
> Key: BCEL-304
> URL: https://issues.apache.org/jira/browse/BCEL-304
> Project: Commons BCEL
> Issue Type: Bug
> Components: Main
>Affects Versions: 6.2
>Reporter: Ed Pavlak
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 6.3
>
>
> When trying to get the class file for Java classes (ie. java.lang.String), an
> IOException is thrown:
> Exception in thread "main" java.io.IOException: Couldn't find:
> java.lang.String.class
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:279)
> at org.apache.bcel.util.ClassPath.getClassFile(ClassPath.java:301)
> at bcel.test.GetClassFileTest.main(GetClassFileTest.java:12)
>
> The root cause appears to be the restructuring of Java starting with Java 9.
> Specifically, the removal of the rt.jar. The above excpetion can be
> reproduced using a simple application:
> package bcel.test;
> import java.io.IOException;
> import org.apache.bcel.util.ClassPath;
> public class GetClassFileTest {
> public static void main(String[] args) throws IOException {
> String className = "java.lang.String";
> System.out.println("Looking up ClassPath.ClassFile for: " + className);
> ClassPath.ClassFile classFile =
> ClassPath.SYSTEM_CLASS_PATH.getClassFile(className);
> if (classFile != null) {
> System.out.println("Class file base: " + classFile.getBase());
> System.out.println("Class file path: " + classFile.getPath());
> }
> }
> }
>
> Running this on Java 8 produces the following output, whereas running it on
> Java 9+ produces the IOException:
> Class file base: C:\jdk1.8.0_161\jre\lib\rt.jar
> Class file path: java/lang/String.class
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640527#comment-16640527
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}The name {{multiply}} seems strange; wouldn't {{compose}} be more
appropriate?
{quote}
Yes, {{multiply}} does seem to expose the underlying matrix implementation. We
could do {{compose}} but then I think the API would be a bit more awkward,
assuming that by {{A.compose(B)}} we mean "perform B then perform A". For
example, if we want to perform a series of transforms in order {{A}}, {{B}},
{{C}}, and then {{D}}, we would need to do
{{D.compose(C.compose(B.compose(A)))}}. If we rename it to {{apply}} and define
{{A.apply(B)}} as "take A and perform B on it", then we can write the same
series of transforms a {{A.apply(B).apply(C).apply(D)}}. I feel like that's
cleaner and better matches the behavior of the other methods, like
{{translate}}.
{quote}{{tranform.apply(v)}} looks more natural than {{v.applyt(transform)}}.
{quote}
I used {{transform.applyTo(vec)}} since that's typically how one talks about
transforms operating, ie, they are applied _to_ points and vectors. The vector
and point classes have corresponding {{vec.apply(transform)}}.
{quote}Doesn't {{createTranslation}} duplicate {{translate}}?
{quote}
They are similar but slightly different. {{translate}} is an instance method
and applies a translation to the current transform. This involves a matrix
multiplication. {{createTranslation}} is a static factory method for creating a
brand new transform that performs a translation. The matrix for this can be
created directly; no matrix multiplication is involved. I would have liked to
have given them the same name but then the methods would conflict.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RNG-59) More robust "SeedFactory"
Gilles created RNG-59:
-
Summary: More robust "SeedFactory"
Key: RNG-59
URL: https://issues.apache.org/jira/browse/RNG-59
Project: Commons RNG
Issue Type: Improvement
Components: simple
Affects Versions: 1.1, 1.0
Reporter: Gilles
Fix For: 1.2
{{SeedFactory}} will produce the same seed when several instances of the same
program are launched in rapid successions.
--
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=16640486#comment-16640486
]
Gilles commented on RNG-57:
---
There are too many things in PR 11: it should only contain the additions to
{{LongProvider}} and {{IntProvider}} and their associated unit tests.
For the failures, I think that the least problematic change would be to select
another seed. We can always revisit later the common infrastructure of the
unit tests.
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640379#comment-16640379
]
Alex D Herbert commented on RNG-57:
---
bq. Please rebase your changes on the current "master" (sorry).
Done. It still fails due to randomness on this machine on
{{MultiplyWithCarry256}} with {{nextInt}}.
I say this machine since it is now my laptop. I noticed that the errors on
Travis were different for JDK 7 than with 8 & 9.
I'm using JDK 8. So the JUnit tests must get run in a different order depending
on the JDK and/or the platform.
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640375#comment-16640375
]
Alex D Herbert commented on RNG-57:
---
bq. IIRC, I did this to avoid a circular dependency between commons-rng-core
and commons-rng-simple;
For a test you can use anything to create the seed, i.e. another library. The
maven dependency can be scoped to test.
But that adds complexity so just use java.util.Random to get a not so random
seed. Or SecureRandom to get a very random one.
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640372#comment-16640372
]
Gilles commented on RNG-57:
---
bq. shows that the parentState == null is never hit at the moment.
Indeed. I changed that yesterday but forgot to {{git push}}...
It's now in "master".
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640369#comment-16640369
]
Gilles commented on RNG-57:
---
bq. Each RNG is built using a fixed seed
IIRC, I did this to avoid a circular dependency between {{commons-rng-core}}
and {{commons-rng-simple}}; but I think that a random seed would be preferable,
even if the test would then sometimes fail.
Perhaps a circular dependency in the {{test}} area is acceptable (?).
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640363#comment-16640363
]
Alex D Herbert commented on RNG-57:
---
I also noticed that {{BaseProvider}} returns an empty array in
{{getStateInternal}} but the method to concatenate them only checks for null.
So the null check could be updated to:
{code:java}
if (parentState == null || parentState.length == 0) {
return state;
}
{code}
A quick check with:
{noformat}
mvn test jacoco:report
{noformat}
shows that the parentState == null is never hit at the moment.
WDYT?
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640357#comment-16640357
]
Gilles commented on RNG-57:
---
Please rebase your changes on the current "master" (sorry).
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640345#comment-16640345
]
Gilles commented on RNG-57:
---
bq. So parent should be first. It is also documented to work this way.
Actually not, as it would be confusing since in the code the "local" state
comes first.
bq. So I've just added some comments in the code that the order is state+parent
when combining and splitting.
Thanks but it is the Javadoc example that needed fixing.
And all the calls in the implementations...
As you noted, the code in {{BaseProvider}} concatenates "local" + "parent", and
is pretty self-documenting.
I'll make a separate commit to fix.
Sorry for the mix-up!
> 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] (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=16640297#comment-16640297 ] Gary Gregory commented on BEANUTILS-509: I guess the problem on my end is that I cannot get your test to fail. Can you come up with a test that fails without changes to the main code? > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.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] [Resolved] (CONFIGURATION-716) PropertiesConfiguration: Escape sequence handling different from Properties
[ https://issues.apache.org/jira/browse/CONFIGURATION-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-716. Resolution: Fixed Fix Version/s: 2.4 Fixed together with CONFIGURATION-715. > PropertiesConfiguration: Escape sequence handling different from Properties > --- > > Key: CONFIGURATION-716 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-716 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Patrick Schmidt >Priority: Major > Fix For: 2.4 > > > The escape sequence handling in PropertiesConfiguration is different from > java.util.Properties. > The Javadoc (of java.util.Properties) basically states that if an escape > sequence (backslash + character) is not understood, the backslash is simply > removed. PropertiesConfiguration keeps the backslash. E.g. "\ " (backslash + > space) should result in just a space. This sequence is used by Properties to > escape the first leading space in a property value when writing to a > properties-file. PropertiesConfiguration does not understand this syntax. > Also (which is technically a different issue but pretty close to this one) > does not preserve leading spaces in property values when saving. One could > use \u0020 to encode the first leading space, but it would be nicer if it > could just use the simpler "\ ". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (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:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-715.
Resolution: Fixed
Fix Version/s: 2.4
Patch was applied, and you have been added to the contributors section.
Many thanks again!
> 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
> Fix For: 2.4
>
>
> 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] (BEANUTILS-512) Add Automatic-Module-Name entry to MANIFEST.MF
[ https://issues.apache.org/jira/browse/BEANUTILS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed BEANUTILS-512. -- Resolution: Fixed In svn trunk. > Add Automatic-Module-Name entry to MANIFEST.MF > -- > > Key: BEANUTILS-512 > URL: https://issues.apache.org/jira/browse/BEANUTILS-512 > Project: Commons BeanUtils > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.0.0 > > > Add Automatic-Module-Name entry to MANIFEST.MF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BEANUTILS-512) Add Automatic-Module-Name entry to MANIFEST.MF
Gary Gregory created BEANUTILS-512: -- Summary: Add Automatic-Module-Name entry to MANIFEST.MF Key: BEANUTILS-512 URL: https://issues.apache.org/jira/browse/BEANUTILS-512 Project: Commons BeanUtils Issue Type: New Feature Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 2.0.0 Add Automatic-Module-Name entry to MANIFEST.MF. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NET-615) IMAPClient could simplify using empty arguments
[
https://issues.apache.org/jira/browse/NET-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved NET-615.
--
Resolution: Fixed
URL: http://svn.apache.org/viewvc?rev=1842969=rev
Log:
NET-614 IMAP fails to quote/encode mailbox names...
> IMAPClient could simplify using empty arguments
> ---
>
> Key: NET-615
> URL: https://issues.apache.org/jira/browse/NET-615
> Project: Commons Net
> Issue Type: Improvement
>Reporter: Sebb
>Priority: Major
>
> Several IMAP commands require arguments.
> For example LIST and LSUB require 2 arguments
> However these arguments can be the empty string, which needs to be quoted,
> for example:
> bq. LIST "" ""
> This is awkward to code at present:
> {code}
> imap.list("\"\"","\"\"")
> {code}
> so it would be useful if NET could handle this case internally
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (NET-614) IMAP fails to quote/encode mailbox names
[ https://issues.apache.org/jira/browse/NET-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved NET-614. -- Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=1842969=rev Log: NET-614 IMAP fails to quote/encode mailbox names... URL: http://svn.apache.org/viewvc?rev=1842972=rev Log: NET-614 IMAP fails to quote/encode mailbox names More commands with mailbox name parameters > IMAP fails to quote/encode mailbox names > > > Key: NET-614 > URL: https://issues.apache.org/jira/browse/NET-614 > Project: Commons Net > Issue Type: Bug > Components: IMAP >Affects Versions: 3.6 >Reporter: Sebb >Priority: Major > > Mailbox names need to be quoted if they contain spaces or double-quote. > If they contain non-ASCII characters then they also need to be encoded [1] > There may be other parameters that are not being encoded/quoted correctly. > [1] https://tools.ietf.org/html/rfc3501#section-5.1.3 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-55) make all "business" method implementations of public API thread safe
[ https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640079#comment-16640079 ] Daniel Atallah commented on CODEC-55: - I agree with the sentiments that the lack of thread safety is not a vulnerability. In this case, I think that it's clearly called out in the documentation (some of the constraints on thread safe usage are a bit odd from an API perspective, but as long as it's documented I don't think it's even a bug). I have asked the WhiteSource team to re-evaluate that they consider this a vulnerability - maybe that's all that is necessary. > make all "business" method implementations of public API thread safe > - > > Key: CODEC-55 > URL: https://issues.apache.org/jira/browse/CODEC-55 > Project: Commons Codec > Issue Type: Wish >Reporter: Qingtian Wang >Priority: Major > Fix For: 1.x > > Attachments: CODEC-55-Wrapper-Implementations.patch, > concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch > > > Maybe most of the implementations are already thread safe. Just such that > codec can say so in general... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-55) make all "business" method implementations of public API thread safe
[ https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640065#comment-16640065 ] Sebb commented on CODEC-55: --- If lack of thread-safety means that there is a security issue, then just about every Java program is at risk - there are lots of methods/classes in the JVM which are not thread-safe. Surely the issue is whether the methods/classes are *used* in a thread-safe manner? That is not something over which Apache Commons has any control. Obviously it makes it easier for users of the API if everything is thread-safe, but that may not be feasible or necessary in the general case. > make all "business" method implementations of public API thread safe > - > > Key: CODEC-55 > URL: https://issues.apache.org/jira/browse/CODEC-55 > Project: Commons Codec > Issue Type: Wish >Reporter: Qingtian Wang >Priority: Major > Fix For: 1.x > > Attachments: CODEC-55-Wrapper-Implementations.patch, > concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch > > > Maybe most of the implementations are already thread safe. Just such that > codec can say so in general... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CRYPTO-141) Errors in native code can leave Java wrappers in bad state
[
https://issues.apache.org/jira/browse/CRYPTO-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcelo Vanzin resolved CRYPTO-141.
---
Resolution: Fixed
Assignee: Marcelo Vanzin
Fix Version/s: 1.1.0
> Errors in native code can leave Java wrappers in bad state
> --
>
> Key: CRYPTO-141
> URL: https://issues.apache.org/jira/browse/CRYPTO-141
> Project: Commons Crypto
> Issue Type: Bug
> Components: Native
>Reporter: Marcelo Vanzin
>Assignee: Marcelo Vanzin
>Priority: Major
> Fix For: 1.1.0
>
>
> Currently, the Java side keeps a reference to the address of the EVP context,
> and checks that it's not 0 before performing any operations.
> But if an error happens in native code, for example here in init():
> {code}
> if (result == 0 && context != NULL) {
> if (CONTEXT(ctx) != NULL) {
> dlsym_EVP_CIPHER_CTX_cleanup(context);
> } else {
> dlsym_EVP_CIPHER_CTX_free(context);
> }
> }
> {code}
> The address known to the Java side will now be invalid, and if any native
> method is now called the JVM will crash.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639951#comment-16639951
]
Alex D Herbert edited comment on RNG-57 at 10/5/18 4:13 PM:
{quote}No need to insert paragraph formatting tags (...) in the Javadoc
{quote}
Thanks for pointing that out. I add them everywhere out of habit.
Updated:
I've changed my mind about removing them if the {{/** ... */}} tags are used
since the comment is still rendered as if it was Javadoc by Eclipse. It may be
the same for other IDEs. This means that someone working on the code knows what
the field is for without having to go to the source line number.
I changed them to:
{code:java}
/**
* Some text.
*
* Some more text.
*/
{code}
I can remove the {{}} if it really bothers you.
was (Author: alexherbert):
{quote}No need to insert paragraph formatting tags (...) in the
Javadoc{quote}
Thanks for pointing that out. I add them everywhere out of habit.
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640009#comment-16640009
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert commented on the issue:
https://github.com/apache/commons-rng/pull/11
[RNG-58](https://issues.apache.org/jira/browse/RNG-58) addresses the
setting of the state, allowing state to be stored at any level of the hierarchy
below `BaseProvider`.
This PR has been updated to use that functionality.
The build now fails due to the randomness of testing.
> 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-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1663#comment-1663
]
Alex D Herbert commented on RNG-57:
---
{quote}Please review the changes made for RNG-58.
{quote}
Nice modifications. I noticed that the {{BaseProvider}} has the signature:
{code:java}
protected byte[] composeStateInternal(byte[] state,
byte[] parentState) {
{code}
but the javadoc order for {{parentState}} and {{state}} are reversed. So I
assume you originally wrote it the other way around then swapped them. With no
state from the parent it wouldn't be detected in a test.
Suffice to say it doesn't work as is and I had to swap them back to:
{code:java}
protected byte[] composeStateInternal(byte[] parentState,
byte[] state) {
{code}
This is the simplest change to get things working. However the order in the
combined state is state+parentState so logically the arguments should be state
and parentState. But all the sub-classes do this:
{code:java}
return composeStateInternal(super.getStateInternal(),
state);
{code}
So parent should be first. It is also documented to work this way.
So I've just added some comments in the code that the order is state+parent
when combining and splitting.
The test for {{ProvidersCommonParametricTest.testStateSettable}} passes. So the
combining and splitting of the state is working.
I am now getting some failures in {{ProvidersCommonParametricTest}} due to
randomness.
The failures are always the same. Each RNG is built using a fixed seed and I
assume JUnit is running the tests in the same order.
However the changes to cache calls from {{next}} (either {{int}} or {{long}})
means that the sequence that is tested after the first call to {{nextBoolean}}
for an {{IntProvider}}, or the first call to {{nextBoolean/nextInt}} for an
{{LongProvider}} is different. These are the failures:
{noformat}
[ERROR] Failures:
[ERROR]
ProvidersCommonParametricTest.testUniformNextIntegerInRange:165->checkNextIntegerInRange:400->checkNextIntegerInRange:420->checkNextInRange:552
org.apache.commons.rng.core.source32.MultiplyWithCarry256: Too many failures
for n = 1834691456 (11 out of 500 tests failed)
[ERROR]
ProvidersCommonParametricTest.testUniformNextLongInRange:180->checkNextLongInRange:438->checkNextInRange:552
org.apache.commons.rng.core.source64.XorShift1024Star: Too many failures for n
= 4611686018427387902 (11 out of 500 tests failed)
{noformat}
- MultiplyWithCarry256 is an {{IntProvider}} and so the method {{next(int)}}
is unchanged. The failures are due to the state of the sequence being shifted
after a call of nextBoolean.
- XorShift1024Star is a {{LongProvider}} and the method {{next(int)}} has been
changed. The failures may actually be due to the loss of randomness from using
the using the upper and lower bits from the long as separate {{int}} samples.
However both tests only fail with 11/500 (p=0.022) which is 1 failure above the
critical p-value of 0.02.
I've pushed to the same PR branch so you can view the changes.
Q. What to do to fix this?
- Change the fixed seed for each of the failing providers until it works.
- Change the critical p-value.
> 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] (CODEC-55) make all "business" method implementations of public API thread safe
[ https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639993#comment-16639993 ] Lijing Lin commented on CODEC-55: - [~datallah]So is the security vulnerability from WhiteSource false positive? Can you provide further justification? Thanks. The MEDIUM security warning on commons-codec-1.11.jar says, "_Not all "business" method implementations of public API in Apache Commons Codec 1.x are thread safe, which might disclose the wrong data or allow an attacker to change non-private fields._" > make all "business" method implementations of public API thread safe > - > > Key: CODEC-55 > URL: https://issues.apache.org/jira/browse/CODEC-55 > Project: Commons Codec > Issue Type: Wish >Reporter: Qingtian Wang >Priority: Major > Fix For: 1.x > > Attachments: CODEC-55-Wrapper-Implementations.patch, > concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch > > > Maybe most of the implementations are already thread safe. Just such that > codec can say so in general... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CODEC-55) make all "business" method implementations of public API thread safe
[ https://issues.apache.org/jira/browse/CODEC-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639993#comment-16639993 ] Lijing Lin edited comment on CODEC-55 at 10/5/18 3:59 PM: -- Hi [~datallah] So is the security vulnerability from WhiteSource false positive? Can you provide further justification? Thanks. The MEDIUM security warning on commons-codec-1.11.jar says, "_Not all "business" method implementations of public API in Apache Commons Codec 1.x are thread safe, which might disclose the wrong data or allow an attacker to change non-private fields._" was (Author: lijing...@us.ibm.com): [~datallah]So is the security vulnerability from WhiteSource false positive? Can you provide further justification? Thanks. The MEDIUM security warning on commons-codec-1.11.jar says, "_Not all "business" method implementations of public API in Apache Commons Codec 1.x are thread safe, which might disclose the wrong data or allow an attacker to change non-private fields._" > make all "business" method implementations of public API thread safe > - > > Key: CODEC-55 > URL: https://issues.apache.org/jira/browse/CODEC-55 > Project: Commons Codec > Issue Type: Wish >Reporter: Qingtian Wang >Priority: Major > Fix For: 1.x > > Attachments: CODEC-55-Wrapper-Implementations.patch, > concurrentCodecs.diff, concurrentQDiff.diff, urlcodec.patch > > > Maybe most of the implementations are already thread safe. Just such that > codec can say so in general... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TEXT-147) Add a Base64 encoder string lookup.
[
https://issues.apache.org/jira/browse/TEXT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed TEXT-147.
-
Resolution: Fixed
In git master.
> Add a Base64 encoder string lookup.
> ---
>
> Key: TEXT-147
> URL: https://issues.apache.org/jira/browse/TEXT-147
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Gary Gregory
>Priority: Major
> Fix For: 1.6
>
>
> Add a Base64 encoder string lookup
> {{org.apache.commons.text.lookup.StringLookupFactory.base64EncoderStringLookup()}}
> Deprecate
> {{org.apache.commons.text.lookup.StringLookupFactory.base64StringLookup()}}
> in favor of
> {{org.apache.commons.text.lookup.StringLookupFactory.base64DecoderStringLookup()}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TEXT-147) Add a Base64 encoder string lookup.
Gary Gregory created TEXT-147:
-
Summary: Add a Base64 encoder string lookup.
Key: TEXT-147
URL: https://issues.apache.org/jira/browse/TEXT-147
Project: Commons Text
Issue Type: New Feature
Reporter: Gary Gregory
Fix For: 1.6
Add a Base64 encoder string lookup
{{org.apache.commons.text.lookup.StringLookupFactory.base64EncoderStringLookup()}}
Deprecate
{{org.apache.commons.text.lookup.StringLookupFactory.base64StringLookup()}} in
favor of
{{org.apache.commons.text.lookup.StringLookupFactory.base64DecoderStringLookup()}}
--
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=16639951#comment-16639951
]
Alex D Herbert commented on RNG-57:
---
{quote}No need to insert paragraph formatting tags (...) in the
Javadoc{quote}
Thanks for pointing that out. I add them everywhere out of habit.
> 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] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16639906#comment-16639906
]
Gilles commented on GEOMETRY-14:
I didn't look in detail; here are a few remarks:
* The name {{multiply}} seems strange; wouldn't {{compose}} be more appropriate?
* {{tranform.apply(v)}} looks more natural than {{v.applyt(transform)}}.
* Incremental building from the unit transform seems fine
* Doesn't {{createTranslation}} duplicate {{translate}}?
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
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=16639701#comment-16639701 ] Akshay Gehi commented on BEANUTILS-509: --- Hi Gary, Please have a look at [^WrapDynaCache_after_svn_commit.patch] 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, > WrapDynaCache_after_svn_commit.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: WrapDynaCache_after_svn_commit.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, > WrapDynaCache_after_svn_commit.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: 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] [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)
