from:"Jan Martin Keil \(Jira\)"

[jira] [Commented] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-23 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480867#comment-17480867
 ] 

Jan Martin Keil commented on JENA-2257:
---

Thanks a lot !

> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 4.4.0
>
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-21 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480025#comment-17480025
 ] 

Jan Martin Keil commented on JENA-2257:
---

{quote}The calculation of length can done without actually making the query 
string.{quote}

How to consider  length changes due to URL encoding then?

> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2258) LiteralLabelImpl: forward Throwabl, not only the message

2022-01-20 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-2258:
-

 Summary: LiteralLabelImpl: forward Throwabl, not only the message
 Key: JENA-2258
 URL: https://issues.apache.org/jira/browse/JENA-2258
 Project: Apache Jena
  Issue Type: Improvement
  Components: Core, Datatypes
Affects Versions: Jena 4.3.2
Reporter: Jan Martin Keil


LiteralLabelImpl: forward Throwable instead of only the message to preserve 
causes.

Pull request on https://github.com/apache/jena/pull/1170.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479850#comment-17479850
 ] 

Jan Martin Keil edited comment on JENA-2257 at 1/21/22, 6:39 AM:
-

Yes. I inspected it with a debugger and found, that {{params}} is empty and 
therefore {{{}qs.length() == 0{}}}.

Target server is [https://query.wikidata.org/sparql.]

Maybe the query should get added to {{params}} in {{query(String)}} instead of 
{{{}actualSendMode(){}}}, {{{}executeQueryPostBody(Params, String){}}}, 
{{{}executeQueryPostForm(Params, String){}}}, {{{}executeQueryGet(Params, 
String){}}}?

Further, one could have all sendMode options in {{query(String)}} logic and 
just use an extra method for the URL length calculation instead of 
{{actualSendMode()}}. That way, {{query(String)}} becomes easier to understand.


was (Author: jmkeil):
Yes. I inspected it with an debugger and found, that {{params}} is empty and 
therefore {{{}qs.length() == 0{}}}.

Target server is [https://query.wikidata.org/sparql.]

Maybe the query should get added to {{params}} in {{query(String)}} instead of 
{{{}actualSendMode(){}}}, {{{}executeQueryPostBody(Params, String){}}}, 
{{{}executeQueryPostForm(Params, String){}}}, {{{}executeQueryGet(Params, 
String){}}}?

Further, one could have all sendMode options in {{query(String)}} logic and 
just use an extra method for the URL length calculation instead of 
{{actualSendMode()}}. That way, {{query(String)}} becomes easier to understand.

> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479850#comment-17479850
 ] 

Jan Martin Keil edited comment on JENA-2257 at 1/21/22, 6:16 AM:
-

Yes. I inspected it with an debugger and found, that {{params}} is empty and 
therefore {{{}qs.length() == 0{}}}.

Target server is [https://query.wikidata.org/sparql.]

Maybe the query should get added to {{params}} in {{query(String)}} instead of 
{{{}actualSendMode(){}}}, {{{}executeQueryPostBody(Params, String){}}}, 
{{{}executeQueryPostForm(Params, String){}}}, {{{}executeQueryGet(Params, 
String){}}}?

Further, one could have all sendMode options in {{query(String)}} logic and 
just use an extra method for the URL length calculation instead of 
{{actualSendMode()}}. That way, {{query(String)}} becomes easier to understand.


was (Author: jmkeil):
Yes. I inspected it with an debugger and found, that {{params}} is empty and 
therefore {{{}qs.length() == 0{}}}.

Target server is [https://query.wikidata.org/sparql.]

Maybe the query should get added to {{params}} in {{query(String)}} instead of 
{{{}actualSendMode(){}}}, {{{}executeQueryPostBody(Params, String){}}}, 
{{{}executeQueryPostForm(Params, String){}}}, {{{}executeQueryGet(Params, 
String){}}}?

Further, one could have all sendMode options in {{query(String)}} logic and 
just use an extra method for the URL length calculation instead of 
{actualSendMode()}. That way, {{query(String)}} becomes easier to understand.

> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17479850#comment-17479850
 ] 

Jan Martin Keil commented on JENA-2257:
---

Yes. I inspected it with an debugger and found, that {{params}} is empty and 
therefore {{{}qs.length() == 0{}}}.

Target server is [https://query.wikidata.org/sparql.]

Maybe the query should get added to {{params}} in {{query(String)}} instead of 
{{{}actualSendMode(){}}}, {{{}executeQueryPostBody(Params, String){}}}, 
{{{}executeQueryPostForm(Params, String){}}}, {{{}executeQueryGet(Params, 
String){}}}?

Further, one could have all sendMode options in {{query(String)}} logic and 
just use an extra method for the URL length calculation instead of 
{actualSendMode()}. That way, {{query(String)}} becomes easier to understand.

> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2257:
--
Description: 
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
{quote}HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workarounds:
 * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
 * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_

  was:
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
{quote}HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_


> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workarounds:
>  * _QuerySendMode.systemDefault = QuerySendMode.asPost;_
>  * _QueryExecution.service(…).sendMode(QuerySendMode.asPost)_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2257:
--
Description: 
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
{quote}HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_

  was:
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody:{_}
{quote}HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_


> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody{_} (default):
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workaround:
> _QuerySendMode.systemDefault = QuerySendMode.asPost;_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2257:
--
Description: 
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody:{_}
{quote}HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_

  was:
{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody:{_}
{quote}HttpException: 414 Request-URI Too Long 
java.util.concurrent.CompletionException: HttpException: 414 Request-URI Too 
Long
    at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
    at 
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
    at 
java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:787)
    at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_


> QueryExecHTTP#actualSendMode ignores query length causing HTTP 414
> --
>
> Key: JENA-2257
> URL: https://issues.apache.org/jira/browse/JENA-2257
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ, SPARQL
>Affects Versions: Jena 4.3.2
>Reporter: Jan Martin Keil
>Priority: Major
>
> {_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
> reqAcceptHeader){_}, does not consider the length of the query. In case of 
> long queries, this causes _414 Request-URI Too Long_ errors, even if 
> {_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody:{_}
> {quote}HttpException: 414 Request-URI Too Long
>     at 
> org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
>     at 
> org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
>     at 
> org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
> {quote}
> Workaround:
> _QuerySendMode.systemDefault = QuerySendMode.asPost;_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (JENA-2257) QueryExecHTTP#actualSendMode ignores query length causing HTTP 414

2022-01-20 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-2257:
-

 Summary: QueryExecHTTP#actualSendMode ignores query length causing 
HTTP 414
 Key: JENA-2257
 URL: https://issues.apache.org/jira/browse/JENA-2257
 Project: Apache Jena
  Issue Type: Bug
  Components: ARQ, SPARQL
Affects Versions: Jena 4.3.2
Reporter: Jan Martin Keil


{_}QueryExecHTTP#actualSendMode(){_}, called in {_}QueryExecHTTP#query(String 
reqAcceptHeader){_}, does not consider the length of the query. In case of long 
queries, this causes _414 Request-URI Too Long_ errors, even if 
{_}sendMode=={_}{_}QuerySendMode{_}{_}.asGetWithLimitBody:{_}
{quote}HttpException: 414 Request-URI Too Long 
java.util.concurrent.CompletionException: HttpException: 414 Request-URI Too 
Long
    at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
    at 
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
    at 
java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:787)
    at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: HttpException: 414 Request-URI Too Long
    at 
org.apache.jena.sparql.engine.http.QueryExceptionHTTP.rewrap(QueryExceptionHTTP.java:49)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.executeQuery(QueryExecHTTP.java:493)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.query(QueryExecHTTP.java:483)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execRdfWorker(QueryExecHTTP.java:339)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.execGraph(QueryExecHTTP.java:287)
    at 
org.apache.jena.sparql.exec.http.QueryExecHTTP.construct(QueryExecHTTP.java:244)
    at 
org.apache.jena.sparql.exec.QueryExecutionAdapter.execConstruct(QueryExecutionAdapter.java:129)
{quote}
Workaround:
_QuerySendMode.systemDefault = QuerySendMode.asPost;_



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (JENA-2188) Escape % in TokenizerText#fatal

2021-11-01 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17436767#comment-17436767
 ] 

Jan Martin Keil commented on JENA-2188:
---

Yes, thanks for the hint. And thanks for fixing that.

> Escape % in TokenizerText#fatal
> ---
>
> Key: JENA-2188
> URL: https://issues.apache.org/jira/browse/JENA-2188
> Project: Apache Jena
>  Issue Type: Bug
>  Components: RIOT
>Affects Versions: Jena 4.2.0
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
>
> The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ 
> to throw an _UnknownFormatConversionException_ instead of a 
> _RiotParseException_. This happens because of the use of _String#format_ 
> without escaping "%". See the following example with an intended syntax error 
> (additional " after lang-tag):
> {code:java}
> import java.io.ByteArrayInputStream;
> import static java.nio.charset.StandardCharsets.UTF_8;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.apache.jena.riot.Lang;
> import org.apache.jena.riot.RDFParserBuilder;
> import org.junit.jupiter.api.Test;
> public class TokenizerTextTest {
>   @Test
>   public void fatal() {
> RDFParserBuilder.create().source(new ByteArrayInputStream(
>   "  \"example\"@en-US\" 
> "
>   
> .getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
>   }
> }{code}
> This causes:
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = 'D'
>   at 
> java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
>   at 
> java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
>   at java.base/java.util.Formatter.parse(Formatter.java:2713)
>   at java.base/java.util.Formatter.format(Formatter.java:2655)
>   at java.base/java.util.Formatter.format(Formatter.java:2609)
>   at java.base/java.lang.String.format(String.java:2897)
>   at 
> org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
>   at 
> org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
>   at 
> org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
>   at 
> org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
>   at 
> org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
>   at 
> org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
>   at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
>   at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
>   at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
>   at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
>   at 
> org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
>   at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
>   at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
>   at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
>   at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
>   at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
>   at 
> org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
>   at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;

public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@en-US\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.apache.jena.riot.RiotParseException;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

public class TokenizerTextTest {
  @Test
  public void fatal() {
Assertions.assertThrows(RiotParseException.class,
  () -> RDFParserBuilder.create().source(new ByteArrayInputStream(
"  \"example\"@en-US\" 
"

.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel()));
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.apache.jena.riot.RiotParseException;
import org.junit.jupiter.api.Assertions;
import org.junit.jupiter.api.Test;

public class TokenizerTextTest {
  @Test
  public void fatal() {
Assertions.assertThrows(RiotParseException.class,
  () -> RDFParserBuilder.create().source(new ByteArrayInputStream(
"  \"example\"@en-US\" 
"

.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel()));
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@en-US\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@en-US\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example with an intended syntax error (additional " after 
lang-tag):
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  
.getBytes(UTF_8))).lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  .getBytes(UTF_8))) 
.lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at

[jira] [Updated] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2188:
--
Description: 
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new ByteArrayInputStream(
  "  \"example\"@de-DE\" 
"
  .getBytes(UTF_8))) 
.lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code:java}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}

  was:
The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new 
ByteArrayInputStream("  
\"example\"@de-DE\" " .getBytes(UTF_8))) 
.lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at

[jira] [Created] (JENA-2188) Escape % in TokenizerText#fatal

2021-10-29 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-2188:
-

 Summary: Escape % in TokenizerText#fatal
 Key: JENA-2188
 URL: https://issues.apache.org/jira/browse/JENA-2188
 Project: Apache Jena
  Issue Type: Bug
  Components: RIOT
Affects Versions: Jena 4.2.0
Reporter: Jan Martin Keil


The presence of "%" near to a syntax error might cause _TokenizerText#fatal_ to 
throw an _UnknownFormatConversionException_ instead of a _RiotParseException_. 
This happens because of the use of _String#format_ without escaping "%". See 
the following example:
{code:java}
import java.io.ByteArrayInputStream;
import static java.nio.charset.StandardCharsets.UTF_8;
import org.apache.jena.rdf.model.ModelFactory;
import org.apache.jena.riot.Lang;
import org.apache.jena.riot.RDFParserBuilder;
import org.junit.jupiter.api.Test;
public class TokenizerTextTest {
  @Test
  public void fatal() {
RDFParserBuilder.create().source(new 
ByteArrayInputStream("  
\"example\"@de-DE\" " .getBytes(UTF_8))) 
.lang(Lang.NQUADS).parse(ModelFactory.createDefaultModel());
  }
}{code}
 This causes:
{code}
java.util.UnknownFormatConversionException: Conversion = 'D'
at 
java.base/java.util.Formatter$FormatSpecifier.conversion(Formatter.java:2839)
at 
java.base/java.util.Formatter$FormatSpecifier.(Formatter.java:2865)
at java.base/java.util.Formatter.parse(Formatter.java:2713)
at java.base/java.util.Formatter.format(Formatter.java:2655)
at java.base/java.util.Formatter.format(Formatter.java:2609)
at java.base/java.lang.String.format(String.java:2897)
at 
org.apache.jena.riot.tokens.TokenizerText.fatal(TokenizerText.java:1347)
at 
org.apache.jena.riot.tokens.TokenizerText.readString(TokenizerText.java:773)
at 
org.apache.jena.riot.tokens.TokenizerText.parseToken(TokenizerText.java:238)
at 
org.apache.jena.riot.tokens.TokenizerText.hasNext(TokenizerText.java:89)
at 
org.apache.jena.atlas.iterator.PeekIterator.fill(PeekIterator.java:50)
at 
org.apache.jena.atlas.iterator.PeekIterator.next(PeekIterator.java:92)
at org.apache.jena.riot.lang.LangEngine.nextToken(LangEngine.java:98)
at org.apache.jena.riot.lang.LangNQuads.parseOne(LangNQuads.java:78)
at org.apache.jena.riot.lang.LangNQuads.runParser(LangNQuads.java:53)
at org.apache.jena.riot.lang.LangBase.parse(LangBase.java:43)
at 
org.apache.jena.riot.RDFParserRegistry$ReaderRIOTLang.read(RDFParserRegistry.java:181)
at org.apache.jena.riot.RDFParser.read(RDFParser.java:358)
at org.apache.jena.riot.RDFParser.parseNotUri(RDFParser.java:348)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:295)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:241)
at org.apache.jena.riot.RDFParser.parse(RDFParser.java:250)
at 
org.apache.jena.riot.RDFParserBuilder.parse(RDFParserBuilder.java:574)
at TokenizerTextTest.fatal(TokenizerTextTest.java:17)
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2169) Dataset interface should support blank node labels for graphs

