[
https://issues.apache.org/jira/browse/JENA-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408993#comment-17408993
]
Andy Seaborne commented on JENA-2154:
-------------------------------------
Seems reasonable.
FYI:
I have a rewrite of HTTP code for JDK java.net.http (and also covering query
execution structure, setup as a tech-debt-reducing effort). There is no design
change in execution, so QueryIterService is only lightly changed.
The replacemeet service code is:
https://github.com/afs/jena/blob/query-exec/jena-arq/src/main/java/org/apache/jena/sparql/exec/http/Service.java
> Custom SERVICE executors
> ------------------------
>
> Key: JENA-2154
> URL: https://issues.apache.org/jira/browse/JENA-2154
> Project: Apache Jena
> Issue Type: New Feature
> Components: ARQ
> Affects Versions: Jena 4.1.0
> Reporter: Claus Stadler
> Priority: Major
>
> While Jena features many extension points for SPARQL query processing, such
> as for custom functions and property functions, there is no dedicated
> extension point for custom SERVICE executors.
> The relevant classes are OpExecutor and QueryIterService:
> While it is possible to configure a custom OpExecutor's in a Context which
> provides SERVICE extensions, it is not possible to combine the functionality
> of two different OpExecutors.
> Concrete use case: The following two projects use their own OpExecutor
> implementation for providing service extensions:
> * [RDF Processing
> Toolkit|https://github.com/SmartDataAnalytics/RdfProcessingToolkit/tree/develop/doc#federating-to-sorted-bzip2-encoded-n-triples]
> supports a service executor for doing binary search over remote sorted
> (bzip2 encoded) ntriples files
> * [SPARQL Anything|https://github.com/SPARQL-Anything/sparql.anything]
> provides service extensions for ingesting non-RDF data as RDF
> Proposed solution:
> * Introduce a ServiceExecutorFactory that serves as the extension point for
> supplying custom QueryIterators if the request can be handled
> {code:java}
> public interface ServiceExecutorFactory {
> Supplier<QueryIterator> createExecutor(OpService op, Binding binding,
> ExecutionContext context);
> }
> {code}
> * Introduce a Symbol for referring to a List<ServiceExecutorFactory> in the
> Context
> * Extend QueryIterService such that it consults the Context for custom
> ServiceExecutorFactories - and invokes the first match from the list before
> falling back to the standard implementation.
> * Example usage:
> {code:java}
> try (QueryExecution qe = QueryExecutionFactory.create(...)) {
> qe.getContext().put(ARQ.customServiceExecutors,
> Arrays.asList(/* ServiceExecutorFactories */));
> }
> {code}
>
> This way, SERVICE extensions do not require custom OpExecutor implementations
> (because it would be handled by QueryIterService) - and conversely, such
> extensions would also work with any custom OpExecutor that yields the
> original QueryIterService implementation.
>
> I could provide my
> [implementation|https://github.com/SmartDataAnalytics/jena-sparql-api/tree/develop/jena-sparql-api-arq-parent/jena-sparql-api-arq-core/src/main/java/org/aksw/jena_sparql_api/arq/core/service]
> as a PR.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
