commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Brandizi (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (COMMONSRDF-73) Jena module has Simple dependency, SPI will never work
Date Mon, 27 Nov 2017 18:58:00 GMT

    [ https://issues.apache.org/jira/browse/COMMONSRDF-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267248#comment-16267248
] 

Marco Brandizi edited comment on COMMONSRDF-73 at 11/27/17 6:57 PM:
--------------------------------------------------------------------

Hi Aaron, I might be wrong on the SPI part, but look at {{getDefaultRdf()}} [here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-commonsrdf/src/main/java/info/marcobrandizi/rdfutils/commonsrdf/CommonsRDFUtils.java].
That is an utilities library that is based on CommonsRDF and for the purpose of being independent
on Jena/RDF4J/whatever. The client of that library is expected to setup things so that one
of such specific implementations is picked up, and this usually happens by definining your
desired implementing class in {{META-INF/services/org.apache.commons.rdf.api.RDF}}.

That works well as long as there is only one of such SPI definitions in the final application's
classpath. However, if I include the current Jena-based implementation of CommonsRDF in the
Maven build for my application, this drags the SimpleRDF's SPI definition with it, at that
point, the ServiceLoader will see two available services and it's quite unpredictable which
one comes first. As you can see in my code, I've just excluded SimpleRDF by the SPI magic,
but that's not ideal.



was (Author: zakmck):
Hi Aaron, I might be wrong on the SPI part, but look at {{getDefaultRdf()}} [here|https://github.com/marco-brandizi/rdfutils/blob/master/rdfutils-commonsrdf/src/main/java/info/marcobrandizi/rdfutils/commonsrdf/CommonsRDFUtils.java].
That is a utilities library that is based on CommonsRDF with the purpose of being independent
on Jena/RDF4J. The client of that library is expected to setup things so that one of such
specific implementations is picked up, and this usually happens by definining your desired
implementing class in {{META-INF/services/org.apache.commons.rdf.api.RDF}}.

That works well as long as there is only one of such SPI definitions in the final application.
If I include the current Jena-based implementation of CommonsRDF, this drags the SimpleRDF'
SPI definition with it, at that point the ServiceLoader will see two available services and
it's quite unpredictable which one comes first. As you can see in my code, I've just excluded
SimpleRDF by the SPI magic, but that's not ideal.



> Jena module has Simple dependency, SPI will never work
> ------------------------------------------------------
>
>                 Key: COMMONSRDF-73
>                 URL: https://issues.apache.org/jira/browse/COMMONSRDF-73
>             Project: Apache Commons RDF
>          Issue Type: Bug
>          Components: jena
>    Affects Versions: 0.3.0
>            Reporter: Marco Brandizi
>
> I'm trying to setup the RDF object one should use with Commons-RDF in a transparent way,
using the SPI mechanism, ServiceLoader and META-INF/org.apache.commons.rdf.api.RDF. 
> This is the code I'm using:
> {code:java}
> private synchronized static RDF getDefaultRdf () 
> {
> 	if ( defaultRdf != null ) return defaultRdf;
> 	
> 	ServiceLoader<RDF> loader = ServiceLoader.load ( RDF.class );
> 	Iterator<RDF> itr = loader.iterator();
> 	
> 	if ( !itr.hasNext () ) throw new RdfException (
> 		"No implementation found for Commons RDF, please, review your dependencies/classpath"
> 	);
> 	defaultRdf = itr.next();
> 	if ( itr.hasNext () ) log.warn ( 
> 		"More than one RDF instance available for Commons RDF, taking the first one ({})",

> 		itr.next ().getClass ().getName () 
> 	);	
> 	
> 	return defaultRdf;
> }
> {code}
> I've done a first test with the Jena module (commons-rdf-jena). SPI is broken by the
fact this module also declares commons-rdf-simple as one of its dependencies. At least in
Maven, the META-INF in commons-rdf-simple is the first that is met in the classpath and the
simple implementation is the one that is picked by the code above, as reported by the warning.
I expect the Jena implementation to be pulled up when I link the jena module as the only dependency.
> Such dependency should be removed, and not just because of this problem (different commons
implementations should be independent of each other). I've given a look at the source files
and it seem the rdf-simple module is only used for testing purposes (but physically is in
the main code folders).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message