2021-09-23 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2169:
--
Description: 
The Recommendations [RDF 1.1 
TriG|https://www.w3.org/TR/trig/#sec-graph-statements] and [RDF 1.1 
N-Quads|https://www.w3.org/TR/n-quads/#simple-triples] permit blank nodes as 
graph labels in datasets. However, this is not supported in Apache Jena. To add 
support for blank node labels, the interface 
{color:#0747a6}{{org.apache.jena.query.Dataset}}{color} and it's implementing 
classes would need new methods corresponding to the following methods:
 * {color:#0747a6}{{public Model getNamedModel(String uri)}}{color} -> e.g. 
{color:#0747a6}{{public Model getLabeledModel(Resource label)}}{color}
 * {color:#0747a6}{{public Dataset addNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
addLabeledModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Dataset removeNamedModel(String uri);}}{color} -> 
e.g. {color:#0747a6}{{public Dataset removeLabeledModel(Resource 
label);}}{color}
 * {color:#0747a6}{{public Dataset replaceNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
replaceLabeledModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Iterator listNames()}}{color} -> e.g. 
{color:#0747a6}{{public Iterator listGraphLabels()}}{color}

This has real *use cases*: If labeled graphs are used to track the provenance 
of statements, as e.g. proposed in the Working Group Note [Data on the Web Best 
Practices: Data Quality Vocabulary|https://www.w3.org/TR/vocab-dqv/], minting 
an URL is not always appropriate. The current *workaround* is to mint a IRI, 
e.g. based on an UUID.
 However, there might also be *drawbacks*: The [SPARQL 1.1 
Recomendation|https://www.w3.org/TR/sparql11-query/#rGraphRef] permits only 
IRIs as graph labels. Graphs with blank node labels might become inaccessible 
within SPARQL. But that is probably (didn't test it yet) the same situation as 
after importing TriG or N-Quads files with blank node graph labels. (A 
shortcoming of SPARQL 1.1 worth to put on [https://github.com/w3c/sparql-12]?)

  was:
The Recommendations [RDF 1.1 
TriG|https://www.w3.org/TR/trig/#sec-graph-statements] and [RDF 1.1 
N-Quads|https://www.w3.org/TR/n-quads/#simple-triples] permit blank nodes as 
graph labels in datasets. However, this is not supported in Apache Jena. To add 
support for blank node labels, the interface 
{color:#0747a6}{{org.apache.jena.query.Dataset}}{color} and it's implementing 
classes would need new methods corresponding to the following methods:
 * {color:#0747a6}{{public Model getNamedModel(String uri)}}{color} -> e.g. 
{color:#0747a6}{{public Model getLabeledModel(Resource label)}}{color}
 * {color:#0747a6}{{public Dataset addNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
addLabeledModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Dataset removeNamedModel(String uri);}}{color} -> 
e.g. {color:#0747a6}{{public Dataset removeLabeledModel(Resource 
label);}}{color}
 * {color:#0747a6}{{public Dataset replaceNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
replaceLabelesModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Iterator listNames()}}{color} -> e.g. 
{color:#0747a6}{{public Iterator listGraphLabels()}}{color}

This has real *use cases*: If labeled graphs are used to track the provenance 
of statements, as e.g. proposed in the Working Group Note [Data on the Web Best 
Practices: Data Quality Vocabulary|https://www.w3.org/TR/vocab-dqv/], minting 
an URL is not always appropriate. The current *workaround* is to mint a IRI, 
e.g. based on an UUID.
 However, there might also be *drawbacks*: The [SPARQL 1.1 
Recomendation|https://www.w3.org/TR/sparql11-query/#rGraphRef] permits only 
IRIs as graph labels. Graphs with blank node labels might become inaccessible 
within SPARQL. But that is probably (didn't test it yet) the same situation as 
after importing TriG or N-Quads files with blank node graph labels. (A 
shortcoming of SPARQL 1.1 worth to put on [https://github.com/w3c/sparql-12]?)


> Dataset interface should support blank node labels for graphs
> -
>
> Key: JENA-2169
> URL: https://issues.apache.org/jira/browse/JENA-2169
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The Recommendations [RDF 1.1 
> TriG|https://www.w3.org/TR/trig/#sec-graph-statements] and [RDF 1.1 
> N-Quads|https://www.w3.org/TR/n-quads/#simple-triples] permit blank nodes as 
> graph labels in datasets. However, this is not supported in Apache Jena. To 
> add support for blank node labels, the

[jira] [Created] (JENA-2169) Dataset interface should support blank node labels for graphs

2021-09-23 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-2169:
-

 Summary: Dataset interface should support blank node labels for 
graphs
 Key: JENA-2169
 URL: https://issues.apache.org/jira/browse/JENA-2169
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


The Recommendations [RDF 1.1 
TriG|https://www.w3.org/TR/trig/#sec-graph-statements] and [RDF 1.1 
N-Quads|https://www.w3.org/TR/n-quads/#simple-triples] permit blank nodes as 
graph labels in datasets. However, this is not supported in Apache Jena. To add 
support for blank node labels, the interface 
{color:#0747a6}{{org.apache.jena.query.Dataset}}{color} and it's implementing 
classes would need new methods corresponding to the following methods:
 * {color:#0747a6}{{public Model getNamedModel(String uri)}}{color} -> e.g. 
{color:#0747a6}{{public Model getLabeledModel(Resource label)}}{color}
 * {color:#0747a6}{{public Dataset addNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
addLabeledModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Dataset removeNamedModel(String uri);}}{color} -> 
e.g. {color:#0747a6}{{public Dataset removeLabeledModel(Resource 
label);}}{color}
 * {color:#0747a6}{{public Dataset replaceNamedModel(String uri, Model 
model);}}{color} -> e.g. {color:#0747a6}{{public Dataset 
replaceLabelesModel(Resource label, Model model);}}{color}
 * {color:#0747a6}{{public Iterator listNames()}}{color} -> e.g. 
{color:#0747a6}{{public Iterator listGraphLabels()}}{color}

This has real *use cases*: If labeled graphs are used to track the provenance 
of statements, as e.g. proposed in the Working Group Note [Data on the Web Best 
Practices: Data Quality Vocabulary|https://www.w3.org/TR/vocab-dqv/], minting 
an URL is not always appropriate. The current *workaround* is to mint a IRI, 
e.g. based on an UUID.
 However, there might also be *drawbacks*: The [SPARQL 1.1 
Recomendation|https://www.w3.org/TR/sparql11-query/#rGraphRef] permits only 
IRIs as graph labels. Graphs with blank node labels might become inaccessible 
within SPARQL. But that is probably (didn't test it yet) the same situation as 
after importing TriG or N-Quads files with blank node graph labels. (A 
shortcoming of SPARQL 1.1 worth to put on [https://github.com/w3c/sparql-12]?)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2042) FusekiServer::getPort() does not return actual port

2021-02-08 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2042:
--
Description: 
{{FusekiServer::getPort()}} does not return the actual port (but 0), if Fuseki 
was configured to select a random free port. E.g. 
{{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I would 
expect and Java Doc states the method should return the selected port.

In case of HTTP only, one can use {{((ServerConnector) 
fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. However, 
including HTTPS, things become more complicated, as the correct port of the 
correct connector needs to be selected first.

  was:
{{FusekiServer::getPort()}} does not return the actual port (but 0), if Fuseki 
was configured to select a random free port. E.g. 
{{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I would 
expect and Java Doc states the method should return the selected port.

In case of HTTP only, one can use {{((ServerConnector) 
fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. However, 
including HTTPS, things become a little bit more complicated, as the correct 
port of the correct connector needs to be selected first.


> FusekiServer::getPort() does not return actual port
> ---
>
> Key: JENA-2042
> URL: https://issues.apache.org/jira/browse/JENA-2042
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.17.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> {{FusekiServer::getPort()}} does not return the actual port (but 0), if 
> Fuseki was configured to select a random free port. E.g. 
> {{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I 
> would expect and Java Doc states the method should return the selected port.
> In case of HTTP only, one can use {{((ServerConnector) 
> fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. 
> However, including HTTPS, things become more complicated, as the correct port 
> of the correct connector needs to be selected first.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-2042) FusekiServer::getPort() does not return actual port

2021-02-08 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-2042:
--
Description: 
{{FusekiServer::getPort()}} does not return the actual port (but 0), if Fuseki 
was configured to select a random free port. E.g. 
{{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I would 
expect and Java Doc states the method should return the selected port.

In case of HTTP only, one can use {{((ServerConnector) 
fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. However, 
including HTTPS, things become a little bit more complicated, as the correct 
port of the correct connector needs to be selected first.

  was:
{{FusekiServer::getPort()}} does not return the actual port (but 0), if Fuseki 
was configured to select a random free port). E.g. 
{{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I would 
expect and Java Doc states the method should return the selected port.

In case of HTTP only, one can use {{((ServerConnector) 
fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. However, 
including HTTPS, things become a little bit more complicated, as the correct 
port of the correct connector needs to be selected first.


> FusekiServer::getPort() does not return actual port
> ---
>
> Key: JENA-2042
> URL: https://issues.apache.org/jira/browse/JENA-2042
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Jena 3.17.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> {{FusekiServer::getPort()}} does not return the actual port (but 0), if 
> Fuseki was configured to select a random free port. E.g. 
> {{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I 
> would expect and Java Doc states the method should return the selected port.
> In case of HTTP only, one can use {{((ServerConnector) 
> fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. 
> However, including HTTPS, things become a little bit more complicated, as the 
> correct port of the correct connector needs to be selected first.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-2042) FusekiServer::getPort() does not return actual port

2021-02-08 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-2042:
-

 Summary: FusekiServer::getPort() does not return actual port
 Key: JENA-2042
 URL: https://issues.apache.org/jira/browse/JENA-2042
 Project: Apache Jena
  Issue Type: Bug
  Components: Fuseki
Affects Versions: Jena 3.17.0
Reporter: Jan Martin Keil


{{FusekiServer::getPort()}} does not return the actual port (but 0), if Fuseki 
was configured to select a random free port). E.g. 
{{FusekiServer.create().port(0).build().start().getPort()}} returns 0. I would 
expect and Java Doc states the method should return the selected port.

In case of HTTP only, one can use {{((ServerConnector) 
fuseki.getJettyServer().getConnectors()[0]).getLocalPort()}} instead. However, 
including HTTPS, things become a little bit more complicated, as the correct 
port of the correct connector needs to be selected first.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1956) ResultSet should implement Iterable

2020-09-25 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202003#comment-17202003
 ] 

Jan Martin Keil commented on JENA-1956:
---

{quote}The code example would fail to close the query execution. For remote 
execution, it is important to close the QueryExecution object to free up HTTP 
cache connections for the cached connection pool.
{quote}
Sure, but they are just minimal examples and the error handling can be added 
the same way in both:
{code:java}
try (QueryExecution qExec = QueryExecutionFactory.create(...) ) {
  for (QuerySolution result : qExec.execSelect()) {
…
  }
}
{code}
instead of
{code:java}
try (QueryExecution qExec = QueryExecutionFactory.create(...) ) {
  ResultSet results = qExec.execSelect();
  while (results.hasNext()) {
QuerySolution result = results.next();
…
  }
}
{code}
On the other hand, Consumers are limited in error handling to throw 
RuntimeExceptions only. But it is an option.

> ResultSet should implement Iterable
> ---
>
> Key: JENA-1956
> URL: https://issues.apache.org/jira/browse/JENA-1956
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The class {{ResultSet}} should implement {{Iterable}}. That 
> would significantly ease query result processing. It would allow to write
> {code:java}
> for (QuerySolution result : QueryExecutionFactory.create(query, 
> model).execSelect()) {
>   …
> }
> {code}
> instead of
> {code:java}
> ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
> while (results.hasNext()) {
>   QuerySolution result = results.next();
>   …
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1955) Make use of Optional or NoSuchElementException

2020-08-28 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1955:
--
Description: 
Many methods currently return {{null}} or an empty String, if something was not 
present. It would significantly ease writing stable and fault-tolerant code, if 
this methods would be replaced be methods returning an {{java.util.Optional}} 
(preferred) or throwing an {{NoSuchElementException}} instead.

Best way to do that would probably be to deprecate the current methods for the 
time being and add new methods using {{java.util.Optional}} or 
{{NoSuchElementException}}.

An (probably incomplete) example list of affected methods:
 * {{QuerySolution#get(String)}}
 * {{QuerySolution#getResource(String)}}
 * {{QuerySolution#getLiteral(String)}}
 * {{Literal#getLanguage()}}

  was:
Many methods currently return {{null}} or an empty String, if something was not 
present. It would significantly ease writing stable and fault-tolerant code, if 
this methods would be replaced be methods returning an {{java.util.Optional}} 
(preferred) or throwing an {{NoSuchElementException}} instead.

Best way to do that would probably be to deprecate the current methods for the 
time being and add new methods using {{java.util.Optional}} or 
{{NoSuchElementException}}.

An probably incomplete/example list of affected methods:
* {{QuerySolution#get(String)}}
* {{QuerySolution#getResource(String)}}
* {{QuerySolution#getLiteral(String)}}
* {{Literal#getLanguage()}}


> Make use of Optional or NoSuchElementException
> --
>
> Key: JENA-1955
> URL: https://issues.apache.org/jira/browse/JENA-1955
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> Many methods currently return {{null}} or an empty String, if something was 
> not present. It would significantly ease writing stable and fault-tolerant 
> code, if this methods would be replaced be methods returning an 
> {{java.util.Optional}} (preferred) or throwing an {{NoSuchElementException}} 
> instead.
> Best way to do that would probably be to deprecate the current methods for 
> the time being and add new methods using {{java.util.Optional}} or 
> {{NoSuchElementException}}.
> An (probably incomplete) example list of affected methods:
>  * {{QuerySolution#get(String)}}
>  * {{QuerySolution#getResource(String)}}
>  * {{QuerySolution#getLiteral(String)}}
>  * {{Literal#getLanguage()}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1956) ResultSet should implement Iterable

2020-08-28 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1956:
--
Description: 
The class {{ResultSet}} should implement {{Iterable}}. That 
would significantly ease query result processing. It would allow to write
{code:java}
for (QuerySolution result : QueryExecutionFactory.create(query, 
model).execSelect()) {
  …
}
{code}
instead of
{code:java}
ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
while (results.hasNext()) {
  QuerySolution result = results.next();
  …
}
{code}

  was:
The class {{ResultSet}} should implement {{Iterable}}. That 
would significantly ease query result processing, if ResultSet would implement 
Iterable. That would allow to write
{code:java}
for (QuerySolution result : QueryExecutionFactory.create(query, 
model).execSelect()) {
  …
}
{code}
instead of
{code:java}
ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
while (results.hasNext()) {
  QuerySolution result = results.next();
  …
}
{code}


> ResultSet should implement Iterable
> ---
>
> Key: JENA-1956
> URL: https://issues.apache.org/jira/browse/JENA-1956
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The class {{ResultSet}} should implement {{Iterable}}. That 
> would significantly ease query result processing. It would allow to write
> {code:java}
> for (QuerySolution result : QueryExecutionFactory.create(query, 
> model).execSelect()) {
>   …
> }
> {code}
> instead of
> {code:java}
> ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
> while (results.hasNext()) {
>   QuerySolution result = results.next();
>   …
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1956) ResultSet should implement Iterable

2020-08-28 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1956:
--
Description: 
The class {{ResultSet}} should implement {{Iterable}}. That 
would significantly ease query result processing, if ResultSet would implement 
Iterable. That would allow to write
{code:java}
for (QuerySolution result : QueryExecutionFactory.create(query, 
model).execSelect()) {
  …
}
{code}
instead of
{code:java}
ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
while (results.hasNext()) {
  QuerySolution result = results.next();
  …
}
{code}

  was:
It would significantly ease query result processing, if ResultSet would 
implement Iterable. That would allow to write
{code:java}
for (QuerySolution result : QueryExecutionFactory.create(query, 
model).execSelect()) {
  …
}
{code}
instead of
{code:java}
ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
while (results.hasNext()) {
  QuerySolution result = results.next();
  …
}
{code}


> ResultSet should implement Iterable
> ---
>
> Key: JENA-1956
> URL: https://issues.apache.org/jira/browse/JENA-1956
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> The class {{ResultSet}} should implement {{Iterable}}. That 
> would significantly ease query result processing, if ResultSet would 
> implement Iterable. That would allow to write
> {code:java}
> for (QuerySolution result : QueryExecutionFactory.create(query, 
> model).execSelect()) {
>   …
> }
> {code}
> instead of
> {code:java}
> ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
> while (results.hasNext()) {
>   QuerySolution result = results.next();
>   …
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1956) ResultSet should implement Iterable

2020-08-28 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1956:
-

 Summary: ResultSet should implement Iterable
 Key: JENA-1956
 URL: https://issues.apache.org/jira/browse/JENA-1956
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


It would significantly ease query result processing, if ResultSet would 
implement Iterable. That would allow to write
{code:java}
for (QuerySolution result : QueryExecutionFactory.create(query, 
model).execSelect()) {
  …
}
{code}
instead of
{code:java}
ResultSet results = QueryExecutionFactory.create(query, model).execSelect();
while (results.hasNext()) {
  QuerySolution result = results.next();
  …
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1955) Make use of Optional or NoSuchElementException

2020-08-28 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1955:
-

 Summary: Make use of Optional or NoSuchElementException
 Key: JENA-1955
 URL: https://issues.apache.org/jira/browse/JENA-1955
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


Many methods currently return {{null}} or an empty String, if something was not 
present. It would significantly ease writing stable and fault-tolerant code, if 
this methods would be replaced be methods returning an {{java.util.Optional}} 
(preferred) or throwing an {{NoSuchElementException}} instead.

Best way to do that would probably be to deprecate the current methods for the 
time being and add new methods using {{java.util.Optional}} or 
{{NoSuchElementException}}.

An probably incomplete/example list of affected methods:
* {{QuerySolution#get(String)}}
* {{QuerySolution#getResource(String)}}
* {{QuerySolution#getLiteral(String)}}
* {{Literal#getLanguage()}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (JENA-1954) Explicit declaration and documentation of thrown exception type

2020-08-28 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1954:
-

 Summary: Explicit declaration and documentation of thrown 
exception type
 Key: JENA-1954
 URL: https://issues.apache.org/jira/browse/JENA-1954
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


It would be very helpful, if methods and javadoc would make explicit the type 
of thrown exceptions. That would significantly ease writing stable and 
fault-tolerant code. The problem affects at least various methods of the 
classes {{QuerySolution}}, {{RDFNode}}, {{Resource}}, {{Literal}}, but probably 
more.

For example add
{code:java}
@throws ClassCastException if the variable was present but not a literal
{code}
and
{code:java}
throws ClassCastException
{code}
into
{code:java}
public interface QuerySolution { 

…

/** Return the value of the named variable in this binding, casting to a 
Literal.
 * A return of null indicates that the variable is not present in this solution.
 * An exception indicates it was present but not a literal.
 * @param varName
 * @return Resource
 */
 public Literal getLiteral(String varName);

…

} {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (JENA-1943) Increase Precision of Decimal Calculation Results

2020-08-17 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179054#comment-17179054
 ] 

Jan Martin Keil commented on JENA-1943:
---

Yes, my point was the division. Other things were just thought for distinction. 
I could have made that more clear. Thank you for the fast fix. I'm looking 
forward for the next release.

> Increase Precision of Decimal Calculation Results
> -
>
> Key: JENA-1943
> URL: https://issues.apache.org/jira/browse/JENA-1943
> Project: Apache Jena
>  Issue Type: Bug
>  Components: ARQ
>Affects Versions: Jena 3.14.0, Jena 3.16.0
>Reporter: Jan Martin Keil
>Assignee: Andy Seaborne
>Priority: Major
> Fix For: Jena 3.17.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The precision of calculation results with type {{xsd:decimal}} is limited 
> without need.
> An Example:
> {code:java}
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class MaxDecimalDivissionPrecissionTest {
>   @Test
>   public void maxDecimalDivissionPrecission() {
>   String query = "PREFIX xsd:  
> "//
>   + "SELECT"//
>   + "  ( 
> STR(1/STRDT(\"1\", xsd:decimal)) AS ?times10)"//
>   + "  ( 
> STR(1/STRDT(\"10\", xsd:decimal)) AS ?calculated)"//
>   + "  
> (DATATYPE(1/STRDT(\"10\", xsd:decimal)) AS ?type)"//
>   + "  ( STR(  
> STRDT(\"0.1\", xsd:decimal)) AS ?direct)"//
>   + "  ( 
> STR(1/STRDT(\"0.01\", 
> xsd:decimal)) AS ?large)"//
>   + "WHERE {}";
>   System.out.println(QueryExecutionFactory.create(query, 
> ModelFactory.createDefaultModel()).execSelect().next().toString().replace(" 
> (", "\n("));
>   }
> }
> {code}
> Output:
> {code:java}
> ( ?times10 = "0.0001" )
> ( ?direct = "0.1" )
> ( ?calculated = "0.0" )
> ( ?large = "100.0" )
> ( ?type = xsd:decimal )
> {code}
>  
>  I would expect {{?calculated == ?direct}}. This only affects very small 
> numbers, very large numbers are not affected. I also checked 
> [Wikibase|https://query.wikidata.org/#PREFIX%20xsd%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%3E%20%0ASELECT%0A%20%20%28STR%281%2FSTRDT%28%221%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Ftimes10%29%0A%20%20%28STR%281%2FSTRDT%28%2210%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Fcalculated%29%0A%20%20%28STR%28%20%20STRDT%28%220.1%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Fdirect%29%0A%20%20%28DATATYPE%28STRDT%28%220.1%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Ftype%29%0A%20%20%28STR%281%2FSTRDT%28%220.01%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Flarge%29%0AWHERE%20%7B%7D]
>  and RDF4J and did not find this limitation. Please consider to remove this 
> limitation as I need higher precision in a view cases in a project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1943) Increase Precision of Decimal Calculation Results

2020-08-14 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1943:
--
Description: 
The precision of calculation results with type {{xsd:decimal}} is limited 
without need.

An Example:
{code:java}
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.rdf.model.ModelFactory;
import org.junit.jupiter.api.Test;

public class MaxDecimalDivissionPrecissionTest {

@Test
public void maxDecimalDivissionPrecission() {
String query = "PREFIX xsd:  
"//
+ "SELECT"//
+ "  ( 
STR(1/STRDT(\"1\", xsd:decimal)) AS ?times10)"//
+ "  ( 
STR(1/STRDT(\"10\", xsd:decimal)) AS ?calculated)"//
+ "  
(DATATYPE(1/STRDT(\"10\", xsd:decimal)) AS ?type)"//
+ "  ( STR(  
STRDT(\"0.1\", xsd:decimal)) AS ?direct)"//
+ "  ( 
STR(1/STRDT(\"0.01\", xsd:decimal)) 
AS ?large)"//
+ "WHERE {}";
System.out.println(QueryExecutionFactory.create(query, 
ModelFactory.createDefaultModel()).execSelect().next().toString().replace(" (", 
"\n("));
}
}
{code}
Output:
{code:java}
( ?times10 = "0.0001" )
( ?direct = "0.1" )
( ?calculated = "0.0" )
( ?large = "100.0" )
( ?type = xsd:decimal )
{code}
 
 I would expect {{?calculated == ?direct}}. This only affects very small 
numbers, very large numbers are not affected. I also checked 
[Wikibase|https://query.wikidata.org/#PREFIX%20xsd%3A%20%3Chttp%3A%2F%2Fwww.w3.org%2F2001%2FXMLSchema%23%3E%20%0ASELECT%0A%20%20%28STR%281%2FSTRDT%28%221%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Ftimes10%29%0A%20%20%28STR%281%2FSTRDT%28%2210%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Fcalculated%29%0A%20%20%28STR%28%20%20STRDT%28%220.1%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Fdirect%29%0A%20%20%28DATATYPE%28STRDT%28%220.1%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Ftype%29%0A%20%20%28STR%281%2FSTRDT%28%220.01%22%2C%20xsd%3Adecimal%29%29%20AS%20%3Flarge%29%0AWHERE%20%7B%7D]
 and RDF4J and did not find this limitation. Please consider to remove this 
limitation as I need higher precision in a view cases in a project.

  was:
The precision of calculation results with type {{xsd:decimal}} is limited 
without need.

An Example:
{code:java}
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.rdf.model.ModelFactory;
import org.junit.jupiter.api.Test;

public class MaxDecimalDivissionPrecissionTest {

@Test
public void maxDecimalDivissionPrecission() {
String query = "PREFIX xsd:  
"//
+ "SELECT"//
+ "  ( 
STR(1/STRDT(\"1\", xsd:decimal)) AS ?times10)"//
+ "  ( 
STR(1/STRDT(\"10\", xsd:decimal)) AS ?calculated)"//
+ "  
(DATATYPE(1/STRDT(\"10\", xsd:decimal)) AS ?type)"//
+ "  ( STR(  
STRDT(\"0.1\", xsd:decimal)) AS ?direct)"//
+ "  ( 
STR(1/STRDT(\"0.01\", xsd:decimal)) 
AS ?large)"//
+ "WHERE {}";
System.out.println(QueryExecutionFactory.create(query, 
ModelFactory.createDefaultModel()).execSelect().next().toString().replace(" (", 
"\n("));
}
}
{code}
Output:
{code:java}
( ?times10 = "0.0001" )
( ?direct = "0.1" )
( ?calculated = "0.0" )
( ?large = "100.0" )
( ?type = xsd:decimal )
{code}
 
 I would expect {{?calculated == ?direct}}. This only affects very small 
numbers, very large numbers are not affected. I also checked

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

2020-03-04 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17051149#comment-17051149
 ] 

Jan Martin Keil commented on JENA-1841:
---

{quote}putting in a registration step will work for you? This seems like the 
correct way. The rest of this discussion is about how to deal with the 
"incorrect setup" case of no prior registration.
{quote}
Sure, that is a convenient way to do this, similar to the Converters in JPA or 
the De-/Serializers in Jackson. And I used a similar approach to work around 
this bug, but unfortunately without using {{TypeMapper}}, as I did not know it. 
Would be helpful to mention the {{TypeMapper}} in the new exception to give a 
hint to developers.

Just to mention it: Compared to e.g. Jackson I see the drawback that it is not 
possible to have different TypeMappers and therefore different conversions for 
the same DataType. But that is another issue (and does not affect me).

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid =

[jira] [Comment Edited] (JENA-1841) Side Effect of Datatype Use in Query

2020-03-03 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050973#comment-17050973
 ] 

Jan Martin Keil edited comment on JENA-1841 at 3/4/20, 7:58 AM:


{quote}Would it make sense that rather than throw an exception just call 
createLiteral( o.toString() ); ?
{quote}
I would expect the library to throw some proper Exception, instead of doing 
some hidden magic that might fit most developers needs. If I did understand it 
right, using {{createLiteral( o.toString() );}} further has the disadvantage 
that it might fall back to {{Object#toString()}} for other classes. In this 
case it will only give the class name and hash, which is worthless in an RDF 
document or SPARQL query. For broader class support out of the box, one could 
make use of the {{Serializable}} interface. The result, however, is not a nice 
representation to use in RDF.
{quote}Finally - did the code mean to use a URI: 
?
{quote}
No.


was (Author: jmkeil):
{quote}Would it make sense that rather than throw an exception just call 
createLiteral( o.toString() ); ?
{quote}
I would expect the library to throw some proper Exception, instead of doing 
some hidden magic that might fit most developers needs. If I did understand it 
right, using {{createLiteral( o.toString() );}} further has the disadvantage 
that it might fall back to {{Object#toString()}} for other classes. In this 
case it will only give the class name and hash, which is worthless in an RDF 
document or SPARQL query. For broader class support out of the box, one could 
make use of the {{Serializable}} interface. The result, however is not a nice 
representation to use in RDF.
{quote}Finally - did the code mean to use a URI: 
?
{quote}
No.

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>

[jira] [Commented] (JENA-1841) Side Effect of Datatype Use in Query

2020-03-03 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17050973#comment-17050973
 ] 

Jan Martin Keil commented on JENA-1841:
---

{quote}Would it make sense that rather than throw an exception just call 
createLiteral( o.toString() ); ?
{quote}
I would expect the library to throw some proper Exception, instead of doing 
some hidden magic that might fit most developers needs. If I did understand it 
right, using {{createLiteral( o.toString() );}} further has the disadvantage 
that it might fall back to {{Object#toString()}} for other classes. In this 
case it will only give the class name and hash, which is worthless in an RDF 
document or SPARQL query. For broader class support out of the box, one could 
make use of the {{Serializable}} interface. The result, however is not a nice 
representation to use in RDF.
{quote}Finally - did the code mean to use a URI: 
?
{quote}
No.

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific piece of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
>

[jira] [Updated] (JENA-1841) Side Effect of Datatype Use in Query

2020-03-02 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1841:
--
Description: 
I faced a bug caused by a side effect of using the datatype 
 in a query.

Short story is that you can not use this datatype in model parsing or queries 
after you once used it in a query.

I did not completely  break it down to a specific piece of code, but I wrote 
some testcases that narrow down the issue. Please note that the order of 
execution of the test methods effect the result. So please first try to execute 
single test methods before executing the whole test class.
{code:java}

import java.io.ByteArrayInputStream;
import java.util.UUID;

import org.apache.jena.arq.querybuilder.SelectBuilder;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.junit.jupiter.api.Test;

public class UuidParsingintoModelOrQuery {

@Test
public void uuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----");
UUID uuid2 = 
UUID.fromString("----0001");

String modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid1 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
modelStr = "_:a  \"" + uuid2 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void sameUuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----0002");
UUID uuid2 = 
UUID.fromString("----0003");
String modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void sameUuidParsingIntoMultipleModel() throws Exception {
UUID uuid = 
UUID.fromString("----0004");
String modelStr = "_:a  \"" + uuid + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void uuidUseInQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0005");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
}

@Test
public void uuidParsingIntoQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0006");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = 
QueryExecutionFactory.create(select.toString());
}

@Test
public void uuidUseInQueryAndParsingIntoModel() throws Exception {
UUID uuid = 
UUID.fromString("----0007");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
String modelStr = "_:a  \"" + uuid + 
"\"^^ .\n"
+ "_:a  \"" + uuid + 
"\"^^ .";
Model model = ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "",
"N-TRIPLE");
}
}
{code}

  was:
I faced a bug caused by a side effect

[jira] [Commented] (JENA-1842) Replace System..print with Log.*

2020-02-19 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17040744#comment-17040744
 ] 

Jan Martin Keil commented on JENA-1842:
---

I took a brief look on 
[https://github.com/apache/jena/search?q=System.err.println|https://github.com/apache/jena/search?q=System.err.println],
 and some of the results looked like further cases. But I did not check that in 
detail.

> Replace System.*.print* with Log.*
> --
>
> Key: JENA-1842
> URL: https://issues.apache.org/jira/browse/JENA-1842
> Project: Apache Jena
>  Issue Type: Improvement
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> Apache Jena uses {{Sytem.err.print*}} (e.g. {{ParserSPARQL11#perform}}) 
> outside of testcases, cmd tools, and examples. This makes it hard to control 
> the output of software using the Jena libraries. I recommend to consistently 
> replace them with appropriated {{Log.info}}, {{Log.warn}}, or {{Log.error}} 
> calls.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1841) Side Effect of Datatype Use in Query

2020-02-17 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1841:
--
Issue Type: Bug  (was: Improvement)

> Side Effect of Datatype  Use in Query
> --
>
> Key: JENA-1841
> URL: https://issues.apache.org/jira/browse/JENA-1841
> Project: Apache Jena
>  Issue Type: Bug
>Affects Versions: Jena 3.14.0
>Reporter: Jan Martin Keil
>Priority: Major
>
> I faced a bug caused by a side effect of using the datatype 
>  in a query.
> Short story is that you can not use this datatype in model parsing or queries 
> after you once used it in a query.
> I did not completely  break it down to a specific peace of code, but I wrote 
> some testcases that narrow down the issue. Please note that the order of 
> execution of the test methods effect the result. So please first try to 
> execute single test methods before executing the whole test class.
> {code:java}
> import java.io.ByteArrayInputStream;
> import java.util.UUID;
> import org.apache.jena.arq.querybuilder.SelectBuilder;
> import org.apache.jena.query.QueryExecution;
> import org.apache.jena.query.QueryExecutionFactory;
> import org.apache.jena.rdf.model.Model;
> import org.apache.jena.rdf.model.ModelFactory;
> import org.junit.jupiter.api.Test;
> public class UuidParsingintoModelOrQuery {
>   @Test
>   public void uuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----");
>   UUID uuid2 = 
> UUID.fromString("----0001");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid1 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   modelStr = "_:a  \"" + uuid2 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoSingleModel() throws Exception {
>   UUID uuid1 = 
> UUID.fromString("----0002");
>   UUID uuid2 = 
> UUID.fromString("----0003");
>   String modelStr = "_:a  \"" + uuid1 + 
> "\"^^ .\n"
>   + "_:a  \"" + uuid2 + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   // repeat
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void sameUuidParsingIntoMultipleModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0004");
>   String modelStr = "_:a  \"" + uuid + 
> "\"^^ .";
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   ModelFactory.createDefaultModel().read(new 
> ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
>   }
>   @Test
>   public void uuidUseInQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0005");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = QueryExecutionFactory.create(select.build());
>   }
>   @Test
>   public void uuidParsingIntoQuery() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0006");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>   QueryExecution q = 
> QueryExecutionFactory.create(select.toString());
>   }
>   @Test
>   public void uuidUseInQueryAndParsingIntoModel() throws Exception {
>   UUID uuid = 
> UUID.fromString("----0007");
>   SelectBuilder select = new SelectBuilder();
>   select.addWhere("?a", "", "?uuid");
>   select.addFilter(select.getExprFactory().eq("?uuid", uuid));
>

[jira] [Created] (JENA-1842) Replace System..print with Log.*

2020-02-17 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1842:
-

 Summary: Replace System.*.print* with Log.*
 Key: JENA-1842
 URL: https://issues.apache.org/jira/browse/JENA-1842
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: Jena 3.14.0
Reporter: Jan Martin Keil


Apache Jena uses {{Sytem.err.print*}} (e.g. {{ParserSPARQL11#perform}}) outside 
of testcases, cmd tools, and examples. This makes it hard to control the output 
of software using the Jena libraries. I recommend to consistently replace them 
with appropriated {{Log.info}}, {{Log.warn}}, or {{Log.error}} calls.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (JENA-1841) Side Effect of Datatype Use in Query

2020-02-17 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1841:
--
Description: 
I faced a bug caused by a side effect of using the datatype 
 in a query.

Short story is that you can not use this datatype in model parsing or queries 
after you once used it in a query.

I did not completely  break it down to a specific peace of code, but I wrote 
some testcases that narrow down the issue. Please note that the order of 
execution of the test methods effect the result. So please first try to execute 
single test methods before executing the whole test class.
{code:java}

import java.io.ByteArrayInputStream;
import java.util.UUID;

import org.apache.jena.arq.querybuilder.SelectBuilder;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.junit.jupiter.api.Test;

public class UuidParsingintoModelOrQuery {

@Test
public void uuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----");
UUID uuid2 = 
UUID.fromString("----0001");

String modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid1 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
modelStr = "_:a  \"" + uuid2 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void sameUuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----0002");
UUID uuid2 = 
UUID.fromString("----0003");
String modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void sameUuidParsingIntoMultipleModel() throws Exception {
UUID uuid = 
UUID.fromString("----0004");
String modelStr = "_:a  \"" + uuid + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}

@Test
public void uuidUseInQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0005");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
}

@Test
public void uuidParsingIntoQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0006");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = 
QueryExecutionFactory.create(select.toString());
}

@Test
public void uuidUseInQueryAndParsingIntoModel() throws Exception {
UUID uuid = 
UUID.fromString("----0007");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
String modelStr = "_:a  \"" + uuid + 
"\"^^ .\n"
+ "_:a  \"" + uuid + 
"\"^^ .";
Model model = ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "",
"N-TRIPLE");
}
}
{code}

  was:
I faced a bug caused by a side effect

[jira] [Created] (JENA-1841) Side Effect of Datatype Use in Query

2020-02-17 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1841:
-

 Summary: Side Effect of Datatype  Use in Query
 Key: JENA-1841
 URL: https://issues.apache.org/jira/browse/JENA-1841
 Project: Apache Jena
  Issue Type: Improvement
Affects Versions: Jena 3.14.0
Reporter: Jan Martin Keil


I faced a bug caused by a side effect of using the datatype 
 in a query.

Short story is that you can not use this datatype in model parsing or queries 
after you once used it in a query.

I did not completely  break it down to a specific peace of code, but I wrote 
some testcases that narrow down the issue. Please note that the order of 
execution of the test methods effect the result. So please first try to execute 
single test methods before executing the whole test class.
{code:java}
import java.io.ByteArrayInputStream;
import java.util.UUID;import org.apache.jena.arq.querybuilder.SelectBuilder;
import org.apache.jena.query.QueryExecution;
import org.apache.jena.query.QueryExecutionFactory;
import org.apache.jena.rdf.model.Model;
import org.apache.jena.rdf.model.ModelFactory;
import org.junit.jupiter.api.Test;public class UuidParsingintoModelOrQuery {
@Test
public void uuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----");
UUID uuid2 = 
UUID.fromString("----0001");   String 
modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid1 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
modelStr = "_:a  \"" + uuid2 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}   @Test
public void sameUuidParsingIntoSingleModel() throws Exception {
UUID uuid1 = 
UUID.fromString("----0002");
UUID uuid2 = 
UUID.fromString("----0003");
String modelStr = "_:a  \"" + uuid1 + 
"\"^^ .\n"
+ "_:a  \"" + uuid2 + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
// repeat
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}   @Test
public void sameUuidParsingIntoMultipleModel() throws Exception {
UUID uuid = 
UUID.fromString("----0004");
String modelStr = "_:a  \"" + uuid + 
"\"^^ .";
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
ModelFactory.createDefaultModel().read(new 
ByteArrayInputStream(modelStr.getBytes()), "", "N-TRIPLE");
}   @Test
public void uuidUseInQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0005");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
}   @Test
public void uuidParsingIntoQuery() throws Exception {
UUID uuid = 
UUID.fromString("----0006");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = 
QueryExecutionFactory.create(select.toString());
}   @Test
public void uuidUseInQueryAndParsingIntoModel() throws Exception {
UUID uuid = 
UUID.fromString("----0007");
SelectBuilder select = new SelectBuilder();
select.addWhere("?a", "", "?uuid");
select.addFilter(select.getExprFactory().eq("?uuid", uuid));
QueryExecution q = QueryExecutionFactory.create(select.build());
String modelStr = "_:a  \"" + uuid + 
"\"^^ .\n"
+ "_:a  \"" + uuid + 
"\"^^ .";
Model model = ModelFactory.createDefaultModel().read(new

[jira] [Created] (JENA-1755) Improve documentation of Query Builders

2019-09-09 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1755:
-

 Summary: Improve documentation of Query Builders
 Key: JENA-1755
 URL: https://issues.apache.org/jira/browse/JENA-1755
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


As discussed in JENA-1751, I propose to improve the documentation of the query 
builders:
{quote}Unfortunately, I did not find (and I think there isn't) any 
documentation or tutorial about the query builders explaining more than the 
very basics. Also the JavaDoc (which is to the best of my knowledge nowhere 
linked on [https://jena.apache.org/]), is, in my experience, not helpful and 
makes it often necessary to look into the code to understand what is needed and 
maybe find out how to get it. If I did not miss a comprehensive documentation 
somewhere, I think it would be worth, to improve documentation. Even a few 
words at the builder classes (mentioning e.g. ExprFactory) and small examples 
at the more complicated methods would help a lot.
{quote}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Comment Edited] (JENA-1751) Enable inline use of Element Subclasses

2019-09-04 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922267#comment-16922267
 ] 

Jan Martin Keil edited comment on JENA-1751 at 9/4/19 8:10 AM:
---

{quote}If QueryBuilder does not work, I would like to understand why.
{quote}
It works. Now I understand, that I just did not find the right tools (in this 
case {{ExprFactory}}).

That means, this issue is somehow obsolete. Sorry for unintended misusing the 
issue tracker for something that should be a help request, again. 
Unfortunately, I did not find (and I think there isn't) any documentation or 
tutorial about the query builders explaining more than the [very 
basics|https://jena.apache.org/documentation/extras/querybuilder/index.html]. 
Also the 
[JavaDoc|https://jena.apache.org/documentation/javadoc/extras/querybuilder/index.html]
 (which is to the best of my knowledge nowhere linked on 
[https://jena.apache.org/]), is, in my experience, not helpful and makes it 
often necessary to look into the code to understand what is needed and maybe 
find out how to get it. If I did not miss a comprehensive documentation 
somewhere, I think it would be worth, to improve documentation. Even a few 
words at the builder classes (mentioning e.g. {{ExprFactory}}) and small 
examples at the more complicated methods would help a lot. Should I open a new 
issue or transform this issue to cover the documentation topic?


was (Author: jmkeil):
{quote}If QueryBuilder does not work, I would like to understand why.
{quote}
It works. Now I understand, that I just did not find the right tools (in this 
case {{ExprFactory}}).

That means, this issue is somehow obsolete. Sorry for unintended misusing the 
issue tracker for something that should be a help request, again. 
Unfortunately, I did not find (and I think there isn't) any documentation or 
tutorial about the query builders explaining more than the [very 
basics|https://jena.apache.org/documentation/extras/querybuilder/index.html]. 
Also the 
[JavaDoc|https://jena.apache.org/documentation/extras/querybuilder/index.html] 
(which is to the best of my knowledge nowhere linked on 
[https://jena.apache.org/]), is, in my experience, not helpful and makes it 
often necessary to look into the code to understand what is needed and maybe 
find out how to get it. If I did not miss a comprehensive documentation 
somewhere, I think it would be worth, to improve documentation. Even a few 
words at the builder classes (mentioning e.g. {{ExprFactory}}) and small 
examples at the more complicated methods would help a lot. Should I open a new 
issue or transform this issue to cover the documentation topic?

> Enable inline use of Element Subclasses
> ---
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1751) Enable inline use of Element Subclasses

2019-09-04 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16922267#comment-16922267
 ] 

Jan Martin Keil commented on JENA-1751:
---

{quote}If QueryBuilder does not work, I would like to understand why.
{quote}
It works. Now I understand, that I just did not find the right tools (in this 
case {{ExprFactory}}).

That means, this issue is somehow obsolete. Sorry for unintended misusing the 
issue tracker for something that should be a help request, again. 
Unfortunately, I did not find (and I think there isn't) any documentation or 
tutorial about the query builders explaining more than the [very 
basics|https://jena.apache.org/documentation/extras/querybuilder/index.html]. 
Also the 
[JavaDoc|https://jena.apache.org/documentation/extras/querybuilder/index.html] 
(which is to the best of my knowledge nowhere linked on 
[https://jena.apache.org/]), is, in my experience, not helpful and makes it 
often necessary to look into the code to understand what is needed and maybe 
find out how to get it. If I did not miss a comprehensive documentation 
somewhere, I think it would be worth, to improve documentation. Even a few 
words at the builder classes (mentioning e.g. {{ExprFactory}}) and small 
examples at the more complicated methods would help a lot. Should I open a new 
issue or transform this issue to cover the documentation topic?

> Enable inline use of Element Subclasses
> ---
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Comment Edited] (JENA-1751) Enable inline use of Element Subclasses

2019-09-03 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921208#comment-16921208
 ] 

Jan Martin Keil edited comment on JENA-1751 at 9/3/19 10:58 AM:


{quote}Just so we're clear here - {{ElementPathBlock}} is the unit used by 
SPARQL 1.1 parsing.
 {{ElementTriplesBlock}} (SPARQL 1.0) intentionally throws an exception if 
given a path.
{quote}
Thanks for the hint. I think, it would make sense to update both and also other 
subclasses of {{Element}} with add* methods:
 * {{ElementData}}
 * {{ElementGroup}}
 * {{ElementUnion}}

{quote}Does module jena-querybuilder meet your needs?
{quote}
Unfortunately not. For example, (NOT) EXISTS requires to use {{Element}} 
subclasses.
{quote}Also - general point - if programmatically generating a query, you may 
wish to generate SPARQL algebra and not SPARQL syntax. Sometimes, it's easier.
{quote}
Thanks for the hint, again. I will have a look.
{quote}The only issue I see is that changing a method signature to add a return 
is binary-incompatible even if it is source-compatible.
{quote}
To avoid this incompatibility one could only add constructors like {{public 
ElementPathBlock(Triple... triples)}} that make chains unnecessary. At least 
for my use case, this would work. What do you think?


was (Author: jmkeil):
{quote}Just so we're clear here - {{ElementPathBlock}} is the unit used by 
SPARQL 1.1 parsing.
 {{ElementTriplesBlock}} (SPARQL 1.0) intentionally throws an exception if 
given a path.
{quote}
Thanks for the hint. I think, it would make sense to update both and also other 
subclasses of {{Element}} with add* methods:
 * {{ElementData}}
 * {{ElementGroup}}
 * {{ElementUnion}}

{quote}Does module jena-querybuilder meet your needs?
{quote}
Unfortunately not yet. For example, it does not provide (NOT) EXISTS support. 
This would change by treating this issue and JENA-1752.
{quote}Also - general point - if programmatically generating a query, you may 
wish to generate SPARQL algebra and not SPARQL syntax. Sometimes, it's easier.
{quote}
Thanks for the hint, again. I will have a look.
{quote}The only issue I see is that changing a method signature to add a return 
is binary-incompatible even if it is source-compatible.
{quote}
To avoid this incompatibility one could only add constructors like {{public 
ElementPathBlock(Triple... triples)}} that make chains unnecessary. At least 
for my use case, this would work. What do you think?

> Enable inline use of Element Subclasses
> ---
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Closed] (JENA-1752) QueryBuilders should support (NOT) EXISTS clause

2019-09-03 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil closed JENA-1752.
-
Resolution: Fixed

> QueryBuilders should support (NOT) EXISTS clause
> 
>
> Key: JENA-1752
> URL: https://issues.apache.org/jira/browse/JENA-1752
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> To support (NOT) EXISTS clauses, I propose to add to the classes
>  * {{org.apache.jena.arq.querybuilder.AskBuilder}}
>  * {{org.apache.jena.arq.querybuilder.ConstructBuilder}}
>  * {{org.apache.jena.arq.querybuilder.SelectBuilder}}
> the following methods
>  * {{addExists(Element el)}}
>  * {{addNotExists(Element el)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1752) QueryBuilders should support (NOT) EXISTS clause

2019-09-03 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921332#comment-16921332
 ] 

Jan Martin Keil commented on JENA-1752:
---

I just recognized, that this can be done by using {{addFilter(new 
org.apache.jena.sparql.expr.E_Exists())}}. I was confused by the 
{{org.apache.jena.sparql.syntax.ElementExists}}.

> QueryBuilders should support (NOT) EXISTS clause
> 
>
> Key: JENA-1752
> URL: https://issues.apache.org/jira/browse/JENA-1752
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> To support (NOT) EXISTS clauses, I propose to add to the classes
>  * {{org.apache.jena.arq.querybuilder.AskBuilder}}
>  * {{org.apache.jena.arq.querybuilder.ConstructBuilder}}
>  * {{org.apache.jena.arq.querybuilder.SelectBuilder}}
> the following methods
>  * {{addExists(Element el)}}
>  * {{addNotExists(Element el)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Updated] (JENA-1751) Enable inline use of Element Subclasses

2019-09-03 Thread Jan Martin Keil (Jira)



 [ 
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1751:
--
Summary: Enable inline use of Element Subclasses  (was: Enable inline use 
of ElementTriplesBlock)

> Enable inline use of Element Subclasses
> ---
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1751) Enable inline use of ElementTriplesBlock

2019-09-03 Thread Jan Martin Keil (Jira)



[ 
https://issues.apache.org/jira/browse/JENA-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921208#comment-16921208
 ] 

Jan Martin Keil commented on JENA-1751:
---

{quote}Just so we're clear here - {{ElementPathBlock}} is the unit used by 
SPARQL 1.1 parsing.
 {{ElementTriplesBlock}} (SPARQL 1.0) intentionally throws an exception if 
given a path.
{quote}
Thanks for the hint. I think, it would make sense to update both and also other 
subclasses of {{Element}} with add* methods:
 * {{ElementData}}
 * {{ElementGroup}}
 * {{ElementUnion}}

{quote}Does module jena-querybuilder meet your needs?
{quote}
Unfortunately not yet. For example, it does not provide (NOT) EXISTS support. 
This would change by treating this issue and JENA-1752.
{quote}Also - general point - if programmatically generating a query, you may 
wish to generate SPARQL algebra and not SPARQL syntax. Sometimes, it's easier.
{quote}
Thanks for the hint, again. I will have a look.
{quote}The only issue I see is that changing a method signature to add a return 
is binary-incompatible even if it is source-compatible.
{quote}
To avoid this incompatibility one could only add constructors like {{public 
ElementPathBlock(Triple... triples)}} that make chains unnecessary. At least 
for my use case, this would work. What do you think?

> Enable inline use of ElementTriplesBlock
> 
>
> Key: JENA-1751
> URL: https://issues.apache.org/jira/browse/JENA-1751
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> To enable the inline use of 
> {{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query 
> generation, I propose to:
>  * add constructor {{public ElementTriplesBlock(Triple triple)}}
>  * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
>  * add {{return this}} to
>  ** {{addTriple(Triple t)}}
>  ** {{addTriple(int index, Triple t)}}
>  ** {{addTriplePath(TriplePath path)}}
>  ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (JENA-1752) QueryBuilders should support (NOT) EXISTS clause

2019-09-02 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1752:
-

 Summary: QueryBuilders should support (NOT) EXISTS clause
 Key: JENA-1752
 URL: https://issues.apache.org/jira/browse/JENA-1752
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


To support (NOT) EXISTS clauses, I propose to add to the classes
 * {{org.apache.jena.arq.querybuilder.AskBuilder}}
 * {{org.apache.jena.arq.querybuilder.ConstructBuilder}}
 * {{org.apache.jena.arq.querybuilder.SelectBuilder}}

the following methods
 * {{addExists(Element el)}}
 * {{addNotExists(Element el)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (JENA-1751) Enable inline use of ElementTriplesBlock

2019-09-02 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1751:
-

 Summary: Enable inline use of ElementTriplesBlock
 Key: JENA-1751
 URL: https://issues.apache.org/jira/browse/JENA-1751
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


To enable the inline use of 
{{org.apache.jena.sparql.syntax.ElementTriplesBlock}} during query generation, 
I propose to:
 * add constructor {{public ElementTriplesBlock(Triple triple)}}
 * add constructor {{public ElementTriplesBlock(Node s, Node p, Node o)}}
 * add {{return this}} to
 ** {{addTriple(Triple t)}}
 ** {{addTriple(int index, Triple t)}}
 ** {{addTriplePath(TriplePath path)}}
 ** {{addTriplePath(int index, TriplePath path)}}



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Created] (JENA-1750) ParameterizedSparqlString should support UNDEF in values clause

2019-09-02 Thread Jan Martin Keil (Jira)

Jan Martin Keil created JENA-1750:
-

 Summary: ParameterizedSparqlString should support UNDEF in values 
clause
 Key: JENA-1750
 URL: https://issues.apache.org/jira/browse/JENA-1750
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


In the class {{org.apache.jena.query.ParameterizedSparqlString}} the methodes
 * {{setValues(String,Collection)}}
 * {{setValues(String,RDFNode)}}
 * {{setValues(Map>)}}
 * {{setRowValues(String,Collection>)}}
 should support the value 
[UNDEF|https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#rDataBlockValue].
 Currently, using null causes a {{NullPointerException}} and there is no 
implementation of {{RDFNode}} representing UNDEF.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (JENA-1687) Precise return types of NodeFactory methods

2019-03-22 Thread Jan Martin Keil (JIRA)



[ 
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799003#comment-16799003
 ] 

Jan Martin Keil commented on JENA-1687:
---

I'm building a processing pipeline. Input and output of the pipeline nodes are 
RDF graphs. As I need to store the results of each pipeline node separately, it 
is not an option to just add them into the input RDF graph. However, the next 
pipeline node needs a union of all earlier RDF graphs to process. To achieve 
that with Model, I would have needed to copy the whole RDF graphs each time. 
This was not an option form the performance/memory/storage perspective and I 
decided to work with Graph instead of Model. Due to your question, I just now 
noticed, that OntModel provides the needed functionality. So it was my mistake. 
Thank you for the critical question and sorry for the inconvenience.

> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set 
> NodeFactory#createURI return type to Node_URI. This makes the developers life 
> easier, as there is no longer a need to cast after creating a Node, if one 
> need a specific node type. I can not see any disadvantages and it should be 
> backward compatible (except of classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (JENA-1687) Precise return types of NodeFactory methods

2019-03-22 Thread Jan Martin Keil (JIRA)



[ 
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798838#comment-16798838
 ] 

Jan Martin Keil edited comment on JENA-1687 at 3/22/19 9:01 AM:


Hi. The use case in mind is to
 # get URI nodes NodeFactory::createURI using (or Graph::find and 
Triple::getSubject / Triple::getObject in case of JENA-1688)
 # process this URI nodes in different ways (nothing what could be done with a 
SPARQL CONSTRUCT query)
 # generate new triples and graphs using some of the processed URI nodes

The idea was to use Java type safety to enforce integrity during the process. 
Of course, there are other ways to ensure that. And I appreciate that you do 
not want change this.


was (Author: jmkeil):
Hi. The use case in mind is to
 # get URI nodes using Graph::find and Triple::getSubject / Triple::getObject 
(or NodeFactory::createURI in case of JENA-1688)
 # process this URI nodes in different ways (nothing what could be done with a 
SPARQL CONSTRUCT query)
 # generate new triples and graphs using some of the processed URI nodes

The idea was to use Java type safety to enforce integrity during the process. 
Of course, there are other ways to ensure that. And I appreciate that you do 
not want change this.

> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set 
> NodeFactory#createURI return type to Node_URI. This makes the developers life 
> easier, as there is no longer a need to cast after creating a Node, if one 
> need a specific node type. I can not see any disadvantages and it should be 
> backward compatible (except of classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (JENA-1687) Precise return types of NodeFactory methods

2019-03-22 Thread Jan Martin Keil (JIRA)



[ 
https://issues.apache.org/jira/browse/JENA-1687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16798838#comment-16798838
 ] 

Jan Martin Keil commented on JENA-1687:
---

Hi. The use case in mind is to
 # get URI nodes using Graph::find and Triple::getSubject / Triple::getObject 
(or NodeFactory::createURI in case of JENA-1688)
 # process this URI nodes in different ways (nothing what could be done with a 
SPARQL CONSTRUCT query)
 # generate new triples and graphs using some of the processed URI nodes

The idea was to use Java type safety to enforce integrity during the process. 
Of course, there are other ways to ensure that. And I appreciate that you do 
not want change this.

> Precise return types of NodeFactory methods
> ---
>
> Key: JENA-1687
> URL: https://issues.apache.org/jira/browse/JENA-1687
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> I propose to precise the return types of the NodeFactory methods, e.g. to set 
> NodeFactory#createURI return type to Node_URI. This makes the developers life 
> easier, as there is no longer a need to cast after creating a Node, if one 
> need a specific node type. I can not see any disadvantages and it should be 
> backward compatible (except of classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1689) Polyadic#m_subGraphs should be a Set

2019-03-21 Thread Jan Martin Keil (JIRA)

Jan Martin Keil created JENA-1689:
-

 Summary: Polyadic#m_subGraphs should be a Set
 Key: JENA-1689
 URL: https://issues.apache.org/jira/browse/JENA-1689
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


I propose that Polyadic#m_subGraphs should be a Set, not a List, to avoid 
duplicated addition of graph instances causing performance issues or unexpected 
behavior in case of removal of a graph.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (JENA-1688) Add methods Node#asBlank, Node#asConcret, Node#asLiteral, Node#asURI, Node#asVariable

2019-03-21 Thread Jan Martin Keil (JIRA)



 [ 
https://issues.apache.org/jira/browse/JENA-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Martin Keil updated JENA-1688:
--
Summary: Add methods Node#asBlank, Node#asConcret, Node#asLiteral, 
Node#asURI, Node#asVariable  (was: Add methods Node#asBlank, Node#asConcret, 
Node#asLitera, Node#asURI, Node#asVariable)

> Add methods Node#asBlank, Node#asConcret, Node#asLiteral, Node#asURI, 
> Node#asVariable
> -
>
> Key: JENA-1688
> URL: https://issues.apache.org/jira/browse/JENA-1688
> Project: Apache Jena
>  Issue Type: Improvement
>Reporter: Jan Martin Keil
>Priority: Major
>
> I propose to add the methods Node#asBlank, Node#asConcret, Node#asLitera, 
> Node#asURI, Node#asVariable returning the Node as the specific type or throw 
> an exception. This makes the developers life easier, as there is no need to 
> use unhandy type casting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1687) Precise return types of NodeFactory methods

2019-03-21 Thread Jan Martin Keil (JIRA)

Jan Martin Keil created JENA-1687:
-

 Summary: Precise return types of NodeFactory methods
 Key: JENA-1687
 URL: https://issues.apache.org/jira/browse/JENA-1687
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


I propose to precise the return types of the NodeFactory methods, e.g. to set 
NodeFactory#createURI return type to Node_URI. This makes the developers life 
easier, as there is no longer a need to cast after creating a Node, if one need 
a specific node type. I can not see any disadvantages and it should be backward 
compatible (except of classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1688) Add methods Node#asBlank, Node#asConcret, Node#asLitera, Node#asURI, Node#asVariable

2019-03-21 Thread Jan Martin Keil (JIRA)

Jan Martin Keil created JENA-1688:
-

 Summary: Add methods Node#asBlank, Node#asConcret, Node#asLitera, 
Node#asURI, Node#asVariable
 Key: JENA-1688
 URL: https://issues.apache.org/jira/browse/JENA-1688
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


I propose to add the methods Node#asBlank, Node#asConcret, Node#asLitera, 
Node#asURI, Node#asVariable returning the Node as the specific type or throw an 
exception. This makes the developers life easier, as there is no need to use 
unhandy type casting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (JENA-1686) Set Dyadic#getL() and Dyadic#getR() return type to Graph

2019-03-21 Thread Jan Martin Keil (JIRA)

Jan Martin Keil created JENA-1686:
-

 Summary: Set Dyadic#getL() and Dyadic#getR() return type to Graph
 Key: JENA-1686
 URL: https://issues.apache.org/jira/browse/JENA-1686
 Project: Apache Jena
  Issue Type: Improvement
Reporter: Jan Martin Keil


I propose to set Dyadic#getL() and Dyadic#getR() return type to Graph. This 
makes the developers life easier, as there is no longer a need to cast. I can 
not see any disadvantages and it should be backward compatible (except of 
classes that override these methods).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

60 matches

Mail list logo