[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312574#comment-16312574
]
Stefan Bodewig commented on COMPRESS-380:
-
Support for {{ZipArchiveInputStream}} is in now, but only if no data descriptor
is used. I need to verify with InfoZip whether they'd support one for
Deflate64. Also I stumbled over COMPRESS-436 while implementing it.
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (COMPRESS-436) ZipArchiveInputStream#getNextZipEntry should throw an exception if compressed size is unknown for bzip2, implode etc.
Stefan Bodewig created COMPRESS-436:
---
Summary: ZipArchiveInputStream#getNextZipEntry should throw an
exception if compressed size is unknown for bzip2, implode etc.
Key: COMPRESS-436
URL: https://issues.apache.org/jira/browse/COMPRESS-436
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.15
Reporter: Stefan Bodewig
Fix For: 1.16
{code}
if (current.entry.getCompressedSize() != ArchiveEntry.SIZE_UNKNOWN) {
if (current.entry.getMethod() == ZipMethod.UNSHRINKING.getCode()) {
current.in = new UnshrinkingInputStream(new
BoundedInputStream(in, current.entry.getCompressedSize()));
} else if (current.entry.getMethod() ==
ZipMethod.IMPLODING.getCode()) {
current.in = new ExplodingInputStream(
current.entry.getGeneralPurposeBit().getSlidingDictionarySize(),
current.entry.getGeneralPurposeBit().getNumberOfShannonFanoTrees(),
new BoundedInputStream(in,
current.entry.getCompressedSize()));
} else if (current.entry.getMethod() == ZipMethod.BZIP2.getCode()) {
current.in = new BZip2CompressorInputStream(new
BoundedInputStream(in, current.entry.getCompressedSize()));
}
}
{code}
never sets {{current.in}} if the compressed size is unknown which probably
leads to a NullPointerException in {{read}} later. We should fail early with a
useful error message instead.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312024#comment-16312024
]
Dawid Weiss commented on COMPRESS-380:
--
Looks good to me. I thought you'd just return 0 and be done with it, to be
honest :) It's nice to see it can be estimated better, but in all honesty I
don't think I ever saw {{available}} in any practical use case that made sense.
Those times I did see it, it was typically used in the wrong way (code only
calling {{read}} when available returned non-zero, etc.).
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-686) JSONConfiguration doesn't support array of objects
[
https://issues.apache.org/jira/browse/CONFIGURATION-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312013#comment-16312013
]
Oliver Heger commented on CONFIGURATION-686:
Thanks for the confirmation.
> JSONConfiguration doesn't support array of objects
> --
>
> Key: CONFIGURATION-686
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-686
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vincent Maurin
> Fix For: 2.3
>
>
> Hello,
> I have noticed that the array type is not properly handled by the
> JSONConfiguration (or AbstractYAMLBasedConfiguration)
> If we take the example from json.org
> {noformat}
> {
> "menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {
> "value": "New",
> "onclick": "CreateNewDoc()"
> },
> {
> "value": "Open",
> "onclick": "OpenDoc()"
> },
> {
> "value": "Close",
> "onclick": "CloseDoc()"
> }
> ]
> }
> }
> }
> {noformat}
> I would have expect the following call to return "New"
> {code:java}
> configuration.getString("menu.popup.menuitem(0).value")
> {code}
> The issue, I guess, is that only the Map type is handled by
> AbstractYAMLBasedConfiguration in a recursive way and not the list type.
> I had a custom JSONConfiguration implementation before supporting this use
> case, sorry for the code, it could be a bit messy and old, but it is maybe
> clearer to understand my issue
> {code:java}
> @Override
> @SuppressWarnings("unchecked")
> public void read(Reader in) throws ConfigurationException {
> try {
> Object jsonRoot = MAPPER.readValue(in, Object.class);
> List roots = createHierarchy(jsonRoot);
> if (roots.size() != 1) {
> throw new ConfigurationException("The configuration only
> support a single root");
> }
> getSubConfigurationParentModel().mergeRoot(roots.get(0).create(),
> null, null, null, null);
> } catch (IOException ex) {
> throw new ConfigurationException("Invalid JsonConfiguration", ex);
> }
> }
>
> @SuppressWarnings("unchecked")
> private static List createHierarchy(Object value) {
> if (value instanceof Map) {
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> Map map = (Map) value;
> for (Map.Entry entry : map.entrySet()) {
> List children =
> createHierarchy(entry.getValue());
> for (ImmutableNode.Builder child : children) {
> child.name(entry.getKey());
> result.addChild(child.create());
> }
> }
> return Collections.singletonList(result);
> } else if (value instanceof List) {
> List list = (List) value;
> List result = new ArrayList<>(list.size());
> for (Object item : list) {
> List children = createHierarchy(item);
> for (ImmutableNode.Builder child : children) {
> result.add(child);
> }
> }
> return result;
> }
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> result.value(value);
> return Collections.singletonList(result);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (JEXL-246) Intermittent ambiguous method invocation when processing assignOverload
[
https://issues.apache.org/jira/browse/JEXL-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-246:
---
Assignee: Henri Biestro
> Intermittent ambiguous method invocation when processing assignOverload
> ---
>
> Key: JEXL-246
> URL: https://issues.apache.org/jira/browse/JEXL-246
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> Sometimes the simple operator like {code}z += 1{code} when {{z}} has not been
> defined yet raises an exception
> {{org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException}}
> with the following stack trace:
> {quote}
> ambiguous method invocation: MyArithmetic.selfAdd(null, java.lang.Integer)
> org.apache.commons.jexl3.internal.introspection.MethodKey$AmbiguousException:
> null
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.getMostSpecific(MethodKey.java:540)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey$Parameters.access$000(MethodKey.java:452)
> at
> org.apache.commons.jexl3.internal.introspection.MethodKey.getMostSpecificMethod(MethodKey.java:261)
> at
> org.apache.commons.jexl3.internal.introspection.ClassMap.getMethod(ClassMap.java:178)
>
> at
> org.apache.commons.jexl3.internal.introspection.Introspector.getMethod(Introspector.java:146)
> at
> org.apache.commons.jexl3.internal.introspection.MethodExecutor.discover(MethodExecutor.java:52)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect.getMethod(Uberspect.java:218)
>
> at MyUberspect.getMethod(MyUberspect.java:168)
> at
> org.apache.commons.jexl3.internal.introspection.Uberspect$ArithmeticUberspect.getOperator(Uberspect.java:413)
> at
> org.apache.commons.jexl3.internal.Operators.tryOverload(Operators.java:85)
> at
> org.apache.commons.jexl3.internal.Operators.tryAssignOverload(Operators.java:118)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.executeAssign(Interpreter.java:1292)
>
> at
> org.apache.commons.jexl3.internal.Interpreter.visit(Interpreter.java:1102)
>
> {quote}
> The class MyArithmetic contains a couple of overloaded
> {{public JexlOperator selfAdd(T x, Object y)}} methods with the first
> argument being the desired type {{T}} like {{Appendable}} or {{Collection}}
> for which the {{+=}} operator is overloaded.
> Obviously in case where the first argument is null and the second argument is
> an Integer it is not possible to differentiate between {{public JexlOperator
> selfAdd(Collection x, Object y)}} and {{public JexlOperator
> selfAdd(Appendable x, Object y)}} but I wonder is there any point in trying
> to perform {{selfAdd}} on the null variable? What questions me more is that
> this error is intermittent and sometimes there is an exception and sometimes
> there is not, so at the moment I have no test case to reproduce. So I think
> this is a bug.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311543#comment-16311543
]
Stefan Bodewig commented on COMPRESS-380:
-
https://github.com/apache/commons-compress/commit/07cc1a278b217d45cb090ff6cb3a7934105cb2d0
changes {{available}}, does this look OK?
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311543#comment-16311543
]
Stefan Bodewig edited comment on COMPRESS-380 at 1/4/18 3:54 PM:
-
https://github.com/apache/commons-compress/commit/07cc1a278b217d45cb090ff6cb3a7934105cb2d0
changes {{available}}, does this look OK? I'll certainly have to add a few
more tests.
was (Author: bodewig):
https://github.com/apache/commons-compress/commit/07cc1a278b217d45cb090ff6cb3a7934105cb2d0
changes {{available}}, does this look OK?
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (RNG-37) Ziggurat algorithm
[ https://issues.apache.org/jira/browse/RNG-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved RNG-37. --- Resolution: Fixed Merged in "master" branch with some additional esthetic changes: commit 8375c9adad6489651836982e433f4f09d9b6e1bb > Ziggurat algorithm > -- > > Key: RNG-37 > URL: https://issues.apache.org/jira/browse/RNG-37 > Project: Commons RNG > Issue Type: Wish >Reporter: Gilles >Priority: Minor > Fix For: 1.1 > > Attachments: RNG-37.patch, ziggurat.buggy.png, ziggurat.patch.png > > > Fast algorithm for sampling a Gaussian distribution: > https://en.wikipedia.org/wiki/Ziggurat_algorithm -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311128#comment-16311128
]
Dawid Weiss commented on COMPRESS-380:
--
Makes sense to me. Available must not block -- that's the whole point of it --
so unless there's an internal buffer with already decompressed data (or an
estimate of how many bytes can be decompressed without fetching new bytes) 0 is
the best choice.
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311099#comment-16311099
]
Stefan Bodewig edited comment on COMPRESS-380 at 1/4/18 9:56 AM:
-
[~chalmagr84] I'd like to remove the {{uncompressedSize}} from the stream's
constructor for two reasons:
* ze.getSize() when using the stream in a {{ZipArchiveInputStream}} context the
uncompressed size may be unknown as it may be stpred inside of a data
descriptor rather than the local file header
* the stream only uses it inside of {{available}} which is supposed to return
the number of bytes that can be read without blocking. The implementation of
{{available}} is probably not correct for general {{InputStream}} s as we may
well be blocking while trying to read bits from it, it is probably OK for the
seekable input underlying {{ZipFile}}
I'd make {{available}} return 0 unconditionally. Alternatively the
{{DecoderState}} s may know a bit more about data they have already read and
could provide a less pessimistic answer.
Any objections?
was (Author: bodewig):
[~chalmagr84] I'd like to remove the {{uncompressedSize}} from the stream's
constructor for two reasons:
* ze.getSize() when using the stream in a {{ZipArchiveInputStream}} context the
uncompressed size may be unknown as it may be stpred inside of a data
descriptor rather than the local file header
* the stream only uses it inside of {{available}} which is supposed to return
the number of bytes that can be read without blocking. The implementation of
{{available}} is probably not correct for general {{InputStream}}s as we may
well be blocking while trying to read bits from it, it is probably OK for the
seekable input underlying {{ZipFile}}
I'd make {{available}} return 0 unconditionally. Alternatively the
{{DecoderState}}s may know a bit more about data they have already read and
could provide a less pessimistic answer.
Any objections?
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311099#comment-16311099
]
Stefan Bodewig commented on COMPRESS-380:
-
[~chalmagr84] I'd like to remove the {{uncompressedSize}} from the stream's
constructor for two reasons:
* ze.getSize() when using the stream in a {{ZipArchiveInputStream}} context the
uncompressed size may be unknown as it may be stpred inside of a data
descriptor rather than the local file header
* the stream only uses it inside of {{available}} which is supposed to return
the number of bytes that can be read without blocking. The implementation of
{{available}} is probably not correct for general {{InputStream}}s as we may
well be blocking while trying to read bits from it, it is probably OK for the
seekable input underlying {{ZipFile}}
I'd make {{available}} return 0 unconditionally. Alternatively the
{{DecoderState}}s may know a bit more about data they have already read and
could provide a less pessimistic answer.
Any objections?
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita resolved LANG-1374.
--
Resolution: Fixed
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> {code:java}
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> {code}
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311060#comment-16311060
]
Bruno P. Kinoshita commented on LANG-1374:
--
Fixed in c614fbcc79615f93d2c60a153db6e82d7474c425. changes.xml updated,
FixVersion and Affect Version updated in JIRA too.
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> {code:java}
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> {code}
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311058#comment-16311058
]
Bruno P. Kinoshita commented on LANG-1374:
--
Nice catch! Thanks for reporting the issue.
Fixed with a small test that will force the code to go through that line.
Probably coverage will increase a tiny bit.
However, that test is not really important. The output generated with or
without the fix is the same, from what I could tell. When that check returns -
incorrectly - false, then result of toString() is appended anyway.
But for the sake of correctness, we should fix that method and allow it to
follow the correct execution logic :-)
Thanks again for spotting it and for providing the fix. Feel free to submit a
pull request next time if you'd like your code to be included with the project.
Added credits in the changes.xml, so it should appear in the website after the
next release.
Bruno
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> {code:java}
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> {code}
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1374:
-
Fix Version/s: (was: 3.7)
(was: 3.6)
3.8
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1374:
-
Description:
In ToStringStyle class, which checking if a string is a valid Json array, the
boolean check was wrong.
original:
{code:java}
private boolean isJsonArray(final String valueAsString) {
return valueAsString.startsWith(getArrayStart())
&& valueAsString.startsWith(getArrayEnd());
}
{code}
The second expression should be valueAsString.endsWith(getArrayEnd())
was:
In ToStringStyle class, which checking if a string is a valid Json array, the
boolean check was wrong.
original:
private boolean isJsonArray(final String valueAsString) {
return valueAsString.startsWith(getArrayStart())
&& valueAsString.startsWith(getArrayEnd());
}
The second expression should be valueAsString.endsWith(getArrayEnd())
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> {code:java}
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> {code}
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1374:
-
Affects Version/s: (was: 3.6)
3.7
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.7
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.8
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (LANG-1374) Parsing Json Array failed
[
https://issues.apache.org/jira/browse/LANG-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno P. Kinoshita updated LANG-1374:
-
Assignee: Bruno P. Kinoshita
> Parsing Json Array failed
> -
>
> Key: LANG-1374
> URL: https://issues.apache.org/jira/browse/LANG-1374
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.builder.*
>Affects Versions: 3.6
>Reporter: Jaswanth Bala
>Assignee: Bruno P. Kinoshita
>Priority: Trivial
> Fix For: 3.6, 3.7
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In ToStringStyle class, which checking if a string is a valid Json array, the
> boolean check was wrong.
> original:
> private boolean isJsonArray(final String valueAsString) {
> return valueAsString.startsWith(getArrayStart())
> && valueAsString.startsWith(getArrayEnd());
> }
> The second expression should be valueAsString.endsWith(getArrayEnd())
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-686) JSONConfiguration doesn't support array of objects
[
https://issues.apache.org/jira/browse/CONFIGURATION-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16311033#comment-16311033
]
Vincent Maurin commented on CONFIGURATION-686:
--
Thank you for the quick patch [~oliver.he...@t-online.de].
My tests are working now with the revision 1819881 so I confirm it is working
as expected.
> JSONConfiguration doesn't support array of objects
> --
>
> Key: CONFIGURATION-686
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-686
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Vincent Maurin
> Fix For: 2.3
>
>
> Hello,
> I have noticed that the array type is not properly handled by the
> JSONConfiguration (or AbstractYAMLBasedConfiguration)
> If we take the example from json.org
> {noformat}
> {
> "menu": {
> "id": "file",
> "value": "File",
> "popup": {
> "menuitem": [
> {
> "value": "New",
> "onclick": "CreateNewDoc()"
> },
> {
> "value": "Open",
> "onclick": "OpenDoc()"
> },
> {
> "value": "Close",
> "onclick": "CloseDoc()"
> }
> ]
> }
> }
> }
> {noformat}
> I would have expect the following call to return "New"
> {code:java}
> configuration.getString("menu.popup.menuitem(0).value")
> {code}
> The issue, I guess, is that only the Map type is handled by
> AbstractYAMLBasedConfiguration in a recursive way and not the list type.
> I had a custom JSONConfiguration implementation before supporting this use
> case, sorry for the code, it could be a bit messy and old, but it is maybe
> clearer to understand my issue
> {code:java}
> @Override
> @SuppressWarnings("unchecked")
> public void read(Reader in) throws ConfigurationException {
> try {
> Object jsonRoot = MAPPER.readValue(in, Object.class);
> List roots = createHierarchy(jsonRoot);
> if (roots.size() != 1) {
> throw new ConfigurationException("The configuration only
> support a single root");
> }
> getSubConfigurationParentModel().mergeRoot(roots.get(0).create(),
> null, null, null, null);
> } catch (IOException ex) {
> throw new ConfigurationException("Invalid JsonConfiguration", ex);
> }
> }
>
> @SuppressWarnings("unchecked")
> private static List createHierarchy(Object value) {
> if (value instanceof Map) {
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> Map map = (Map) value;
> for (Map.Entry entry : map.entrySet()) {
> List children =
> createHierarchy(entry.getValue());
> for (ImmutableNode.Builder child : children) {
> child.name(entry.getKey());
> result.addChild(child.create());
> }
> }
> return Collections.singletonList(result);
> } else if (value instanceof List) {
> List list = (List) value;
> List result = new ArrayList<>(list.size());
> for (Object item : list) {
> List children = createHierarchy(item);
> for (ImmutableNode.Builder child : children) {
> result.add(child);
> }
> }
> return result;
> }
> ImmutableNode.Builder result = new ImmutableNode.Builder();
> result.value(value);
> return Collections.singletonList(result);
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-380) Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
[
https://issues.apache.org/jira/browse/COMPRESS-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16310990#comment-16310990
]
Stefan Bodewig commented on COMPRESS-380:
-
I've added a first testcase and it passes. The next steps will be adding
support to {{ZipArchiveInputStream}}, make the stream a full
{{CompressorInputStream}} and even a read-only codec for the 7z package.
Many thanks so far.
> Support for ENHANCED_DEFLATED (Deflate64) in ZIP files
> --
>
> Key: COMPRESS-380
> URL: https://issues.apache.org/jira/browse/COMPRESS-380
> Project: Commons Compress
> Issue Type: New Feature
>Reporter: Dawid Weiss
> Fix For: 1.16
>
> Attachments: archive-deflate.zip, archive-deflate64.zip, archive.zip,
> archive64.zip, compress-380.diff, hello.world, input2
>
>
> Some of the (large) ZIP files we try to process currently will throw this:
> {code}
> UnsupportedZipFeatureException: unsupported feature method
> 'ENHANCED_DEFLATED'
> {code}
> which is a bummer since JDK's implementation also doesn't support Deflate64.
> This seems to be PKWare's extensions, although code to decrypt it exists in
> zlib (and is appropriately licensed, I believe).
> https://github.com/madler/zlib/tree/master/contrib/infback9
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
