[
https://issues.apache.org/jira/browse/JENA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paolo Castagna updated JENA-195:
--------------------------------
Attachment: JENA-195.patch
Thank you Andy.
This patch improves the javadoc and provides an additional example (i.e.
ExampleKasabi.java) which needs a Kasabi API key to be run. Maybe not a good
idea to include this as an example, but this is the real use case where this
issue come from.
A QueryExecException is thrown if someone overrides a SPARQL protocol query
parameter via Context.
I'll further improve the documentation, as the code settles.
Things I am not sure about are: encoding policy and Explain.explain.
QueryEngineHTTP.addParam doesn't encode values, I followed the same approach
for consistency. Is this the right thing to do?
I need to look more at Explain.explain and find out what's the best way to
report logging informations.
> Maybe it's time to have a page on the website for all-things-remote,
> including this feature
If/when a page for all-things-remote is added to the website, I'll add a
section there when this issue is closed. I am not sure if I know all of the
all-things-remote.
> Allow users to specify query parameters when they use SERVICE
> <...?name=value> in their SPARQL queries
> ------------------------------------------------------------------------------------------------------
>
> Key: JENA-195
> URL: https://issues.apache.org/jira/browse/JENA-195
> Project: Jena
> Issue Type: Improvement
> Components: ARQ
> Reporter: Paolo Castagna
> Assignee: Paolo Castagna
> Priority: Minor
> Attachments: JENA-195.patch, JENA-195.patch
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> SPARQL endpoints might require or allow additional query parameters, if we
> want to use those endpoints with SERVICE <...> in SPARQL queries we must
> support query parameters and allow users to use SERVICE <...?name=value> in
> their SPARQL queries.
> Service.java can look in the Context for additional parameters.
> Parameters need to be kept separate and grouped on a per SERVICE endpoint
> basis (in order to avoid exposing parameter values to wrong places).
> A Map<String, Map<String,List<String>>> can be uses to map SERVICE endpoint
> URLs to parameter-->values.
> OpService.java probably needs to change (to keep the parameters separate from
> the SERVICE endpoint URL).
> See also this thread on jena-users:
> http://markmail.org/thread/wc5hvr3b3uzy2mrk
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
