Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 27 Nov 2017 18:56:00 +0000 (UTC)
From: "Marco Brandizi (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.13120446.1511435201000.326381.1511808960609@Atlassian.JIRA>
In-Reply-To: <JIRA.13120446.1511435201000@Atlassian.JIRA>
References: <JIRA.13120446.1511435201000@Atlassian.JIRA> <JIRA.13120446.1511435201323@jira-lw-us.apache.org>
Subject: [jira] [Comment Edited] (COMMONSRDF-73) Jena module has Simple
 dependency, SPI will never work
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 27 Nov 2017 18:56:06 -0000


    [ 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:55 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 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.


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)