[jira] [Commented] (VALIDATOR-410) Failure cases for UrlValidator
[
https://issues.apache.org/jira/browse/VALIDATOR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064199#comment-16064199
]
Asankhaya Sharma commented on VALIDATOR-410:
The BNF URL grammar used in the tests is given here:
https://github.com/codelion/gramtest/blob/master/src/test/resources/url.bnf
And it was based of https://www.w3.org/Addressing/URL/5_BNF.html
I think if we try to parse the URL using a RegEx it is bound to have some
limitations. In fact I also found few other JS libraries also that miss valid
generated test cases e.g. https://github.com/segmentio/is-url/issues/15 and
https://github.com/gajus/url-regexp/issues/6
> Failure cases for UrlValidator
> ---
>
> Key: VALIDATOR-410
> URL: https://issues.apache.org/jira/browse/VALIDATOR-410
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.5.1
>Reporter: Asankhaya Sharma
>Priority: Minor
>
> I was trying to check how closely the UrlValidator implements the URL grammar
> as described by the RFC 1738 (https://www.ietf.org/rfc/rfc1738.txt). I fuzzed
> the UrlValidator with GramTest, a grammar based test case generation tool
> (https://github.com/codelion/gramtest).
> I found that in the latest version 1.5.1, the UrlValidator fails to validate
> the following strings:
> {{"ftp:///+"}}
> {{"mailto:%FF@Z"}}
> These two strings may seem a bit strange, but I verified manually that they
> are allowed by the grammar given in the RFC (see also
> https://www.w3.org/Addressing/URL/5_BNF.html).
> Furthermore, it is possible to create the following URLs in Java without
> throwing a {{MalformedUrlException}}:
> {code}
> new URL("ftp:///+;);
> new URL("mailto:%FF@Z;);
> {code}
> however, the UrlValidator returns false for these strings:
> {code}
> UrlValidator validator = new UrlValidator(UrlValidator.ALLOW_ALL_SCHEMES +
> UrlValidator.ALLOW_2_SLASHES + UrlValidator.ALLOW_LOCAL_URLS);
> validator.isValid("ftp:///+;); // returns false
> validator.isValid("mailto:%FF@Z;); // returns false
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies
[
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064035#comment-16064035
]
BELUGA BEHR edited comment on COLLECTIONS-605 at 6/27/17 12:25 AM:
---
Here is the example that inspired me:
{code:title=org.apache.hadoop.hive.serde2.RegexSerDe}
row = new ArrayList(numColumns);
// Constructing the row object, etc, which will be reused for all rows.
for (int c = 0; c < numColumns; c++) {
row.add(null);
}
{code}
What it would be nice to do:
{code:title=org.apache.hadoop.hive.serde2.RegexSerDe}
row = new ArrayList(numColumns);
CollectionUtils.addNCopies(numColumns, null);
{code}
was (Author: belugabehr):
{code:title=org.apache.hadoop.hive.serde2.RegexSerDe}
row = new ArrayList(numColumns);
// Constructing the row object, etc, which will be reused for all rows.
for (int c = 0; c < numColumns; c++) {
row.add(null);
}
{code}
> Add new CollectionUtils Feature - addNCopies
>
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies
[
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16064035#comment-16064035
]
BELUGA BEHR commented on COLLECTIONS-605:
-
{code:title=org.apache.hadoop.hive.serde2.RegexSerDe}
row = new ArrayList(numColumns);
// Constructing the row object, etc, which will be reused for all rows.
for (int c = 0; c < numColumns; c++) {
row.add(null);
}
{code}
> Add new CollectionUtils Feature - addNCopies
>
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063913#comment-16063913 ] Min Wei commented on JEXL-226: -- I know the Java heritage, though ?? is becoming a more pattern (e.g. Swift supports it too). Note that I am still experimenting with JEXL. And kind of curious about the main use cases by other people. I know it's originally planned to support SCXML Given JEXL is already departing away from Java (e.g. its lambda etc.), it might make sense to make it more "LISP like" expression language that supports defining new operators. Anyway, just a suggestion. Please feel free to close out this jira. > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei > Labels: features > Fix For: Later > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063883#comment-16063883 ] Henri Biestro commented on JEXL-226: JEXL stands for Java Expression Language though :-) Not a fan of adding a C# syntax for an operator that already exists; I'd suggest regexp/replace ?? with ?: if this is a must in your case. For operators, at least the actual operations behind the syntax, most of the behaviors (if not all) can be customized through a user-defined JexlArithmetic and overriding/overloading the corresponding methods. (see http://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl3/JexlOperator.html ) > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei > Labels: features > Fix For: Later > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CONFIGURATION-258) JSON configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063698#comment-16063698
]
Oliver Heger commented on CONFIGURATION-258:
Added you to the contributors section in revision 1799978.
> 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.2
>
> 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.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063512#comment-16063512 ] Min Wei commented on JEXL-226: -- I have some internal use cases to prefer the C# like syntax. On thinking of it, it might be a good idea to be able to redefine the operators in general for a scripting language like JEXL. Because it's a DSL after all. > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei > Labels: features > Fix For: Later > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DAEMON-288) Hang while stopping procrun service
[ https://issues.apache.org/jira/browse/DAEMON-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063389#comment-16063389 ] Mike Miller commented on DAEMON-288: Based on DAEMON-366 traces and config, I think the main thread didn't see gShutdownEvent because the start method returned before the stop method was called. Notice the trace "Waiting for all threads to exit" occurred right after the start was called. The stop wasn't called for another 3 minutes. Since gShutdownEvent is created during the stop, it would have still been NULL if the start exited before the serviceStop() was called. Since start exited prematurely, the code ended up in the code path to INFINITE wait for the JVM to exit. I would speculate that there was a non-daemon JVM thread preventing the JVM from exiting. According to Procrun documentation, "Note: in jvm mode, the start method should not return until the stop method has been called.". Maybe a warning should be logged if executing in JVM mode and the start method returns before the stop method is executed? > Hang while stopping procrun service > --- > > Key: DAEMON-288 > URL: https://issues.apache.org/jira/browse/DAEMON-288 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.13 > Environment: Windows 7 64 bit >Reporter: Mike Miller > Fix For: 1.0.15 > > Attachments: prunsrv.c.patch > > > There is a hang of the procrun service while it is attempting to stop. It is > not easy to reproduce ( 30%-5% depending on pc ). Using a debugging to > analyze the hang, both the serviceMain() and serviceStop() threads appear to > have run and exited. I can tell this from the state of the global variables > like gSargs and gShutdownEvents. Looking at the code, both are calling > reportServiceStatus( SERVICE_STOPPED...). Typically when either one reports > SERVICE_STOPPED, the main thread unblocks and the process terminates. This > often occurs without both threads running to completion. I think this is a > race condition caused by the reportServiceStatus() usage. The MSDN > documentation for SetServiceStatus() states to only call SetServiceStatus() > with SERVICE_STOPPED after all cleanup has occurred and to only call it once. > It appears that procrun has a race condition where 2 threads will both > attempt to report SERVICE_STOPPED and will likely report this while the other > thread is still running. I believe this is the root cause of why the Service > Control Manager sometimes is unable to stop the service. > > As a potential solution, I modified serviceStop() to not call > reportServiceStatus(SERVICE_STOPPED...) and to move the SetEvent( > gShutdownEvent) to the end of the method. This change allows the thread > running the serviceStop() to complete. Now the only method reporting > stopped is when serviceMain() exits. With this refactoring to only report > SERVICE_STOPPED once (per MSDN) the hang has not been reproducible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063302#comment-16063302 ] ASF GitHub Bot commented on COMPRESS-413: - Github user bodewig commented on the issue: https://github.com/apache/commons-compress/pull/43 Builds for PRs are already covered - https://builds.apache.org/job/Commons-Compress%20PullRequest%20Builder/ - and we could add support for building arbitrary branches if we wanted to using build pipelines. We just haven't got that many branches outside of PRs (master and the stalled compress-2.0 experiment). :-) > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063215#comment-16063215 ] ASF GitHub Bot commented on COMPRESS-413: - Github user sesuncedu commented on the issue: https://github.com/apache/commons-compress/pull/43 Travis has some nice properties, especially when working with forks. It's very easy to enable travis for a fork, so CI can be done before a PR goes in. Travis can also run really quickly, but only when tuned properly, and when the system is not running at capacity. If the stars are aligned, you can get every job in a big 'ol matrix running in parallel (each container build gets 2 cores and max 4GB of memory), which is nice if they're free. The critical thing is to be using the container environments and not the VM, as the startup time is tiny. The annoying thing about Travis is that the default environment is running Ubuntu 12.04, which is well past its LTS date. The trusty (14.04) container is *still* marked as beta, despite being on a production level update cycle (set group to edge for that real beta experience). The 12.04 containers all have to do a lot of package replacement on startup, which takes away some of the benefits of having a container ). I kept the home server on 12.04 until the end of LTS because Travis, then went to xenial (16.04) which is the current LTS, and has nice things like proper zfs (hey- an apache connection). Hudkins farms in my mental model usually seem to be more congested, but there are good reasons not to believe that. > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063148#comment-16063148 ] ASF GitHub Bot commented on COMPRESS-413: - Github user sesuncedu commented on the issue: https://github.com/apache/commons-compress/pull/43 I think there is also some jacoco oddness related to synthetic methods in certain JDKs , but mostly I blame coveralls, since I'm not sure jacoco is wrong :-) IntelliJ has a bunch of different coverage tracers, including jacoco, and they have a spread of class and line counts that seems to be all synthetic accessor related. Oh for statement level "ignore". > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063093#comment-16063093 ] Henri Biestro commented on JEXL-230: Please, amend the doc, submit a patch. > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Trivial > Labels: documentation, help-wanted > Fix For: 3.1 > > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
[ https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063094#comment-16063094 ] ASF GitHub Bot commented on COMPRESS-413: - Github user bodewig commented on the issue: https://github.com/apache/commons-compress/pull/43 We all know coveralls is flaky at the sub-percent/sub-permille level. The first paragraphs of https://github.com/apache/commons-compress/pull/39#issuecomment-310845353 are still true :-) The matrix build is https://builds.apache.org/view/Apache%20Commons/job/Commons-Compress%20JDK-Matrix%20Build/ > Travis build redundantly repeats compilation and tests redundantly > -- > > Key: COMPRESS-413 > URL: https://issues.apache.org/jira/browse/COMPRESS-413 > Project: Commons Compress > Issue Type: Improvement > Components: Build >Affects Versions: 1.14 > Environment: Travis >Reporter: Simon Spero >Priority: Minor > Labels: CI > Fix For: 1.15 > > Original Estimate: 0h > Remaining Estimate: 0h > > The Travis build setup is suboptimal. > At the moment, code is compiled and installed by the default install phase. > Then the default build phase is executed, which compiles and runs the tests. > If the tests succeed, then the build is cleaned, recompiled, and retested; > this time with > coverage enabled. > The .travis.yml file could be changed to skip the install phase, and to run > tests with coverage during the build phase. > The coveralls plugin can be configured in the pom to not fail the build if > the service is unreachable, so forks that don't have jacoco enabled won't > always have their builds fail. > Also, the jdk switching in the trusty container seems to be not working > properly at the moment, so installing a jdk7 doesn't work properly. > These changes evolved as I was poking jenkins last night. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063088#comment-16063088 ] Henri Biestro edited comment on JEXL-226 at 6/26/17 1:34 PM: - I'm very much against having 2 syntaxes for the same operator. What is the benefit of not using the 'elvis' - ?: - operator ? was (Author: henrib): I'm very much against having 2 syntaxes for the same operator. What is the benefit of not using the 'elvis' operator ? > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei > Labels: features > Fix For: Later > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-226) add ?? operator support
[ https://issues.apache.org/jira/browse/JEXL-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063088#comment-16063088 ] Henri Biestro commented on JEXL-226: I'm very much against having 2 syntaxes for the same operator. What is the benefit of not using the 'elvis' operator ? > add ?? operator support > > > Key: JEXL-226 > URL: https://issues.apache.org/jira/browse/JEXL-226 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: Later >Reporter: Min Wei > Labels: features > Fix For: Later > > Original Estimate: 1h > Remaining Estimate: 1h > > Jexl already supports null-coalescing semantics with the operator "?:". So it > should be a simple matter to extend it with a different syntax. > https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operator > https://github.com/apache/commons-jexl/pull/4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063085#comment-16063085 ] ASF GitHub Bot commented on COMPRESS-400: - Github user asfgit closed the pull request at: https://github.com/apache/commons-compress/pull/31 > It should be possible for users to create and access extra PAX headers to tar > archives > --- > > Key: COMPRESS-400 > URL: https://issues.apache.org/jira/browse/COMPRESS-400 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Simon Spero >Priority: Minor > > It is very useful to be able to add extra PAX headers to tar entries. For > example, a tar file containing maven artifacts could have extra headers > carrying the groupid, artifactid, version, classifier, etc. > If the appropriate prefixes are used, these headers can be extracted to posix > extended attributes by gnu and bsdtar. > This change requires adding a map to TarArchiveEntry to carry the extra > headers, plus modifications to the TarArchive*Stream to save unrecognized > headers when reading, and to add any extra headers when writing. > I have created a prototype implementation, but have not merged it into my > fork of the project. I don't have full tests written, because I was using > gnutar as an oracle. > I have also ignored the issue of writing values to standard headers like > size, though since the PAX specification states that doing things like > setting size=100 (if the real size is not in fact 100) is undefined, so I'm > technically in compliance. The temptation is to do what was asked, then on > close pop up a "Were you sure?" dialog, but that's mean. I guess I could use > this to set the appropriate entry fields if doing so makes sense, but the > easiest approach is to block setting any headers that would be consumed by > the tar implementation when reading. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives
[
https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063078#comment-16063078
]
Stefan Bodewig commented on COMPRESS-400:
-
Thanks Simon, I've merged the PR.
Do you think your additional notes should go into the docs in some way?
{{src/site/xdoc/tar.xml}} already contains information specific to tar support.
> It should be possible for users to create and access extra PAX headers to tar
> archives
> ---
>
> Key: COMPRESS-400
> URL: https://issues.apache.org/jira/browse/COMPRESS-400
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
>Reporter: Simon Spero
>Priority: Minor
>
> It is very useful to be able to add extra PAX headers to tar entries. For
> example, a tar file containing maven artifacts could have extra headers
> carrying the groupid, artifactid, version, classifier, etc.
> If the appropriate prefixes are used, these headers can be extracted to posix
> extended attributes by gnu and bsdtar.
> This change requires adding a map to TarArchiveEntry to carry the extra
> headers, plus modifications to the TarArchive*Stream to save unrecognized
> headers when reading, and to add any extra headers when writing.
> I have created a prototype implementation, but have not merged it into my
> fork of the project. I don't have full tests written, because I was using
> gnutar as an oracle.
> I have also ignored the issue of writing values to standard headers like
> size, though since the PAX specification states that doing things like
> setting size=100 (if the real size is not in fact 100) is undefined, so I'm
> technically in compliance. The temptation is to do what was asked, then on
> close pop up a "Were you sure?" dialog, but that's mean. I guess I could use
> this to set the appropriate entry fields if doing so makes sense, but the
> easiest approach is to block setting any headers that would be consumed by
> the tar implementation when reading.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (COMPRESS-400) It should be possible for users to create and access extra PAX headers to tar archives
[ https://issues.apache.org/jira/browse/COMPRESS-400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16063074#comment-16063074 ] ASF GitHub Bot commented on COMPRESS-400: - Github user asfgit closed the pull request at: https://github.com/apache/commons-compress/pull/46 > It should be possible for users to create and access extra PAX headers to tar > archives > --- > > Key: COMPRESS-400 > URL: https://issues.apache.org/jira/browse/COMPRESS-400 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Reporter: Simon Spero >Priority: Minor > > It is very useful to be able to add extra PAX headers to tar entries. For > example, a tar file containing maven artifacts could have extra headers > carrying the groupid, artifactid, version, classifier, etc. > If the appropriate prefixes are used, these headers can be extracted to posix > extended attributes by gnu and bsdtar. > This change requires adding a map to TarArchiveEntry to carry the extra > headers, plus modifications to the TarArchive*Stream to save unrecognized > headers when reading, and to add any extra headers when writing. > I have created a prototype implementation, but have not merged it into my > fork of the project. I don't have full tests written, because I was using > gnutar as an oracle. > I have also ignored the issue of writing values to standard headers like > size, though since the PAX specification states that doing things like > setting size=100 (if the real size is not in fact 100) is undefined, so I'm > technically in compliance. The temptation is to do what was asked, then on > close pop up a "Were you sure?" dialog, but that's mean. I guess I could use > this to set the appropriate entry fields if doing so makes sense, but the > easiest approach is to block setting any headers that would be consumed by > the tar implementation when reading. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[
https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062998#comment-16062998
]
Dmitri Blinov commented on JEXL-230:
As far as I know we have two different syntaxes here, the one which creates
arrays, like the follows
{code}
[1,2,3]
{code}
and the other one which creates an ArrayList, like the follows
{code}
[1,2,3,...]
{code}
Syntax is similar, but since it allows for creation of different objects I
think this should be mentioned somewhere in documentation, I suggest a separate
topic in Section Literals, List Literal
> List literal is not mentioned in docs
> -
>
> Key: JEXL-230
> URL: https://issues.apache.org/jira/browse/JEXL-230
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Trivial
> Labels: documentation, help-wanted
> Fix For: 3.1
>
>
> The syntax for [1,2,3,...] literal which creates List objects is not
> mentioned in documentation
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-229) Introduce new syntax for class literals: Class and Type
[ https://issues.apache.org/jira/browse/JEXL-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062958#comment-16062958 ] Henri Biestro commented on JEXL-229: A set of use cases is missing. However and in general, I suspect a new syntax is not warranted. Can you give produce an example/test using a classp(...) or typep(...) function/functor in a namespace so what you're after is made clear? > Introduce new syntax for class literals: Class and Type > - > > Key: JEXL-229 > URL: https://issues.apache.org/jira/browse/JEXL-229 > Project: Commons JEXL > Issue Type: New Feature >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Minor > > For the purpose of type checking in jexl, It whould be convenient to have > some simple syntax for referring to class types, like Class or > Type. Literal Class should refer to general classes, and literal > Type should refer to primitive type classes. For literals Class it > could be possible to specify partal class name, which should resolve to > classes in basic packages like java.lang and java.util, for example. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-228) Ability to read j.u.Collection elements other than instanceof j.u.List by using [] and . operator
[
https://issues.apache.org/jira/browse/JEXL-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062955#comment-16062955
]
Henri Biestro commented on JEXL-228:
There should be a way to preserve standard behavior by creating a new
ResolverStrategy & PropertyResolver.
see
http://commons.apache.org/proper/commons-jexl/apidocs/org/apache/commons/jexl3/introspection/JexlUberspect.ResolverStrategy.html
> Ability to read j.u.Collection elements other than instanceof j.u.List by
> using [] and . operator
> -
>
> Key: JEXL-228
> URL: https://issues.apache.org/jira/browse/JEXL-228
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Minor
>
> In the current implementation of Jexl there is a possibility to address in a
> script the specific elements of {{List}} and {{Array}} by using operators
> {{[]}} or {{.}}, whereas its not that simple for descendants of {{Set}} or
> any other {{Collection}} descendant, as there is no such an operator for them
> out of the box. But in practice this is not so uncommon task for a script
> writer to get, for example, the first element of the LinkedHashSet, which is
> supposed to maintain the logical order of its elements, but unfortunately
> does not implement {{List}} interface for us to be able to address its
> elements in that order. I believe such a basic functionality - deserves to be
> available for script witers from the start.
> I have been experimenting with overloading access operators in customized
> JexlArithmetic for a while and have managed to overload operators {{[]}} and
> {{.}} so that they could be used not only for {{List}} interfaces but for
> other {{Collection}} types as well:
> {code}
> protected Object nth(Collection c, int i) {
>if (c instanceof List) {
> List list = (List) c;
> return list.get(i);
>} else {
> for (Object o : c) {
> if (i-- == 0)
> return o;
> }
>}
>return null;
> }
> public Object propertyGet(Collection c, Number n) {
>return nth(c, n.intValue());
> }
> public Object arrayGet(Collection c, Number n) {
>return nth(c, n.intValue());
> }
> {code}
> But I'm not satisfied with the fact that I have disabled alltogether the
> initial Jexl implementation of access operators for {{LIst}} types.
> The suggestion is to add the ability for Jexl scripts to read, not
> manipulate, elements of any {{Collection}} type.
> BTW, I have found that for {{List}} elements this solution is roughly 50%
> faster compared with that of built-in Jexl List access implementation, so may
> be there should be a place for a performance improvement in a way Jexl itself
> accesses list elements.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro resolved JEXL-230. Resolution: Invalid Assignee: Henri Biestro Fix Version/s: 3.1 Syntax is fully documented in: http://commons.apache.org/proper/commons-jexl/reference/syntax.html For the problem at hand, Section Literals, Array Literal > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Assignee: Henri Biestro >Priority: Trivial > Labels: documentation, help-wanted > Fix For: 3.1 > > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062928#comment-16062928 ] Dmitri Blinov commented on JEXL-230: I thought the main source tree for jexl is maintained on the other site, it is only mirrored at github, isn't it? > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Trivial > Labels: documentation, help-wanted > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (COLLECTIONS-605) Add new CollectionUtils Feature - addNCopies
[
https://issues.apache.org/jira/browse/COLLECTIONS-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062905#comment-16062905
]
Sebb commented on COLLECTIONS-605:
--
What is the use case for this?
> Add new CollectionUtils Feature - addNCopies
>
>
> Key: COLLECTIONS-605
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-605
> Project: Commons Collections
> Issue Type: New Feature
>Affects Versions: 4.1
>Reporter: BELUGA BEHR
>Priority: Trivial
> Attachments: COLLECTIONS-605.1.patch
>
>
> Java's {{java.util.Collections}} has:
> {code}
> nCopies(int n, T o)
> Returns an immutable list consisting of n copies of the specified object.
> addAll(Collection c, T... elements)
> Adds all of the specified elements to the specified collection.
> fill(List list, T obj)
> Replaces all of the elements of the specified list with the specified element.
> {code}
> However, it does not have the ability to add nCopies directly to a Collection.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062826#comment-16062826 ] Bruno P. Kinoshita commented on JEXL-230: - Patches welcome! :-) There should be a good place for it somewhere around here https://github.com/apache/commons-jexl/tree/trunk/src/site/xdoc > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Trivial > Labels: documentation, help-wanted > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (JEXL-230) List literal is not mentioned in docs
[ https://issues.apache.org/jira/browse/JEXL-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated JEXL-230: Labels: documentation help-wanted (was: ) > List literal is not mentioned in docs > - > > Key: JEXL-230 > URL: https://issues.apache.org/jira/browse/JEXL-230 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.1 >Reporter: Dmitri Blinov >Priority: Trivial > Labels: documentation, help-wanted > > The syntax for [1,2,3,...] literal which creates List objects is not > mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (JEXL-231) Syntax for accessing List elements is not mentioned in docs
Dmitri Blinov created JEXL-231:
--
Summary: Syntax for accessing List elements is not mentioned in
docs
Key: JEXL-231
URL: https://issues.apache.org/jira/browse/JEXL-231
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 3.1
Reporter: Dmitri Blinov
Priority: Trivial
While it is explicitly specified in docs that Jexl allows to use {{[]}} and
{{.}} operators for accessing array elements, nothing is said that the same
syntax could be used for accessing List elements
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (JEXL-230) List literal is not mentioned in docs
Dmitri Blinov created JEXL-230: -- Summary: List literal is not mentioned in docs Key: JEXL-230 URL: https://issues.apache.org/jira/browse/JEXL-230 Project: Commons JEXL Issue Type: Improvement Affects Versions: 3.1 Reporter: Dmitri Blinov Priority: Trivial The syntax for [1,2,3,...] literal which creates List objects is not mentioned in documentation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VALIDATOR-410) Failure cases for UrlValidator
[
https://issues.apache.org/jira/browse/VALIDATOR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062648#comment-16062648
]
Bruno P. Kinoshita commented on VALIDATOR-410:
--
FWIW, here's a few different libraries and the results for the URL validation.
Python.
{code:python}
import validators # pip install validators
r = validators.url('ftp:///+')
print(r == True)
# False
from urllib.parse import urlparse
= urlparse('ftp:///+')
print(r == True)
# False
{code}
JavaScript:
JQuery Validation Plug-in fails to validate ftp:///+, see
https://jqueryvalidation.org/url-method/ to test it. You can find the regex
used in the GH repository too.
Perl:
{code:perl}
#!/usr/bin/env perl
use Data::Validate::URI qw(is_uri);
my $r = is_uri("ftp:///+;);
if ($r) {
print "Valid";
} else {
print "Invalid";
}
# Valid
{code}
So at least it's not so different from other programming languages & libraries.
There may be other Python and JS libraries that actually validate to true that
URL, I just used the ones I'm aware of and normally use in projects.
> Failure cases for UrlValidator
> ---
>
> Key: VALIDATOR-410
> URL: https://issues.apache.org/jira/browse/VALIDATOR-410
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.5.1
>Reporter: Asankhaya Sharma
>Priority: Minor
>
> I was trying to check how closely the UrlValidator implements the URL grammar
> as described by the RFC 1738 (https://www.ietf.org/rfc/rfc1738.txt). I fuzzed
> the UrlValidator with GramTest, a grammar based test case generation tool
> (https://github.com/codelion/gramtest).
> I found that in the latest version 1.5.1, the UrlValidator fails to validate
> the following strings:
> {{"ftp:///+"}}
> {{"mailto:%FF@Z"}}
> These two strings may seem a bit strange, but I verified manually that they
> are allowed by the grammar given in the RFC (see also
> https://www.w3.org/Addressing/URL/5_BNF.html).
> Furthermore, it is possible to create the following URLs in Java without
> throwing a {{MalformedUrlException}}:
> {code}
> new URL("ftp:///+;);
> new URL("mailto:%FF@Z;);
> {code}
> however, the UrlValidator returns false for these strings:
> {code}
> UrlValidator validator = new UrlValidator(UrlValidator.ALLOW_ALL_SCHEMES +
> UrlValidator.ALLOW_2_SLASHES + UrlValidator.ALLOW_LOCAL_URLS);
> validator.isValid("ftp:///+;); // returns false
> validator.isValid("mailto:%FF@Z;); // returns false
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (VALIDATOR-410) Failure cases for UrlValidator
[
https://issues.apache.org/jira/browse/VALIDATOR-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16062621#comment-16062621
]
Bruno P. Kinoshita commented on VALIDATOR-410:
--
Hi [~codelion],
Most issues at Apache Commons components I found via JIRA. This one I found
from the GramtTest project page :-)
I am reading GramTest's code base to better understand how it works, and
compare with afl and its genetics algorithms. I believe the priority given to
this issue is correct, as there doesn't seem to be any risk in not parsing
correctly the test cases mentioned.
What about the grammar used for the tests? Could you share that as well,
please? That may be helpful to understand where it fails exactly to validate
and why (and for me to continue learning about GramTest :)
Thanks
Bruno
> Failure cases for UrlValidator
> ---
>
> Key: VALIDATOR-410
> URL: https://issues.apache.org/jira/browse/VALIDATOR-410
> Project: Commons Validator
> Issue Type: Bug
>Affects Versions: 1.5.1
>Reporter: Asankhaya Sharma
>Priority: Minor
>
> I was trying to check how closely the UrlValidator implements the URL grammar
> as described by the RFC 1738 (https://www.ietf.org/rfc/rfc1738.txt). I fuzzed
> the UrlValidator with GramTest, a grammar based test case generation tool
> (https://github.com/codelion/gramtest).
> I found that in the latest version 1.5.1, the UrlValidator fails to validate
> the following strings:
> {{"ftp:///+"}}
> {{"mailto:%FF@Z"}}
> These two strings may seem a bit strange, but I verified manually that they
> are allowed by the grammar given in the RFC (see also
> https://www.w3.org/Addressing/URL/5_BNF.html).
> Furthermore, it is possible to create the following URLs in Java without
> throwing a {{MalformedUrlException}}:
> {code}
> new URL("ftp:///+;);
> new URL("mailto:%FF@Z;);
> {code}
> however, the UrlValidator returns false for these strings:
> {code}
> UrlValidator validator = new UrlValidator(UrlValidator.ALLOW_ALL_SCHEMES +
> UrlValidator.ALLOW_2_SLASHES + UrlValidator.ALLOW_LOCAL_URLS);
> validator.isValid("ftp:///+;); // returns false
> validator.isValid("mailto:%FF@Z;); // returns false
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
