[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/20/23 9:52 AM:
---
I tried the servlet 3.1 multipart support. (PS it's now in the Jena codebase.)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support. (PS it's now in Jena codebase)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/20/23 9:52 AM:
---
I tried the servlet 3.1 multipart support. (PS it's now in Jena codebase)
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[
https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022
]
Andy Seaborne edited comment on FILEUPLOAD-309 at 1/1/23 10:09 PM:
---
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`
{{@MultipartConfig}} only applies to servlets, not servlet filters.
[https://github.com/jakartaee/servlet/issues/87]
Jetty: the code can set request attribute {{__MULTIPART_CONFIG_ELEMENT}} during
request processing.
Tomcat needs a setting of a context XML attribute
{{allowCasualMultipartParsing}}. e.g. set it in {{META-INF/context.xml}}. That
does at least avoid users needing to specially change the configuration of
their server.
was (Author: andy.seaborne):
I tried the servlet 3.1 multipart support.
Our (Jena) usage is
* a servlet filter
* deployed in any servlet container - normally bundled with Jetty; some users
deploy a WAR file version in Tomcat et al.
* `multipart/form-data` is just one possible content-type at the URL endpoint.
* streaming (errors are handled by being inside a database transaction)
Each servlet container needs custom configuration.
`@MultipartConfig` only applies to servlets, not servlet filters.
https://github.com/jakartaee/servlet/issues/87
Jetty: the code can set request attribute `__MULTIPART_CONFIG_ELEMENT` during
request processing.
Tomcat needs a setting of a context XML attribute
`allowCasualMultipartParsing`. Set in e.g. `META-INF/context.xml`.
> Release version 2.0.0
> -
>
> Key: FILEUPLOAD-309
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309
> Project: Commons FileUpload
> Issue Type: Wish
>Reporter: Thiago Henrique Hupner
>Priority: Major
>
> At Piranha, we've migrated to use the new Jakarta namespace.
> One of our dependencies is the Commons File Upload, but the latest version
> available is 1.4.
> Looking around at the source code, I've found that the code is already
> prepared for the new Jakarta namespace.
> So, I want to know if there's a plan to release a new version soon. Or at
> least a 2.0.0 milestone.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17652022#comment-17652022 ] Andy Seaborne commented on FILEUPLOAD-309: -- I tried the servlet 3.1 multipart support. Our (Jena) usage is * a servlet filter * deployed in any servlet container - normally bundled with Jetty; some users deploy a WAR file version in Tomcat et al. * `multipart/form-data` is just one possible content-type at the URL endpoint. * streaming (errors are handled by being inside a database transaction) Each servlet container needs custom configuration. `@MultipartConfig` only applies to servlets, not servlet filters. https://github.com/jakartaee/servlet/issues/87 Jetty: the code can set request attribute `__MULTIPART_CONFIG_ELEMENT` during request processing. Tomcat needs a setting of a context XML attribute `allowCasualMultipartParsing`. Set in e.g. `META-INF/context.xml`. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616378#comment-17616378 ] Andy Seaborne edited comment on FILEUPLOAD-309 at 11/18/22 7:28 PM: (( This whole jakarta thing is "no gain, and a bit of a pain". )) The [Jakarta 9 release plan|https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan] says that the idea is for a "no changes except namespaces" release, with an exception if referring to spec not transferring. Would not Fileupload v2.0 with name changes be better, and give the 3.x space for considered changes? A release of 1.4/Jakarta as 2.0 would help smooth this transition as it is significant for many projects. Or is the advice copying the code and changing it locally – which is practical for fileupload. was (Author: andy.seaborne): (( This whole jakarta thing is "no gain, and a bit of a pain". )) The [Jakarta 9 release plan](https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan) specifically says that the idea is no changes except namespaces with an exception if referring to spec not transferring. Would not Fileupload v3.0 with changes be better, and give the 3.x space for considered changes? A release of 1.4/Jakarta as 2.0 would help smooth this transition as it is significant for many projects. Or advise copying the code and changing it locally which is practical for fileupload. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616378#comment-17616378 ] Andy Seaborne commented on FILEUPLOAD-309: -- (( This whole jakarta thing is "no gain, and a bit of a pain". )) The [Jakarta 9 release plan](https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee9/JakartaEE9ReleasePlan) specifically says that the idea is no changes except namespaces with an exception if referring to spec not transferring. Would not Fileupload v3.0 with changes be better, and give the 3.x space for considered changes? A release of 1.4/Jakarta as 2.0 would help smooth this transition as it is significant for many projects. Or advise copying the code and changing it locally which is practical for fileupload. > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument
[
https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018374#comment-17018374
]
Andy Seaborne edited comment on CODEC-264 at 1/18/20 9:27 AM:
--
The v1.14 version of {{hash128(byte[], , int seed)}} does now apply the seed
mask, contrary to the comments.
Line 805
{noformat}
@Deprecated
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
//
// Note: This fails to apply masking using 0xL to the seed.
//
return hash128x64(data, offset, length, seed);
}
{noformat}
It calls {{hash128x86(byte[],, int seed)}} (exact signature match), not
{{hash128x86(byte[],, long seed)}} (type conversion).
{{hash128x86(byte[],, int seed)}} applies the mask (checked by debugger walk
through in EclipseIDE).
{{hash128(byte[],, int seed)}} should be a call of {{hash128x86(byte[],,
long)}} directly.
I think that casting at the call site will do that:
{noformat}
return hash128x64(data, offset, length, (long)seed);
{noformat}
or for clarity explicitly:
{noformat}
long seedLong = seed; /* unmasked 32->64 bit extension */
return hash128x64(data, offset, length, seedLong);
{noformat}
If the private static work function had a different name, then automatic,
unmasked conversion would have applied.
was (Author: andy.seaborne):
The v1.14 version of {{hash128(byte[], , int seed)}} does now apply the seed
mask, contrary to the comments.
Line 805
{noformat}
@Deprecated
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
//
// Note: This fails to apply masking using 0xL to the seed.
//
return hash128x64(data, offset, length, seed);
}
{noformat}
It calls {{hash128x86(byte[],, int seed)}} (exact signature match), not
{hash128x86(byte[],, long seed)}} (type conversion).
{{hash128x86(byte[],, int seed)}} applies the mask (checked by debugger walk
through in EclipseIDE).
{{hash128(byte[],, int seed)}} should be a call of {{hash128x86(byte[],,
long)}} directly.
I think that casting at the call site will do that:
{noformat}
return hash128x64(data, offset, length, (long)seed);
{noformat}
or for clarity explicitly:
{noformat}
long seedLong = seed; /* unmasked 32->64 bit extension */
return hash128x64(data, offset, length, seedLong);
{noformat}
If the private static work function had a different name, then automatic,
unmasked conversion would have applied.
> murmur3.hash128() does not account for unsigned seed argument
> -
>
> Key: CODEC-264
> URL: https://issues.apache.org/jira/browse/CODEC-264
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.13
>Reporter: Claude Warren
>Assignee: Alex Herbert
>Priority: Major
> Fix For: 1.14
>
> Attachments: YonikMurmur3Tests.java
>
>
> The original murmur3_x64_128 code used unsigned int for seed arguments.
> Using the equivalent bit patterns in the commons codec version does not yield
> the same results.
> I believe this is because the commons version does not account for sign
> extension etc.
> Yonic Seeley [~yonik] has explains the issue in his implementation
> https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java
> He provides a test case to show that his code returns the same answers as the
> original C/C++ code. I modified that test to call the codec version to show
> the error.
> I have attached that test case.
> Given that the original code is in the wild I am uncertain how to fix this
> issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument
[ https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018547#comment-17018547 ] Andy Seaborne commented on CODEC-264: - Hi Alex, I've visually inspected the code in git ([commit f5a61f0c|https://github.com/apache/commons-codec/commit/f5a61f0c]) and it looks correct. Thanks / Andy > murmur3.hash128() does not account for unsigned seed argument > - > > Key: CODEC-264 > URL: https://issues.apache.org/jira/browse/CODEC-264 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.13 >Reporter: Claude Warren >Assignee: Alex Herbert >Priority: Major > Fix For: 1.14 > > Attachments: YonikMurmur3Tests.java > > > The original murmur3_x64_128 code used unsigned int for seed arguments. > Using the equivalent bit patterns in the commons codec version does not yield > the same results. > I believe this is because the commons version does not account for sign > extension etc. > Yonic Seeley [~yonik] has explains the issue in his implementation > https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java > He provides a test case to show that his code returns the same answers as the > original C/C++ code. I modified that test to call the codec version to show > the error. > I have attached that test case. > Given that the original code is in the wild I am uncertain how to fix this > issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CODEC-264) murmur3.hash128() does not account for unsigned seed argument
[
https://issues.apache.org/jira/browse/CODEC-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17018374#comment-17018374
]
Andy Seaborne commented on CODEC-264:
-
The v1.14 version of {{hash128(byte[], , int seed)}} does now apply the seed
mask, contrary to the comments.
Line 805
{noformat}
@Deprecated
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
//
// Note: This fails to apply masking using 0xL to the seed.
//
return hash128x64(data, offset, length, seed);
}
{noformat}
It calls {{hash128x86(byte[],, int seed)}} (exact signature match), not
{hash128x86(byte[],, long seed)}} (type conversion).
{{hash128x86(byte[],, int seed)}} applies the mask (checked by debugger walk
through in EclipseIDE).
{{hash128(byte[],, int seed)}} should be a call of {{hash128x86(byte[],,
long)}} directly.
I think that casting at the call site will do that:
{noformat}
return hash128x64(data, offset, length, (long)seed);
{noformat}
or for clarity explicitly:
{noformat}
long seedLong = seed; /* unmasked 32->64 bit extension */
return hash128x64(data, offset, length, seedLong);
{noformat}
If the private static work function had a different name, then automatic,
unmasked conversion would have applied.
> murmur3.hash128() does not account for unsigned seed argument
> -
>
> Key: CODEC-264
> URL: https://issues.apache.org/jira/browse/CODEC-264
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.13
>Reporter: Claude Warren
>Assignee: Alex Herbert
>Priority: Major
> Fix For: 1.14
>
> Attachments: YonikMurmur3Tests.java
>
>
> The original murmur3_x64_128 code used unsigned int for seed arguments.
> Using the equivalent bit patterns in the commons codec version does not yield
> the same results.
> I believe this is because the commons version does not account for sign
> extension etc.
> Yonic Seeley [~yonik] has explains the issue in his implementation
> https://github.com/yonik/java_util/blob/master/src/util/hash/MurmurHash3.java
> He provides a test case to show that his code returns the same answers as the
> original C/C++ code. I modified that test to call the codec version to show
> the error.
> I have attached that test case.
> Given that the original code is in the wild I am uncertain how to fix this
> issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820850#comment-15820850 ] Andy Seaborne commented on COMMONSRDF-51: - This is confusing the lexical representation and the value space. See the text: [[ Two literals are term-equal ... Thus, two literals can have the same value without being the same RDF term. ]] I see no confusion of the character by character text - it is defining "same term", not "same value" which is what a case-insensitive lang tag comparison of use for as covered by the second part. > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell >Assignee: Stian Soiland-Reyes > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15820846#comment-15820846 ] Andy Seaborne commented on COMMONSRDF-51: - "a-z and A-Z are permitted" -- not permitted, that is the range of allowed, no more. Only ASCII characters are in a language tag. Turtle does not allow any other characters. > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell >Assignee: Stian Soiland-Reyes > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSRDF-51) RDF-1.1 specifies that language tags need to be compared using lower-case
[ https://issues.apache.org/jira/browse/COMMONSRDF-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15819001#comment-15819001 ] Andy Seaborne commented on COMMONSRDF-51: - Languages tags in BCP 47 says "ALPHA" which is defined in RFC5234 as "A-Z, a-z". > RDF-1.1 specifies that language tags need to be compared using lower-case > - > > Key: COMMONSRDF-51 > URL: https://issues.apache.org/jira/browse/COMMONSRDF-51 > Project: Apache Commons RDF > Issue Type: Bug > Components: api >Affects Versions: 0.3.0 >Reporter: Peter Ansell >Assignee: Stian Soiland-Reyes > > The [RDF-1.1 specification states that the [value space of Literal language > tags is > lowercase|https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal], which > does not conflict with the case-insensitive specification in BCP47. The > Literal.equals and Literal.hashCode API contracts should specify that > language tags must be compared using lowercase, even if they are otherwise > stored and returned as upper-case by getLanguageTag. The API currently has > incorrect language by saying "character-by-character" for language tag > comparisons, as that implies case-sensitive comparisons are used. > The lowercasing must also be done using a locale that is consistent (known > example where lowercase and uppercase do not roundtrip as expected for > US-ASCII characters is Turkish [1]), so I would recommend actually stating > that .toLowerCase(Locale.ENGLISH) is used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14577799#comment-14577799 ] Andy Seaborne commented on COLLECTIONS-442: --- [~tn],[~mbenson] - interesting to hear that. Jena has moved to Java8 and for java.lang.Iterable processing we have mostly adopted streams (or left it alone :-) ). There is still a lot of code where iterators are the design pattern and streams are not the right design so I'll be interested in looking at FluentIterable et al. A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.x Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMMONSSITE-80) Start RDF Commons
[ https://issues.apache.org/jira/browse/COMMONSSITE-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14250608#comment-14250608 ] Andy Seaborne commented on COMMONSSITE-80: -- I presume we mean a Java API here. These are not the only RDF APIs. Apache Jena has an RDF API that is widely used. Outside Apache, Sesame is another. commons-rdf is an effort with both Apache committers (1 projects) and others to find common ground for a portability layer. An important question is why? -- what does a combined/single/new API provide? For commons-rdf, the goal is portable algorithms and processing with a choice of storage. This discussion is useful: https://github.com/commons-rdf/commons-rdf/issues/35 Disclosure: I contribute to Jena and commons-rdf. Start RDF Commons - Key: COMMONSSITE-80 URL: https://issues.apache.org/jira/browse/COMMONSSITE-80 Project: Commons All Issue Type: New Feature Reporter: Reto Gmür The Apache Clerezza project has the goal to provide[a]n API modeling the W3C RDF standard without any vendor specific additions. It would be beneficial of such an API to be part of Apache Commons. With this issue the core API work at clerezza should be harmonized with other efforts like https://github.com/commons-rdf/commons-rdf in which apache committers are involved too. As a new commons-rdf project. the project should focus on a minimal API that is thus likely to be broadly accepted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated COLLECTIONS-442: -- Attachment: iter-src.zip A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.0 Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[
https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649668#comment-13649668
]
Andy Seaborne commented on COLLECTIONS-442:
---
I like the style. Attached is another take on this.
The main class is Iter that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekInterator for looking oen step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
public class IterExample
{
public static void main(String ... args)
{
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
System.out.println(iter.toList());
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}}) ;
it = Iter.distinct(it) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
A set of enhanced iterator classes donated by the Apache Jena project
-
Key: COLLECTIONS-442
URL: https://issues.apache.org/jira/browse/COLLECTIONS-442
Project: Commons Collections
Issue Type: Improvement
Components: Iterator
Reporter: Claude Warren
Fix For: 4.0
Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip
A set of templated (Generic) iterators that add filtering, mapping, and
conversion to set or list collections. Tests included.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated COLLECTIONS-442: -- Attachment: (was: iter-src.zip) A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.0 Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Seaborne updated COLLECTIONS-442: -- Attachment: iter-src.zip A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.0 Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[
https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649668#comment-13649668
]
Andy Seaborne edited comment on COLLECTIONS-442 at 5/6/13 11:41 AM:
I like the style. Attached is another take on this.
The main class is {{Iter}} that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekIterator for looking one step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
System.out.println(iter.toList());
{noformat}
and
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}}) ;
it = Iter.distinct(it) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
was (Author: andy.seaborne):
I like the style. Attached is another take on this.
The main class is Iter that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekInterator for looking oen step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
public class IterExample
{
public static void main(String ... args)
{
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
System.out.println(iter.toList());
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}}) ;
it = Iter.distinct(it) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
A set of enhanced iterator classes donated by the Apache Jena project
-
Key: COLLECTIONS-442
URL: https://issues.apache.org/jira/browse/COLLECTIONS-442
Project: Commons Collections
Issue Type: Improvement
Components: Iterator
Reporter: Claude Warren
Fix For: 4.0
Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip
A set of templated (Generic) iterators that add filtering, mapping, and
conversion to set or list collections. Tests included.
--
This message is automatically generated by JIRA.
If you think
[jira] [Comment Edited] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[
https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649668#comment-13649668
]
Andy Seaborne edited comment on COLLECTIONS-442 at 5/6/13 11:42 AM:
I like the style. Attached is another take on this.
The main class is {{Iter}} that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekIterator for looking one step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
System.out.println(iter.toList());
{noformat}
and
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }}) ;
it = Iter.distinct(it) ;
it = Iter.concat(it, x.iterator()) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
was (Author: andy.seaborne):
I like the style. Attached is another take on this.
The main class is {{Iter}} that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekIterator for looking one step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
System.out.println(iter.toList());
{noformat}
and
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override
public boolean accept(Integer item)
{
return item.intValue() = 2 ;
}}) ;
it = Iter.distinct(it) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override
public String convert(Integer item)
{
return [+String.valueOf(item)+] ;
}}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
A set of enhanced iterator classes donated by the Apache Jena project
-
Key: COLLECTIONS-442
URL: https://issues.apache.org/jira/browse/COLLECTIONS-442
Project: Commons Collections
Issue Type: Improvement
Components: Iterator
Reporter: Claude Warren
Fix For: 4.0
Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip
A set of templated (Generic) iterators that add filtering, mapping, and
conversion to set or list collections. Tests included.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[
https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13649668#comment-13649668
]
Andy Seaborne edited comment on COLLECTIONS-442 at 5/6/13 11:43 AM:
I like the style. Attached is another take on this.
The main class is {{Iter}} that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekIterator for looking one step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
System.out.println(iter.toList());
{noformat}
and
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }}) ;
it = Iter.distinct(it) ;
it = Iter.concat(it, x.iterator()) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
{noformat}
was (Author: andy.seaborne):
I like the style. Attached is another take on this.
The main class is {{Iter}} that provides two styles:
* A style like the FluentIterator style of method chaining.
* Static methods to provide short sequences to that one-step operations can be
applied to regular iterators and iterables
Also includes a PeekIterator for looking one step ahead.
The function-application style is useful for short sequences; the chainign is
better for longer sequences.
{noformat}
iter = Iter.removeNulls(iter) ;
{noformat}
Example of each style: (example.IterExample.java):
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Chaining style
IterString iter = Iter.iter(x)
.filter(new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }})
.distinct()
.append(x.iterator())
.map(new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
System.out.println(iter.toList());
{noformat}
and
{noformat}
ListInteger x = Arrays.asList(1,2,3,2,3) ;
// Function application style.
IteratorInteger it = Iter.filter(x, new FilterInteger() {
@Override public boolean accept(Integer item)
{ return item.intValue() = 2 ; }}) ;
it = Iter.distinct(it) ;
it = Iter.concat(it, x.iterator()) ;
IteratorString its = Iter.map(it, new TransformInteger,String() {
@Override public String convert(Integer item)
{ return [+String.valueOf(item)+] ; }}) ;
ListString y = Iter.toList(its) ;
System.out.println(y);
}
}
{noformat}
A set of enhanced iterator classes donated by the Apache Jena project
-
Key: COLLECTIONS-442
URL: https://issues.apache.org/jira/browse/COLLECTIONS-442
Project: Commons Collections
Issue Type: Improvement
Components: Iterator
Reporter: Claude Warren
Fix For: 4.0
Attachments: COLLECTIONS-442.tar.gz, FluentIterator.java, iter-src.zip
A set of templated (Generic) iterators that add filtering, mapping, and
conversion to set or list collections. Tests included.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13636199#comment-13636199 ] Andy Seaborne commented on COLLECTIONS-442: --- Jena also has https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/iterator/Iter.java (tests in src/test/java) with many operations plain Java iterators. A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.x Attachments: COLLECTIONS-442.tar.gz A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (COLLECTIONS-442) A set of enhanced iterator classes donated by the Apache Jena project
[ https://issues.apache.org/jira/browse/COLLECTIONS-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13636199#comment-13636199 ] Andy Seaborne edited comment on COLLECTIONS-442 at 4/19/13 9:10 AM: Jena also has https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/iterator/Iter.java (tests in src/test/java) with many operations on plain Java iterators. was (Author: andy.seaborne): Jena also has https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src/main/java/org/apache/jena/atlas/iterator/Iter.java (tests in src/test/java) with many operations plain Java iterators. A set of enhanced iterator classes donated by the Apache Jena project - Key: COLLECTIONS-442 URL: https://issues.apache.org/jira/browse/COLLECTIONS-442 Project: Commons Collections Issue Type: Improvement Components: Iterator Reporter: Claude Warren Fix For: 4.x Attachments: COLLECTIONS-442.tar.gz A set of templated (Generic) iterators that add filtering, mapping, and conversion to set or list collections. Tests included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
