[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974228#comment-15974228 ] Joerg Schaible commented on CONFIGURATION-656: -- An uber jar for a library is always a bad idea. Better is a shallow jar that depends on all others. Same effect but no class can appear twice on CP. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
Gunel Jahangirova created MATH-1414:
---
Summary: Method reciprocal() in Complex for complex numbers with
parts very close to 0.0
Key: MATH-1414
URL: https://issues.apache.org/jira/browse/MATH-1414
Project: Commons Math
Issue Type: Improvement
Reporter: Gunel Jahangirova
Priority: Minor
In class Complex the method reciprocal() returns INF only if the real and
imaginary parts are equal exactly to 0.0. In case of real and imaginary parts,
being double numbers very close to 0.0, it does not hold. For example, if we
run this code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunel Jahangirova updated MATH-1414:
Description:
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In case of real and imaginary parts are double
numbers very close to 0.0, it does not hold. For example, if we run this code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
was:
In class Complex the method reciprocal() returns INF only if the real and
imaginary parts are equal exactly to 0.0. In case of real and imaginary parts,
being double numbers very close to 0.0, it does not hold. For example, if we
run this code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In case of real and imaginary parts
> are double numbers very close to 0.0, it does not hold. For example, if we
> run this code
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gunel Jahangirova updated MATH-1414:
Description:
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In the cases when real and imaginary parts are
double numbers very close to 0.0, it does not hold. For example, if we run this
code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
was:
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In case of real and imaginary parts are double
numbers very close to 0.0, it does not hold. For example, if we run this code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated MATH-1414:
-
Description:
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In the cases when real and imaginary parts are
double numbers very close to 0.0, it does not hold. For example, if we run this
code
{code}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
{code}
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
{code}
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
{code}
should be replaced by the equality check with some tolerance (0.01 in this
case):
{code}
if (equals(this, ZERO, 0.01)) {
return INF;
}
{code}
was:
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In the cases when real and imaginary parts are
double numbers very close to 0.0, it does not hold. For example, if we run this
code
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
I think the code in the method
if (real == 0.0 && imaginary == 0.0) {
return INF;
}
should be replaced by the equality check with some tolerance (0.01 in this
case):
if (equals(this, ZERO, 0.01)) {
return INF;
}
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974436#comment-15974436
]
Bruno P. Kinoshita commented on MATH-1414:
--
Should this 0.01 value be parameterized? i.e. should we maybe keep the current
behaviour, but give users a method like reciprocal(Double threshold) ?
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (LANG-1272) Array shuffling
[
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated LANG-1272:
-
Assignee: Emmanuel Bourg
> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Emmanuel Bourg
>Priority: Minor
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the
> content of an array (Objects or primitives). This would be similar to the
> {{java.util.Collections.shuffle()}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974486#comment-15974486
]
Raymond DeCampo commented on MATH-1414:
---
0.01 is way too large of a tolerance.
I think a better approach would be to detect if one of the real or imaginary
parts is going to be infinite or NaN and then return the proper result. We
need to determine what the desired result in this situation is, e.g. in the
example above one could make a case for {{Complex.INF}};
{{Double.NEGATIVE_INFINTITY}} or {{Double.POSITIVE_INFINITY}} (where the last
two have imaginary part zero).
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974508#comment-15974508
]
Gunel Jahangirova commented on MATH-1414:
-
In case of Complex(0.0, 0.0) the value calculated for reciprocal is (Infinity,
NaN) and the current implementation returns Inf. Similarly, we could return
Double.NEGATIVE_INFINITY, if the real part of the result is
Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY in case it is
Double.POSITIVE_INFINITY.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974508#comment-15974508
]
Gunel Jahangirova edited comment on MATH-1414 at 4/19/17 12:00 PM:
---
In case of Complex(0.0, 0.0) the value calculated for reciprocal is (Infinity,
NaN) and the current implementation returns Inf. Similarly, we could return
{code}Double.NEGATIVE_INFINITY{code}, if the real part of the result is
{code}Double.NEGATIVE_INFINITY{code} and {code}Double.POSITIVE_INFINITY{code}
in case it is {code}Double.POSITIVE_INFINITY{code}.
was (Author: gjahanagirova):
In case of Complex(0.0, 0.0) the value calculated for reciprocal is (Infinity,
NaN) and the current implementation returns Inf. Similarly, we could return
Double.NEGATIVE_INFINITY, if the real part of the result is
Double.NEGATIVE_INFINITY and Double.POSITIVE_INFINITY in case it is
Double.POSITIVE_INFINITY.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974526#comment-15974526
]
Gilles commented on MATH-1414:
--
Please open a report on https://issues.apache.org/jira/browse/NUMBERS since
this {{Complex}} class will likely be deprecated in favour of its equivalent in
"Commons Numbers".
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974536#comment-15974536
]
Tim Allison commented on COMPRESS-387:
--
[~thetaphi] explains here: https://issues.apache.org/jira/browse/TIKA-1757
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974537#comment-15974537
]
Tim Allison commented on COMPRESS-387:
--
And, thank you!!!
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (NUMBERS-22) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
Gunel Jahangirova created NUMBERS-22:
Summary: Method reciprocal() in Complex for complex numbers with
parts very close to 0.0
Key: NUMBERS-22
URL: https://issues.apache.org/jira/browse/NUMBERS-22
Project: Commons Numbers
Issue Type: Improvement
Reporter: Gunel Jahangirova
Priority: Minor
I have been redirected here from the issue repository of Apache Commons Math,
as the Complex class will likely be deprecated in favour of its equivalent in
"Commons Numbers".
In class Complex method reciprocal() returns INF only if the real and imaginary
parts are exactly equal to 0.0. In the cases when real and imaginary parts are
double numbers very close to 0.0, it does not hold. For example, if we run this
code
{code}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
{code}
the value of complex1.getReal() will be -Infinity and the value of
complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
The suggested solutions after the discussion are either checking the equality
to ZERO with some tolerance or to detect if one of the real or imaginary parts
is going to be infinite or NaN and then return the proper result.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974539#comment-15974539
]
Tim Allison commented on COMPRESS-385:
--
bq. I can imagine that Tika would benefit from detecting a 7z archive as well.
Y. Thank you!
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974564#comment-15974564
]
Stefan Bodewig commented on COMPRESS-387:
-
> Uwe Schindler explains here: https://issues.apache.org/jira/browse/TIKA-1757
Thanks, we probably don't need the {{getPath()}} at all but could rather stop
right after {{toURI()}}.
I've grepped through the code and it looks as if we didn't use similar
constructs anywhere else, fortunately.
What really puzzled me is why we were getting an NPE at the point where we use
{{ARCDIR}}, by now I think it is {{list}} returning {{null}} because {{ARCDIR}}
didn't exist. One of the many {{File}}-APIs with broken semantics.
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974583#comment-15974583
]
Tim Allison commented on COMPRESS-387:
--
right. Of course...
You are correct on the NPE. The path had a %20 in it, and the operating system
couldn't find it, so NPE.
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CONFIGURATION-656) YAML Configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
The Alchemist updated CONFIGURATION-656:
Attachment: commons-configuration2-yaml.support.patch
Attached patch against trunk to add YAML support using SnakeYAML.
Test coverage is pretty good. Do you guys want a separate
{{configuration2-yaml}} module?
> YAML Configuration
> --
>
> Key: CONFIGURATION-656
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-656
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Reporter: Gary Gregory
> Attachments: commons-configuration2-yaml.support.patch
>
>
> Like the missing JSON Configuration, we really should also support YAML.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974637#comment-15974637
]
The Alchemist commented on CONFIGURATION-258:
-
@[~ebourg]: I can't find a {{JSONConfiguration}} in 2.0. Am I missing
something?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Assignee: Emmanuel Bourg
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974637#comment-15974637
]
The Alchemist edited comment on CONFIGURATION-258 at 4/19/17 1:26 PM:
--
@[~ebourg]: I can't find a {{JSONConfiguration}} in 2.x. Am I missing
something?
was (Author: the_alchemist):
@[~ebourg]: I can't find a {{JSONConfiguration}} in 2.0. Am I missing
something?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Assignee: Emmanuel Bourg
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974637#comment-15974637
]
The Alchemist edited comment on CONFIGURATION-258 at 4/19/17 1:26 PM:
--
@[~ebourg]: I can't find a {{JSONConfiguration}} in 2.x or trunk. Am I missing
something?
was (Author: the_alchemist):
@[~ebourg]: I can't find a {{JSONConfiguration}} in 2.x. Am I missing
something?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Assignee: Emmanuel Bourg
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg updated CONFIGURATION-258:
-
Assignee: (was: Emmanuel Bourg)
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974672#comment-15974672
]
Emmanuel Bourg commented on CONFIGURATION-258:
--
It was on the experimental branch for configuration2:
http://svn.apache.org/repos/asf/commons/proper/configuration/branches/configuration2_experimental/src/main/java/org/apache/commons/configuration2/json/
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Assignee: Emmanuel Bourg
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974689#comment-15974689
]
The Alchemist commented on CONFIGURATION-258:
-
@[~ebourg]: Looks like it uses the now-defunct {{ConfigurationNode}}, which
was removed as part of CONFIGURATION-575.
I can:
* try to re-vive this custom parser
* just use the Nashorn javascript engine to parse JSON, which will work on the
(Oracle) VM 7 and above
* use jackson's JSON parser
Perhaps a {{commons-configuration2-jackson}} module would be useful if you
wanna go with that approach? Just let me know which one you want to use and
I'll code it up.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974720#comment-15974720
]
Emmanuel Bourg commented on CONFIGURATION-258:
--
I have no preference, if you can reuse the javacc parser that's great but
jackson is fine too. Nashorn is Java 8+ only and commons-configuration isn't
there yet.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974750#comment-15974750
]
The Alchemist commented on CONFIGURATION-258:
-
Sorry, I mis-spoke. Java 7 comes with a Javascript engine too (Rhino-based
instead of Nashorn-based).
But you'd prefer jackson/javacc parser versus the built-in Javascript engine?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (LANG-925) Deprecate o.a.c.lang.time.* package
[ https://issues.apache.org/jira/browse/LANG-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-925: --- Issue Type: Sub-task (was: Task) Parent: LANG-923 > Deprecate o.a.c.lang.time.* package > --- > > Key: LANG-925 > URL: https://issues.apache.org/jira/browse/LANG-925 > Project: Commons Lang > Issue Type: Sub-task > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Benedikt Ritter > Fix For: Discussion > > > We have discussed [1] to deprecate the time package, because it will become > obsolete in Java 8. > [1] http://markmail.org/message/uw3lggwkt5ul5b7k -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-1165) FastDateFormat should extend DateFormat
[
https://issues.apache.org/jira/browse/LANG-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher closed LANG-1165.
---
Resolution: Won't Fix
Closed after reading Charles Hontons comment:
{quote}
Unfortunately, having FastDateFormat extend DateFormat causes multiple final
method violations: All of the static getInstance() and getDateInstance methods
are final in DataFormat.
{quote}
> FastDateFormat should extend DateFormat
> ---
>
> Key: LANG-1165
> URL: https://issues.apache.org/jira/browse/LANG-1165
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
>Affects Versions: 3.4
>Reporter: Michael Osipov
>
> Current FDT extends {{Format}} only, thus making it impossible to replace SDF
> where {{DateFormat}} is accepted.
> I am using Jackson's {{ObjectMapper}} which has a {{#setDateFormat}} method.
> But -- it accepts {{DateFormat}}. Impossible to use FDT.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-80) StrLookup API confusing
[ https://issues.apache.org/jira/browse/TEXT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974928#comment-15974928 ] Pascal Schumacher commented on TEXT-80: --- Issue moved from commons-lang to commons-text, because StrLookup was ported to commons-text and and the commons-lang version will soon be deprecated. > StrLookup API confusing > --- > > Key: TEXT-80 > URL: https://issues.apache.org/jira/browse/TEXT-80 > Project: Commons Text > Issue Type: Bug >Reporter: Etienne Neveu > > [bayard: copying this from LANG-564] > I don't see the point of having a generic type parameter on the StrLookup > class, if it's not used anywhere. No method / field in StrLookup references > this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter > 'V' is never used". Moreover, Java generics are not reified, so there is no > reliable way to access the type parameter at runtime (and I don't see the > point of doing that anyway...). > While the Javadoc tries to clarify the purpose of a StrLookup, the unused > type parameter is still confusing, and the client code has to un-necessarily > specify type parameters. For example, I have to write: > StrLookup lookup = StrLookup.noneLookup(); > StrLookup lookup2 = StrLookup.systemPropertiesLookup(); > StrLookup lookup3 = StrLookup.mapLookup(integerMap); > instead of > StrLookup lookup = StrLookup.noneLookup(); > StrLookup lookup2 = StrLookup.systemPropertiesLookup(); > StrLookup lookup3 = StrLookup.mapLookup(integerMap); > My best guess is that this type parameter was added when commons-lang was > generified, because StringLookup.mapLookup() takes a generified Map. Doing > this is not really needed, though: we could remove the type parameter > everywhere, and replace the StrLookup.mapLookup()'s Map with a > Map (which is the same as Map, but > shorter). > I guess it's too late to change this now, due to backward compatibility... > But I thought I'd comment just in case it's still possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Moved] (TEXT-80) StrLookup API confusing
[ https://issues.apache.org/jira/browse/TEXT-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher moved LANG-745 to TEXT-80: Fix Version/s: (was: Discussion) Affects Version/s: (was: 3.0) Component/s: (was: lang.*) Workflow: jira (was: Default workflow, editable Closed status) Key: TEXT-80 (was: LANG-745) Project: Commons Text (was: Commons Lang) > StrLookup API confusing > --- > > Key: TEXT-80 > URL: https://issues.apache.org/jira/browse/TEXT-80 > Project: Commons Text > Issue Type: Bug >Reporter: Etienne Neveu > > [bayard: copying this from LANG-564] > I don't see the point of having a generic type parameter on the StrLookup > class, if it's not used anywhere. No method / field in StrLookup references > this type parameter. IntelliJ IDEA itself reports a warning: "Type parameter > 'V' is never used". Moreover, Java generics are not reified, so there is no > reliable way to access the type parameter at runtime (and I don't see the > point of doing that anyway...). > While the Javadoc tries to clarify the purpose of a StrLookup, the unused > type parameter is still confusing, and the client code has to un-necessarily > specify type parameters. For example, I have to write: > StrLookup lookup = StrLookup.noneLookup(); > StrLookup lookup2 = StrLookup.systemPropertiesLookup(); > StrLookup lookup3 = StrLookup.mapLookup(integerMap); > instead of > StrLookup lookup = StrLookup.noneLookup(); > StrLookup lookup2 = StrLookup.systemPropertiesLookup(); > StrLookup lookup3 = StrLookup.mapLookup(integerMap); > My best guess is that this type parameter was added when commons-lang was > generified, because StringLookup.mapLookup() takes a generified Map. Doing > this is not really needed, though: we could remove the type parameter > everywhere, and replace the StrLookup.mapLookup()'s Map with a > Map (which is the same as Map, but > shorter). > I guess it's too late to change this now, due to backward compatibility... > But I thought I'd comment just in case it's still possible. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974935#comment-15974935
]
Emmanuel Bourg commented on CONFIGURATION-258:
--
That's up to you. A JSONConfiguration based on javax.script could be
interesting too, probably slower than a javacc parser, but performance isn't
really critical here.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-70) Build failure with java 9-ea+159
[
https://issues.apache.org/jira/browse/TEXT-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974937#comment-15974937
]
Pascal Schumacher commented on TEXT-70:
---
The maven findbugs plugin need to update to groovy 2.4.8+ and release a new
version for this to work.
> Build failure with java 9-ea+159
>
>
> Key: TEXT-70
> URL: https://issues.apache.org/jira/browse/TEXT-70
> Project: Commons Text
> Issue Type: Bug
>Affects Versions: 1.0-beta-1
> Environment: $ mvn -X
> Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> 2015-11-10T11:41:47-05:00)
> Maven home: /usr/local/Cellar/maven/3.3.9/libexec
> Java version: 9-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "10.12.3", arch: "x86_64", family: "mac"
>Reporter: Rob Tompkins
> Fix For: 1.x
>
>
> {{mvn -X clean site}} fails with the following error trace (noting that this
> feels more like a bug with the maven-site-plugin than with our
> code...regardless it's worth logging):
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on project
> commons-text: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make
> private java.io.File(java.lang.String,java.io.File) accessible: module
> java.base does not "opens java.io" to unnamed module @47313e46 -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-site-plugin:3.6:site (default-site) on
> project commons-text: Execution default-site of goal
> org.apache.maven.plugins:maven-site-plugin:3.6:site failed: Unable to make
> private java.io.File(java.lang.String,java.io.File) accessible: module
> java.base does not "opens java.io" to unnamed module @47313e46
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:547)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
> default-site of goal org.apache.maven.plugins:maven-site-plugin:3.6:site
> failed: Unable to make private java.io.File(java.lang.String,java.io.File)
> accessible: module java.base does not "opens java.io" to unnamed module
> @47313e46
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:145)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
> ... 20 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> private java.io.File(java.lang.String,java.io.File) accessible: module
> java.base does not "opens java.io" to unnamed module @47313e46
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:335)
> at
> java.base/java.lang.reflect.AccessibleObject.chec
[jira] [Closed] (LANG-742) [IgnoreCase] methods for ArrayUtils
[ https://issues.apache.org/jira/browse/LANG-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-742. -- Resolution: Won't Fix Fix Version/s: (was: Review Patch) No comments for over 5 years. I guess this feature is a bit too specific for commons-lang, so I'm closing this. > [IgnoreCase] methods for ArrayUtils > --- > > Key: LANG-742 > URL: https://issues.apache.org/jira/browse/LANG-742 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* >Reporter: Michael Lyons >Priority: Minor > Attachments: StringArrayUtils.java, StringArrayUtilsTest.java > > > This is a proposal for a feature addition. > On several projects, I've needed to perform case insensitive manipulation on > Arrays of Strings. My original need was just a solution for > containsIgnoreCase(String[], String) and indexOfIgnoreCase(String[], String). > In an effort to keep things simple, I created this class which implements 8 > [IgnoreCase] methods that could be a benefit to Commons Lang users. > StringArrayUtils extends ArrayUtils, it provides case insensitive > manipulation on an Array of Strings. > The new methods provided in the class are: > containsIgnoreCase(String[] array, String stringToFind) > indexOfIgnoreCase(String[] array, String stringToFind) > indexOfIgnoreCase(String[] array, String stringToFind, int startIndex) > isEqualsIgnoreCase(String[] array1, String[] array2) > lastIndexOfIgnoreCase(String[] array, String stringToFind) > lastIndexOfIgnoreCase(String[] array, String stringToFind, int startIndex) > removeElementIgnoreCase(String[] array, String element) > removeElementsIgnoreCase(String[] array, String... values) > These eight methods cover the functional pattern provided in ArrayUtils. Any > comparison in ArrayUtils based on obj1.equals(obj2) now has an equivalent > str1.equalsIgnoreCase(str2) in StringArrayUtils. > I've included a test case and have made efforts to match your coding > convention and style. Thanks in advance for your time and consideration. I'd > be happy to follow up with any changes or edits if you think this is > something that might be included in a future version of Commons Lang. > ...Mike > Ps. I understand that handling a special case for the String's > equalsIgnoreCase(...) may be a slippery slope - which has been intentionally > avoided. I have also considered overloading the above eight methods with a > Comparator parameter, but requiring a user to pass in a not-null, > case-insensitive comparator didn't seem as straight forward as the above > solution. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-595) JDK 1.6 changes
[ https://issues.apache.org/jira/browse/LANG-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-595. -- Resolution: Won't Fix Fix Version/s: (was: 4.0) java.util.Arrays#copyOf does not allow null, which ArrayUtils#clone allows, so it is not a direct replacement. As commons-lang now uses java 7 I'm closing this issue. > JDK 1.6 changes > --- > > Key: LANG-595 > URL: https://issues.apache.org/jira/browse/LANG-595 > Project: Commons Lang > Issue Type: Task > Components: General >Reporter: Henri Yandell > > List of Java 6 related changes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-647) ToStringBuilder output makes it difficult to distinguish between an empty String array and an array of one empty String
[
https://issues.apache.org/jira/browse/LANG-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-647:
---
Summary: ToStringBuilder output makes it difficult to distinguish between
an empty String array and an array of one empty String (was: ToStringBuilder
output makes it difficult to distinguich between an empty String array and an
array of one empty String)
> ToStringBuilder output makes it difficult to distinguish between an empty
> String array and an array of one empty String
> ---
>
> Key: LANG-647
> URL: https://issues.apache.org/jira/browse/LANG-647
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Affects Versions: 2.5
>Reporter: pascal jacob
>Priority: Minor
> Fix For: Patch Needed
>
>
> ToStringBuilder output is the same for an empty array (i.e. new String[0])
> and for an array containing only a single empty string (i.e. new String[] {
> "" } ). This makes it difficult in some case to see the true nature of
> arrays.
> For example I once had a JUnit test case that print the following trace
> failure:
> java.lang.AssertionError:
> Expected:
> got:
> Apparently the two objects look like the same! But they are not: one had an
> empty array; the other had an array with only a single empty string. With a
> customized ToStringStyle the difference became apparent:
> Expected:
> got:
> The fix is simple, change the method: protected void
> appendDetail(StringBuffer buffer, String fieldName, Object value) to:
> protected void appendDetail(StringBuffer buffer, String
> fieldName, Object value) {
> if((value instanceof String) &&
> ((String)value).isEmpty()) {
> buffer.append("\"\"");
> }
> else {
> super.appendDetail(buffer, fieldName,
> value);
> }
> }
>
> here is the test case that revealed the problem:
> public void testToStringBuilder() {
> ToStringBuilder builder1 = new ToStringBuilder("Builder1");
> builder1.append("empty array", new String[0]);
> builder1.append("array of one empty string", new String[] { ""
> });
> builder1.append("array of two empty strings", new String[] {
> "", "" });
> String builder1Result = builder1.toString();
> System.out.println(builder1Result);
> // -
> ToStringBuilder builder2 = new ToStringBuilder("Builder2", new
> ToStringStyle() {
> @Override
> protected void appendDetail(StringBuffer buffer, String
> fieldName, Object value) {
> if((value instanceof String) &&
> ((String)value).isEmpty()) {
> buffer.append("\"\"");
> }
> else {
> super.appendDetail(buffer, fieldName,
> value);
> }
> }
> });
> builder2.append("empty array", new String[0]);
> builder2.append("array of one empty string", new String[] { ""
> });
> builder2.append("array of two empty strings", new String[] {
> "", "" });
> String builder2Result = builder2.toString();
> System.out.println(builder2Result);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (JCS-176) RemoteCacheNoWaitFacade constructor throws ConcurrentModificationException
Dan Griffith created JCS-176: Summary: RemoteCacheNoWaitFacade constructor throws ConcurrentModificationException Key: JCS-176 URL: https://issues.apache.org/jira/browse/JCS-176 Project: Commons JCS Issue Type: Bug Components: RMI Remote Cache Affects Versions: jcs-2.1 Reporter: Dan Griffith RemoteCacheNoWaitFacade constructor throws a ConcurrentModificationException in line 73 attempting to add to the collection it is traversing in the enhanced for loop. Exception is swallowed in the org.apache.commons.jcs.engine.control.CompositeCacheConfigurator parseAuxiliary() method which logs the statement "Could not instantiate auxiliary cache named ...". This prevents client from communicating changes to the remote cache. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TEXT-78) Investigate adding a spell checker
[ https://issues.apache.org/jira/browse/TEXT-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed TEXT-78. - > Investigate adding a spell checker > -- > > Key: TEXT-78 > URL: https://issues.apache.org/jira/browse/TEXT-78 > Project: Commons Text > Issue Type: New Feature >Reporter: Bruno P. Kinoshita >Priority: Minor > Labels: help-wanted, spellcheck, spellchecker, spelling, text > > There are already spell checkers such as > [Hunspell|http://hunspell.github.io/] (which has its own API to define > suffixes and prefix), and simpler spell checkers like [jazzy > (forked)|https://github.com/reckart/jazzy]. > Hunspell (GPL/mixed) is written in C++, and Java programs that use it > normally use native access through > [BridJ|https://github.com/thomas-joiner/HunspellBridJ]/[JNA|https://github.com/dren-dk/HunspellJNA]. > Jazzy (LGPL) is good, but not actively maintained, and simply looks up words > from a dictionary. > We can provide a simple interface, and perhaps one or two different spell > checkers in pure Java. > Having edit distances already in the project, we could investigate something > such as adding a [BK-Tree|https://en.wikipedia.org/wiki/BK-tree], an > in-memory look-up spell checker, etc. > When creating the initial interfaces & design, it will be important to > remember that we want to support multiple languages too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #262: Findbugs in Travis CI
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/262 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #262: Findbugs in Travis CI
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/262 Thanks! :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (LANG-1272) Array shuffling
[
https://issues.apache.org/jira/browse/LANG-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved LANG-1272.
--
Resolution: Fixed
Fix Version/s: 3.6
> Array shuffling
> ---
>
> Key: LANG-1272
> URL: https://issues.apache.org/jira/browse/LANG-1272
> Project: Commons Lang
> Issue Type: Improvement
>Reporter: Emmanuel Bourg
>Assignee: Emmanuel Bourg
>Priority: Minor
> Fix For: 3.6
>
>
> I'd like to suggest the addition of methods in ArrayUtils shuffling the
> content of an array (Objects or primitives). This would be similar to the
> {{java.util.Collections.shuffle()}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975088#comment-15975088
]
Gary Gregory commented on CONFIGURATION-258:
There is also Google Gson which I've used a plenty and is quite good. This
component already depends on other libraries, so one more is OK by me.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975111#comment-15975111
]
Uwe Schindler commented on COMPRESS-387:
bq. Thanks, we probably don't need the getPath() at all but could rather stop
right after toURI().
Yes, that's the correct way to do it. Using getPath() on the URI may break,
too. The correct way (see also the Maven project's code guidelines about
URL/URI/File and Classpath) is to convert the URL to an URI and pass the URI to
the File ctor:
https://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths
(although this is outdated, as newer Java versions have URL.toURI() that works
correct.
This is "the correct way" to do this:
{code:java}
URL u = foobar.getResource("...");
File f = new File(u.toURI());
{code}
Nevertheless, I'd prefer to get an InputStream directly, as the test suite
would fail, if the resources are in a JAR file for some reason (IDE,...).
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975111#comment-15975111
]
Uwe Schindler edited comment on COMPRESS-387 at 4/19/17 5:18 PM:
-
bq. Thanks, we probably don't need the getPath() at all but could rather stop
right after toURI().
Yes, that's the correct way to do it. Using getPath() on the URI may break,
too. The correct way (see also the Maven project's code guidelines about
URL/URI/File and Classpath) is to convert the URL to an URI and pass the URI to
the File ctor:
https://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths
(although the comments are a bit outdated, as newer Java versions have
URL.toURI() that works correct).
This is "the correct way" to do this:
{code:java}
URL u = foobar.getResource("...");
File f = new File(u.toURI());
{code}
Nevertheless, I'd prefer to get an InputStream directly, as the test suite
would fail, if the resources are in a JAR file for some reason (IDE,...).
was (Author: thetaphi):
bq. Thanks, we probably don't need the getPath() at all but could rather stop
right after toURI().
Yes, that's the correct way to do it. Using getPath() on the URI may break,
too. The correct way (see also the Maven project's code guidelines about
URL/URI/File and Classpath) is to convert the URL to an URI and pass the URI to
the File ctor:
https://maven.apache.org/plugin-developers/common-bugs.html#Converting_between_URLs_and_Filesystem_Paths
(although this is outdated, as newer Java versions have URL.toURI() that works
correct.
This is "the correct way" to do this:
{code:java}
URL u = foobar.getResource("...");
File f = new File(u.toURI());
{code}
Nevertheless, I'd prefer to get an InputStream directly, as the test suite
would fail, if the resources are in a JAR file for some reason (IDE,...).
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975144#comment-15975144
]
Joerg Schaible commented on CONFIGURATION-258:
--
Usage of the JavaScript interpreter is a bad idea, because it's evaluation not
limited to JSON, but will evaluate any kind of JavaScript expression opening
even security issues:
{code:javascript}
{
"regexp": /foo/,
"oops": new java.lang.ProcessBuilder(new java.lang.String("notepad.exe"),
new java.lang.String("c:\\boot.ini")).start()
}
{code}
Not sure, if I got it right directly by heart, but you get the idea. A real
JSON parser does not allow this at all.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975178#comment-15975178
]
The Alchemist commented on CONFIGURATION-258:
-
@[~joehni]: Good call. If we limit ourselves to Java 8, we can use
[ScriptObjectMirror.wrapAsJSONCompatible()|https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/ScriptObjectMirror.html#wrapAsJSONCompatible-java.lang.Object-java.lang.Object-]
but it seems like an external library is the way to go.
The
[org.json|http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.json%22%20AND%20a%3A%22json%22]
is nice small library (~55KB). Any objections to that?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975178#comment-15975178
]
The Alchemist edited comment on CONFIGURATION-258 at 4/19/17 6:30 PM:
--
@[~joehni]: Good call. If we limit ourselves to Java 8, we can use
[ScriptObjectMirror.wrapAsJSONCompatible()|https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/ScriptObjectMirror.html#wrapAsJSONCompatible-java.lang.Object-java.lang.Object-]
but it seems like an external library is the way to go.
I was thinking about using the
[org.json|http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.json%22%20AND%20a%3A%22json%22]
library which is nice and small, but it gave me too much trouble, so I've
attached a patch that uses Jackson's JSON support.
P.S. I was thinking about creating a separate
{{commons-configuration2-jackson}} module, but the package structure isn't
really conducive to that. Ideally, everything out of the root module and turn
it into type POM.
was (Author: the_alchemist):
@[~joehni]: Good call. If we limit ourselves to Java 8, we can use
[ScriptObjectMirror.wrapAsJSONCompatible()|https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/ScriptObjectMirror.html#wrapAsJSONCompatible-java.lang.Object-java.lang.Object-]
but it seems like an external library is the way to go.
The
[org.json|http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.json%22%20AND%20a%3A%22json%22]
is nice small library (~55KB). Any objections to that?
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
The Alchemist updated CONFIGURATION-258:
Attachment: commons-configuration2-yaml.and.json.support.diff
YAML and JSON support are combined here because they both share the same
superclass, which provides helpers for {{Map}}.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975250#comment-15975250
]
The Alchemist edited comment on CONFIGURATION-258 at 4/19/17 6:32 PM:
--
YAML and JSON support are combined at
[^commons-configuration2-yaml.and.json.support.diff] because they both share
the same superclass, which provides helpers for {{Map}}.
was (Author: the_alchemist):
YAML and JSON support are combined here because they both share the same
superclass, which provides helpers for {{Map}}.
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975314#comment-15975314 ] Oliver Heger commented on CONFIGURATION-656: Configuration would certainly benefit from a more modular design. However, I am not sure whether this can be achieved without breaking compatibility. We would probably also need some kind of service loader mechanism to bring the pieces together again for a combined configuration. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > Attachments: commons-configuration2-yaml.support.patch > > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975323#comment-15975323
]
Emmanuel Bourg commented on CONFIGURATION-258:
--
Note that the org.json library can't be used because its license has a field of
use restriction (the famous "The Software shall be used for Good, not Evil"
clause).
> JSON configuration
> --
>
> Key: CONFIGURATION-258
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-258
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Affects Versions: 1.3
>Reporter: Antonio López-Cerón Vivo
>Priority: Minor
> Fix For: 2.x
>
> Attachments: commons-configuration2-yaml.and.json.support.diff
>
>
> JSON is a lightweight data-interchange format
> {code}
> {"menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {"value": "New", "onclick": "CreateNewDoc()"},
> {"value": "Open", "onclick": "OpenDoc()"},
> {"value": "Close", "onclick": "CloseDoc()"}
> ]
> }
> }}
> {code}
> All references can be located at
> http://www.json.org/
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975321#comment-15975321 ] Gary Gregory commented on CONFIGURATION-656: We could start work on a version 3... with a modular design. > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > Attachments: commons-configuration2-yaml.support.patch > > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (IO-531) make it more esay-to-use: org.apache.commons.io.FileUtils.listFiles(File, IOFileFilter, IOFileFilter)
[ https://issues.apache.org/jira/browse/IO-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975579#comment-15975579 ] Sebb commented on IO-531: - Sorry, but I'm still not clear what you want the null parameter to do. Can you provide a test case? Or at least a description of a simple directory structure and the results you want to get. This will be needed to generate a unit test for any changes that might be made. > make it more esay-to-use: org.apache.commons.io.FileUtils.listFiles(File, > IOFileFilter, IOFileFilter) > - > > Key: IO-531 > URL: https://issues.apache.org/jira/browse/IO-531 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 2.5 >Reporter: Hao Liu > > when I only want to filter the directories, it should be better to allow me > to set the second parameter to null or I have to implement the > org.apache.commons.io.filefilter.IOFileFilter interface with nothing > functionally task to do. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (DBUTILS-128) Can't execute subquery when use parameters
[ https://issues.apache.org/jira/browse/DBUTILS-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] inthink updated DBUTILS-128: Priority: Blocker (was: Major) Description: Oracle Database: ``` SQL> desc dept Name Null?Type - DEPTNONOT NULL NUMBER(2) DNAME VARCHAR2(14) LOCVARCHAR2(13) SQL> desc emp; Name Null?Type - EMPNO NOT NULL NUMBER(4) ENAME VARCHAR2(10) JOBVARCHAR2(9) MGRNUMBER(4) HIREDATE DATE SALNUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2) SQL ``` select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=? ``` Java ``` String sql="select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=?"; Emp e=(Emp) qr.query(sql, new BeanHandler(Emp.class),7902); ``` ERROR: ``` java.sql.SQLException: ORA-00904: "EMP": invalid identifier Query: select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=? Parameters: [7902] at org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:392) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:351) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:289) ``` driver: ojdbc7.jar When execute on database or use pure JDBC, It's correct. Please fixed. was: Oracle Database: ``` SQL> desc dept Name Null?Type - DEPTNONOT NULL NUMBER(2) DNAME VARCHAR2(14) LOCVARCHAR2(13) SQL> desc emp; Name Null?Type - EMPNO NOT NULL NUMBER(4) ENAME VARCHAR2(10) JOBVARCHAR2(9) MGRNUMBER(4) HIREDATE DATE SALNUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2) SQL ``` select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=? ``` Java ``` String sql="select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=?"; Emp e=(Emp) qr.query(sql, new BeanHandler(Emp.class),7902); ``` ERROR: ``` java.sql.SQLException: ORA-00904: "EMP": invalid identifier Query: select e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename from emp e2 where e2.empno=e.mgr) as mgrname from emp e,dept d where e.deptno=d.deptno and e.empno=? Parameters: [7902] at org.apache.commons.dbutils.AbstractQueryRunner.rethrow(AbstractQueryRunner.java:392) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:351) at org.apache.commons.dbutils.QueryRunner.query(QueryRunner.java:289) ``` When execute on database or use JDBC, It's correct. Please fixed. > Can't execute subquery when use parameters > -- > > Key: DBUTILS-128 > URL: https://issues.apache.org/jira/browse/DBUTILS-128 > Project: Commons DbUtils > Issue Type: Bug >Affects Versions: 1.5, 1.6 > Environment: Database: Oracle > SQL: select > e.empno,e.ename,e.job,e.hiredate,e.mgr,e.sal,e.comm,d.dname,(select e2.ename > from emp e2 where e2.empno=e.mgr) as mgrname from
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975955#comment-15975955
]
Bruno P. Kinoshita commented on MATH-1414:
--
[~erans] we can move the issue to the NUMBERS component, keeping the
conversation log with it.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CONFIGURATION-664) Add API org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String)
Gary Gregory created CONFIGURATION-664:
--
Summary: Add API
org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String)
Key: CONFIGURATION-664
URL: https://issues.apache.org/jira/browse/CONFIGURATION-664
Project: Commons Configuration
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Add API
org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String):
{code:java}
/**
* Returns a list with the children of this node. This list cannot be
* modified.
* @param name the node name to find
*
* @return a list with the child nodes
*/
public List getChildren(final String name)
{
final List list = new ArrayList<>();
if (name == null) {
return list;
}
for (final ImmutableNode node : children)
{
if (name.equals(node.getNodeName()))
{
list.add(node);
}
}
return list;
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975981#comment-15975981
]
Bruno P. Kinoshita commented on MATH-1414:
--
Trying to make sure I understand the issue in the code.
Using -2.44242319E-315 as input, here's the result in Python with NumPy.
{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex0)
array(0.0)
{noformat}
Here's the output with GNU Octave:
{noformat}
>> complex0 = -2.44242319E-315
complex0 = -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}
And in our case, as [~gjahanagirova] pointed, we get the following with the
latest code from git/master:
{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());
# Output will be:
# -Infinity
# NaN
{noformat}
For the reciprocal value, for the three libraries the real value is -Infinity.
NumPy and Octave seem to agree that the imaginary part of the reciprocal is
0.0. But [math] says it is NaN.
>the value of complex1.getImaginary() will be NaN, instead of complex1 being
>equal to INF.
Are we sure the imaginary part of the reciprocal value must be INF, instead of
0.0 as in the other libraries?
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15975981#comment-15975981
]
Bruno P. Kinoshita edited comment on MATH-1414 at 4/20/17 3:16 AM:
---
Trying to make sure I understand the issue in the code.
Using -2.44242319E-315 as input, here's the result in Python with NumPy.
{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex1)
array(0.0)
{noformat}
Here's the output with GNU Octave:
{noformat}
>> complex0 = -2.44242319E-315
complex0 = -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}
And in our case, as [~gjahanagirova] pointed, we get the following with the
latest code from git/master:
{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());
# Output will be:
# -Infinity
# NaN
{noformat}
For the reciprocal value, for the three libraries the real value is -Infinity.
NumPy and Octave seem to agree that the imaginary part of the reciprocal is
0.0. But [math] says it is NaN.
>the value of complex1.getImaginary() will be NaN, instead of complex1 being
>equal to INF.
Are we sure the imaginary part of the reciprocal value must be INF, instead of
0.0 as in the other libraries?
was (Author: kinow):
Trying to make sure I understand the issue in the code.
Using -2.44242319E-315 as input, here's the result in Python with NumPy.
{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex0)
array(0.0)
{noformat}
Here's the output with GNU Octave:
{noformat}
>> complex0 = -2.44242319E-315
complex0 = -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}
And in our case, as [~gjahanagirova] pointed, we get the following with the
latest code from git/master:
{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());
# Output will be:
# -Infinity
# NaN
{noformat}
For the reciprocal value, for the three libraries the real value is -Infinity.
NumPy and Octave seem to agree that the imaginary part of the reciprocal is
0.0. But [math] says it is NaN.
>the value of complex1.getImaginary() will be NaN, instead of complex1 being
>equal to INF.
Are we sure the imaginary part of the reciprocal value must be INF, instead of
0.0 as in the other libraries?
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CONFIGURATION-664) Add API org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String)
[
https://issues.apache.org/jira/browse/CONFIGURATION-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed CONFIGURATION-664.
--
Resolution: Fixed
Fix Version/s: 2.2
In svn trunk.
> Add API
> org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String)
>
>
> Key: CONFIGURATION-664
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-664
> Project: Commons Configuration
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 2.2
>
>
> Add API
> org.apache.commons.configuration2.tree.ImmutableNode.getChildren(String):
> {code:java}
> /**
> * Returns a list with the children of this node. This list cannot be
> * modified.
> * @param name the node name to find
> *
> * @return a list with the child nodes
> */
> public List getChildren(final String name)
> {
> final List list = new ArrayList<>();
> if (name == null) {
> return list;
> }
> for (final ImmutableNode node : children)
> {
> if (name.equals(node.getNodeName()))
> {
> list.add(node);
> }
> }
> return list;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
