[ https://issues.apache.org/jira/browse/JENA-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andy Seaborne resolved JENA-2154. --------------------------------- Fix Version/s: Jena 4.2.0 Assignee: Andy Seaborne Resolution: Done > 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 > Assignee: Andy Seaborne > Priority: Major > Fix For: Jena 4.2.0 > > > 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)