[jira] [Commented] (NUMBERS-50) Clean checkstyle for Complex
[ https://issues.apache.org/jira/browse/NUMBERS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302635#comment-16302635 ] Gilles commented on NUMBERS-50: --- bq. option is to change the subject and extend the scope to solve all the checkstyle errors. Sure, but it could be confusing to change the purpose meant by the original reporter. I think that it would be nicer to open a new one similar to [that page (for RNG)|https://issues.apache.org/jira/browse/RNG-23]. > Clean checkstyle for Complex > > > Key: NUMBERS-50 > URL: https://issues.apache.org/jira/browse/NUMBERS-50 > Project: Commons Numbers > Issue Type: Bug >Reporter: Eric Barnhill >Priority: Trivial > > Clean up trailing whitespaces and other checkstyle violations in > commons-numbers-complex -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated CONFIGURATION-684:
-
Labels: discussion help-wanted (was: )
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
> Labels: discussion, help-wanted
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302606#comment-16302606
]
Bruno P. Kinoshita commented on CONFIGURATION-684:
--
Hmm. Good point [~oliver.he...@t-online.de]. [~fabienrenaud], not too sure
about disabling it completely, as it would impact other users that have built
their software on top of the premise that dots were escaped.
I don't have the need for this change right now, but perhaps users that have
YAML configuration files from other frameworks/tools with dots in the keys
could be affected by this issue.
There are some tools (Ansible, Jenkins, Openshift, SpringBoot, etc) that
support YAML and may use dots in the keys. I suspect users from these tools
could report problems some day with this default behaviour.
*
https://github.com/spring-projects/spring-boot/blob/8f793eaf33cc312935fc69b3591bf2aa55c63275/spring-boot-project/spring-boot/src/test/resources/activeprofilerepro.yml
*
https://github.com/khoubyari/spring-boot-rest-example/blob/c8c6a745ed7c2772d26cfb24a46f17c230eedcfe/src/main/resources/application.yml
*
https://github.com/openshift/origin/blob/d017a2b159a44ae6860696caa3f9a88261e7b82a/examples/jenkins/pipeline/bluegreen-pipeline.yaml
So I would be pending towards i) modifying the keys parsing just for YAML,
allowing dots, and then ii) updating the documentation explaining that YAML
supports dots in the keys, but not the other formats.
One issue that we could have, however, is when mixing configurations from
YAML/XML/ini/etc. Not sure if there could be a case where a key read from a
YAML file is mixed with keys from other sources, and for some reason it results
in an error...
Not in a hurry to get it fixed, so happy to wait others to review this issue
and vote on these solutions or others, or just comment their point of view.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (BEANUTILS-500) Upgrade commons-collections to 4
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius resolved BEANUTILS-500. Resolution: Fixed > Upgrade commons-collections to 4 > > > Key: BEANUTILS-500 > URL: https://issues.apache.org/jira/browse/BEANUTILS-500 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 2.0 >Reporter: Dave Brosius >Priority: Minor > Fix For: 2.0 > > Attachments: BEANUTILS-500.2.txt, BEANUTILS-500.3.txt, > BEANUTILS-500.txt > > > uptake commons-collections4. > The main difference is the removal of 'FastHashMap', and replacement with > ConcurrentHashMap. > There are a few breaking changes for deprecated methods that return a > FastHashMap, that are exposed. > I made them package private, and undeprecated them, thus 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BEANUTILS-500) Upgrade commons-collections to 4
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated BEANUTILS-500: --- Attachment: BEANUTILS-500.3.txt And the last patch (BEANUTILS-500.3.txt) resolves the MemoryLeakTestCase, and with that, all unit tests pass. > Upgrade commons-collections to 4 > > > Key: BEANUTILS-500 > URL: https://issues.apache.org/jira/browse/BEANUTILS-500 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 2.0 >Reporter: Dave Brosius >Priority: Minor > Fix For: 2.0 > > Attachments: BEANUTILS-500.2.txt, BEANUTILS-500.3.txt, > BEANUTILS-500.txt > > > uptake commons-collections4. > The main difference is the removal of 'FastHashMap', and replacement with > ConcurrentHashMap. > There are a few breaking changes for deprecated methods that return a > FastHashMap, that are exposed. > I made them package private, and undeprecated them, thus 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (BEANUTILS-500) Upgrade commons-collections to 4
[ https://issues.apache.org/jira/browse/BEANUTILS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Brosius updated BEANUTILS-500: --- Attachment: BEANUTILS-500.2.txt Finally had a chance to look at the Jira61TestCase failures, this patch (BEANUTILS-500.2.txt) should fix them > Upgrade commons-collections to 4 > > > Key: BEANUTILS-500 > URL: https://issues.apache.org/jira/browse/BEANUTILS-500 > Project: Commons BeanUtils > Issue Type: Improvement > Components: Bean / Property Utils >Affects Versions: 2.0 >Reporter: Dave Brosius >Priority: Minor > Fix For: 2.0 > > Attachments: BEANUTILS-500.2.txt, BEANUTILS-500.txt > > > uptake commons-collections4. > The main difference is the removal of 'FastHashMap', and replacement with > ConcurrentHashMap. > There are a few breaking changes for deprecated methods that return a > FastHashMap, that are exposed. > I made them package private, and undeprecated them, thus 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MATH-1436) PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
[ https://issues.apache.org/jira/browse/MATH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated MATH-1436: Fix Version/s: (was: 3.6.1) > PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues > > > Key: MATH-1436 > URL: https://issues.apache.org/jira/browse/MATH-1436 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.5, 3.6, 3.6.1 >Reporter: Matt Juntunen > Fix For: 4.0 > > > These are two separate issues that I found while using the partitioning code > from 3.5 to work with complex solid models. The issues are: > 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses > a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent > hyperplane. This causes issues when working with a tolerance other than the > default. > 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on > infinite line segments. An IndexOutOfBoundsException is thrown when a > PolygonsSet is created with a single infinite SubLine as a boundary and a > NullPointerException is thrown when one is created with a mix of finite and > finite boundaries. > I will be attaching a pull request shortly with fixes and unit tests. > UPDATE: > -Pull request for v4.0: [https://github.com/apache/commons-math/pull/70]- > -Pull request for v3.6.x: [https://github.com/apache/commons-math/pull/71]- > (removed; no future releases planned for v3.x) > UPDATE [2017-12-23]: > Split initial pull request into two separate ones: > - SubOrientedPoint changes: [https://github.com/apache/commons-math/pull/72] > - PolygonsSet changes: [https://github.com/apache/commons-math/pull/73 ] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (MATH-1436) PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
[ https://issues.apache.org/jira/browse/MATH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302551#comment-16302551 ] Matt Juntunen commented on MATH-1436: - I split the pull request in two and added the new links in the issue description. There's also a few more unit tests and more comments. And better commit messages, too :-) Let me know if this will work or not. Thanks. > PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues > > > Key: MATH-1436 > URL: https://issues.apache.org/jira/browse/MATH-1436 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.5, 3.6, 3.6.1 >Reporter: Matt Juntunen > Fix For: 4.0, 3.6.1 > > > These are two separate issues that I found while using the partitioning code > from 3.5 to work with complex solid models. The issues are: > 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses > a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent > hyperplane. This causes issues when working with a tolerance other than the > default. > 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on > infinite line segments. An IndexOutOfBoundsException is thrown when a > PolygonsSet is created with a single infinite SubLine as a boundary and a > NullPointerException is thrown when one is created with a mix of finite and > finite boundaries. > I will be attaching a pull request shortly with fixes and unit tests. > UPDATE: > -Pull request for v4.0: [https://github.com/apache/commons-math/pull/70]- > -Pull request for v3.6.x: [https://github.com/apache/commons-math/pull/71]- > (removed; no future releases planned for v3.x) > UPDATE [2017-12-23]: > Split initial pull request into two separate ones: > - SubOrientedPoint changes: [https://github.com/apache/commons-math/pull/72] > - PolygonsSet changes: [https://github.com/apache/commons-math/pull/73 ] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MATH-1436) PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
[ https://issues.apache.org/jira/browse/MATH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Juntunen updated MATH-1436: Description: These are two separate issues that I found while using the partitioning code from 3.5 to work with complex solid models. The issues are: 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent hyperplane. This causes issues when working with a tolerance other than the default. 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on infinite line segments. An IndexOutOfBoundsException is thrown when a PolygonsSet is created with a single infinite SubLine as a boundary and a NullPointerException is thrown when one is created with a mix of finite and finite boundaries. I will be attaching a pull request shortly with fixes and unit tests. UPDATE: -Pull request for v4.0: [https://github.com/apache/commons-math/pull/70]- -Pull request for v3.6.x: [https://github.com/apache/commons-math/pull/71]- (removed; no future releases planned for v3.x) UPDATE [2017-12-23]: Split initial pull request into two separate ones: - SubOrientedPoint changes: [https://github.com/apache/commons-math/pull/72] - PolygonsSet changes: [https://github.com/apache/commons-math/pull/73 ] was: These are two separate issues that I found while using the partitioning code from 3.5 to work with complex solid models. The issues are: 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent hyperplane. This causes issues when working with a tolerance other than the default. 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on infinite line segments. An IndexOutOfBoundsException is thrown when a PolygonsSet is created with a single infinite SubLine as a boundary and a NullPointerException is thrown when one is created with a mix of finite and finite boundaries. I will be attaching a pull request shortly with fixes and unit tests. UPDATE: Pull request for v4.0: https://github.com/apache/commons-math/pull/70 -Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71- (removed; no future releases planned for v3.x) > PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues > > > Key: MATH-1436 > URL: https://issues.apache.org/jira/browse/MATH-1436 > Project: Commons Math > Issue Type: Bug >Affects Versions: 4.0, 3.5, 3.6, 3.6.1 >Reporter: Matt Juntunen > Fix For: 4.0, 3.6.1 > > > These are two separate issues that I found while using the partitioning code > from 3.5 to work with complex solid models. The issues are: > 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses > a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent > hyperplane. This causes issues when working with a tolerance other than the > default. > 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on > infinite line segments. An IndexOutOfBoundsException is thrown when a > PolygonsSet is created with a single infinite SubLine as a boundary and a > NullPointerException is thrown when one is created with a mix of finite and > finite boundaries. > I will be attaching a pull request shortly with fixes and unit tests. > UPDATE: > -Pull request for v4.0: [https://github.com/apache/commons-math/pull/70]- > -Pull request for v3.6.x: [https://github.com/apache/commons-math/pull/71]- > (removed; no future releases planned for v3.x) > UPDATE [2017-12-23]: > Split initial pull request into two separate ones: > - SubOrientedPoint changes: [https://github.com/apache/commons-math/pull/72] > - PolygonsSet changes: [https://github.com/apache/commons-math/pull/73 ] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (MATH-1436) PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
[
https://issues.apache.org/jira/browse/MATH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated MATH-1436:
Description:
These are two separate issues that I found while using the partitioning code
from 3.5 to work with complex solid models. The issues are:
1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a
hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
hyperplane. This causes issues when working with a tolerance other than the
default.
2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
infinite line segments. An IndexOutOfBoundsException is thrown when a
PolygonsSet is created with a single infinite SubLine as a boundary and a
NullPointerException is thrown when one is created with a mix of finite and
finite boundaries.
I will be attaching a pull request shortly with fixes and unit tests.
UPDATE:
Pull request for v4.0: https://github.com/apache/commons-math/pull/70
-Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71-
(removed; no future releases planned for v3.x)
was:
These are two separate issues that I found while using the partitioning code
from 3.5 to work with complex solid models. The issues are:
1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a
hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
hyperplane. This causes issues when working with a tolerance other than the
default.
2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
infinite line segments. An IndexOutOfBoundsException is thrown when a
PolygonsSet is created with a single infinite SubLine as a boundary and a
NullPointerException is thrown when one is created with a mix of finite and
finite boundaries.
I will be attaching a pull request shortly with fixes and unit tests.
UPDATE:
Pull request for v4.0: https://github.com/apache/commons-math/pull/70
{noformat}
Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71
{noformat}
(removed; no future releases planned for v3.x)
> PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
>
>
> Key: MATH-1436
> URL: https://issues.apache.org/jira/browse/MATH-1436
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.5, 3.6, 3.6.1
>Reporter: Matt Juntunen
> Fix For: 4.0, 3.6.1
>
>
> These are two separate issues that I found while using the partitioning code
> from 3.5 to work with complex solid models. The issues are:
> 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses
> a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
> hyperplane. This causes issues when working with a tolerance other than the
> default.
> 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
> infinite line segments. An IndexOutOfBoundsException is thrown when a
> PolygonsSet is created with a single infinite SubLine as a boundary and a
> NullPointerException is thrown when one is created with a mix of finite and
> finite boundaries.
> I will be attaching a pull request shortly with fixes and unit tests.
> UPDATE:
> Pull request for v4.0: https://github.com/apache/commons-math/pull/70
> -Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71-
> (removed; no future releases planned for v3.x)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (MATH-1436) PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
[
https://issues.apache.org/jira/browse/MATH-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated MATH-1436:
Description:
These are two separate issues that I found while using the partitioning code
from 3.5 to work with complex solid models. The issues are:
1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a
hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
hyperplane. This causes issues when working with a tolerance other than the
default.
2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
infinite line segments. An IndexOutOfBoundsException is thrown when a
PolygonsSet is created with a single infinite SubLine as a boundary and a
NullPointerException is thrown when one is created with a mix of finite and
finite boundaries.
I will be attaching a pull request shortly with fixes and unit tests.
UPDATE:
Pull request for v4.0: https://github.com/apache/commons-math/pull/70
{noformat}
Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71
{noformat}
(removed; no future releases planned for v3.x)
was:
These are two separate issues that I found while using the partitioning code
from 3.5 to work with complex solid models. The issues are:
1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses a
hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
hyperplane. This causes issues when working with a tolerance other than the
default.
2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
infinite line segments. An IndexOutOfBoundsException is thrown when a
PolygonsSet is created with a single infinite SubLine as a boundary and a
NullPointerException is thrown when one is created with a mix of finite and
finite boundaries.
I will be attaching a pull request shortly with fixes and unit tests.
UPDATE:
Pull request for v4.0: https://github.com/apache/commons-math/pull/70
-Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71 -
(removed; no future releases planned for v3.x)
> PolygonsSet Infinite Lines and SubOrientedPoint Tolerance Issues
>
>
> Key: MATH-1436
> URL: https://issues.apache.org/jira/browse/MATH-1436
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.5, 3.6, 3.6.1
>Reporter: Matt Juntunen
> Fix For: 4.0, 3.6.1
>
>
> These are two separate issues that I found while using the partitioning code
> from 3.5 to work with complex solid models. The issues are:
> 1. org.apache.commons.math[34].geometry.euclidean.oned.SubOrientedPoint uses
> a hardcoded tolerance of 1.0e-10 instead of the tolerance from the parent
> hyperplane. This causes issues when working with a tolerance other than the
> default.
> 2. org.apache.commons.math[34].geometry.euclidean.twod.PolygonsSet fails on
> infinite line segments. An IndexOutOfBoundsException is thrown when a
> PolygonsSet is created with a single infinite SubLine as a boundary and a
> NullPointerException is thrown when one is created with a mix of finite and
> finite boundaries.
> I will be attaching a pull request shortly with fixes and unit tests.
> UPDATE:
> Pull request for v4.0: https://github.com/apache/commons-math/pull/70
> {noformat}
> Pull request for v3.6.x: https://github.com/apache/commons-math/pull/71
> {noformat}
> (removed; no future releases planned for v3.x)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302520#comment-16302520
]
Oliver Heger commented on CONFIGURATION-684:
The problem is that the dot is the normal property delimiter character. If it
appears in a property name, it must be escaped.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302517#comment-16302517
]
Fabien Renaud commented on CONFIGURATION-684:
-
My original issues was with querying such dotted keys that did not appear to
exist in the config tree. It's only when I printed all the keys I realized they
were escape and wasn't sure whether this was desired behavior or not so I
opened this ticket.
Personally, I'd rather disable escaping of dots completely (and explicitly) and
trust whomever writes the config to not introduce dups.
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-684) YAMLConfiguration keys with double dots
[
https://issues.apache.org/jira/browse/CONFIGURATION-684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302507#comment-16302507
]
Oliver Heger commented on CONFIGURATION-684:
[~kinow], maybe I have not fully understood this ticket. I think the report is
only that the getKeys() method returns keys that are different from the
original keys if the configuration contains keys with dots. But this is the
normal behavior for all hierarchical configurations. Or do I miss something?
So my proposed fix would be to add a note to the Javadocs of getKeys().
> YAMLConfiguration keys with double dots
> ---
>
> Key: CONFIGURATION-684
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-684
> Project: Commons Configuration
> Issue Type: Bug
>Reporter: Fabien Renaud
>
> h2. Issue
> Loading a YAML configuration with dotted keys causes dots to be duplicated in
> the keys of the YAMLConfiguration object.
> h2. Repro
> 100% repro:
> file.yml:
> {code}some.key.with.dots: 123{code}
> {code}
> package foo;
> import org.apache.commons.configuration2.YAMLConfiguration;
> import
> org.apache.commons.configuration2.builder.FileBasedConfigurationBuilder;
> import org.apache.commons.configuration2.builder.fluent.Parameters;
> import org.apache.commons.configuration2.ex.ConfigurationException;
> public class App {
> public static void main(String[] args) throws ConfigurationException {
> Parameters params = new Parameters();
> FileBasedConfigurationBuilder builder1 =
> new FileBasedConfigurationBuilder<>(YAMLConfiguration.class)
>
> .configure(params.fileBased().setFileName("file.yml"));
>
> YAMLConfiguration conf = builder1.getConfiguration();
> conf.getKeys().forEachRemaining(System.out::println);
> System.out.println("---");
> YAMLConfiguration yaml = new YAMLConfiguration();
> yaml.read(new
> InputStreamReader(ClassLoader.getSystemResourceAsStream("file.yml")));
> yaml.getKeys().forEachRemaining(System.out::println);
> }
> }
> {code}
> prints
> {code}some..key..with..dots
> ---
> some..key..with..dots
> {code}
> That is a serious bug for a configuration system. The issue may easily go
> untested for some keys and only reveal itself on production.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IMAGING-209) PnmImageParser throws ImageWriteException when writing if PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
[
https://issues.apache.org/jira/browse/IMAGING-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved IMAGING-209.
Resolution: Fixed
Fix Version/s: 1.0
Merged, pull request closed, and changes.xml updated.
Thank you [~easypeasy] for your contribution!
Bruno
> PnmImageParser throws ImageWriteException when writing if
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
> --
>
> Key: IMAGING-209
> URL: https://issues.apache.org/jira/browse/IMAGING-209
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: PNM
>Reporter: Isak W
>Assignee: Bruno P. Kinoshita
> Fix For: 1.0
>
>
> Code sample:
> {code:java}
> Map params = new HashMap<>();
> params.put(PnmImageParser.PARAM_KEY_PNM_RAWBITS,
> PnmImageParser.PARAM_VALUE_PNM_RAWBITS_YES);
> Imaging.writeImage(image, file, ImageFormats.PNM, params);
> {code}
> Error message is: "Unknown parameter: PNM_RAWBITS:
> This happens because used parameters are cleared from the map after usage and
> any remaining parameters are determined to be unknown, but
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is never cleared.
> I will provide a patch on Github shortly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IMAGING-209) PnmImageParser throws ImageWriteException when writing if PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
[
https://issues.apache.org/jira/browse/IMAGING-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated IMAGING-209:
---
Assignee: Bruno P. Kinoshita
> PnmImageParser throws ImageWriteException when writing if
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
> --
>
> Key: IMAGING-209
> URL: https://issues.apache.org/jira/browse/IMAGING-209
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: PNM
>Reporter: Isak W
>Assignee: Bruno P. Kinoshita
>
> Code sample:
> {code:java}
> Map params = new HashMap<>();
> params.put(PnmImageParser.PARAM_KEY_PNM_RAWBITS,
> PnmImageParser.PARAM_VALUE_PNM_RAWBITS_YES);
> Imaging.writeImage(image, file, ImageFormats.PNM, params);
> {code}
> Error message is: "Unknown parameter: PNM_RAWBITS:
> This happens because used parameters are cleared from the map after usage and
> any remaining parameters are determined to be unknown, but
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is never cleared.
> I will provide a patch on Github shortly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IMAGING-209) PnmImageParser throws ImageWriteException when writing if PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
[
https://issues.apache.org/jira/browse/IMAGING-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302348#comment-16302348
]
ASF GitHub Bot commented on IMAGING-209:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-imaging/pull/33
> PnmImageParser throws ImageWriteException when writing if
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is provided
> --
>
> Key: IMAGING-209
> URL: https://issues.apache.org/jira/browse/IMAGING-209
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: PNM
>Reporter: Isak W
>
> Code sample:
> {code:java}
> Map params = new HashMap<>();
> params.put(PnmImageParser.PARAM_KEY_PNM_RAWBITS,
> PnmImageParser.PARAM_VALUE_PNM_RAWBITS_YES);
> Imaging.writeImage(image, file, ImageFormats.PNM, params);
> {code}
> Error message is: "Unknown parameter: PNM_RAWBITS:
> This happens because used parameters are cleared from the map after usage and
> any remaining parameters are determined to be unknown, but
> PnmImageParser.PARAM_KEY_PNM_RAWBITS is never cleared.
> I will provide a patch on Github shortly.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (NUMBERS-50) Clean checkstyle for Complex
[
https://issues.apache.org/jira/browse/NUMBERS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302320#comment-16302320
]
Amey Jadiye commented on NUMBERS-50:
bq. No, but it is not necessary to explicitly "suppress" it since running mvn
clean site does not report any error.
This looks very strange to me, curious how {{mvn clean verify}} is failing but
now {{mvn clean site}}
bq. Anyways, it looks like this report can be resolved since as of today there
is no checkstyle violations in the module commons-numbers-complex
hmm, I also feel to close this. one more option is to change the subject and
extend the scope to solve all the checkstyle errors.
> Clean checkstyle for Complex
>
>
> Key: NUMBERS-50
> URL: https://issues.apache.org/jira/browse/NUMBERS-50
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Eric Barnhill
>Priority: Trivial
>
> Clean up trailing whitespaces and other checkstyle violations in
> commons-numbers-complex
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
