-
Notifications
You must be signed in to change notification settings - Fork 15
New UniversalResourceSingleProvider to support more RDF formats #9
Conversation
Does not treat OSLC Query resources in a special way; does not do all the hacks necessary to perform ABBREV support. Change-Id: I125188a77230fca013bd9f94a7471c2e8a4099fe Signed-off-by: Andrew Berezovskyi <[email protected]>
Oh yes, and I also tested RDF/JSON support in Jena. Seems good. That now really means we can deprecate our own RDF/JSON library unless OSLC products again require some tweaks. |
Suggest keeping this patch until after the release of 2.4.0. that is, 2.5.0 This new provider is meant to be available in parrallel with the existing Providers. So no harm done. Instead of transparently creating the Query responses, we should provide a library method that allows developer to create a proper query response out of the set of resources to be returned. |
2nd try, #9 has too many merge conflicts Signed-off-by: Andrew Berezovskyi <[email protected]>
Due to the amount of merge conflicts will be closed in favour of #76 |
@@ -13,6 +12,6 @@ | |||
* @since 0.0.1 | |||
*/ | |||
@Provider | |||
@Produces({OslcMediaType.JSON_LD}) | |||
@Consumes({OslcMediaType.JSON_LD}) | |||
@Produces({"ld+json"}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use a MIME type and a const
* | ||
* @author Andrew Berezovskyi ([email protected]) | ||
* @version $version-stub$ | ||
* @since 0.0.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since 4.0.0
@@ -0,0 +1,80 @@ | |||
package org.eclipse.lyo.oslc4j.provider.jena; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
license
@@ -6,6 +6,7 @@ | |||
import org.eclipse.lyo.oslc4j.core.model.OslcMediaType; | |||
import org.eclipse.lyo.oslc4j.core.model.ServiceProvider; | |||
import org.eclipse.lyo.oslc4j.provider.jena.OslcJsonLdProvider; | |||
import org.eclipse.lyo.oslc4j.provider.jena.UniversalResourceSingleProvider; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
license
@@ -0,0 +1,114 @@ | |||
package org.eclipse.lyo.oslc4j.provider.jena; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
license
* | ||
* @author Andrew Berezovskyi ([email protected]) | ||
* @version $version-stub$ | ||
* @since 0.0.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since 4.0.0
private static final Annotation[] ANNOTATIONS_EMPTY_ARRAY = new Annotation[0]; | ||
private static final Class<Error> CLASS_OSLC_ERROR = Error.class; | ||
private static final ErrorHandler ERROR_HANDLER = new ErrorHandler(); | ||
protected static final Annotation[] ANNOTATIONS_EMPTY_ARRAY = new Annotation[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
So I wanted to have a "quick" refactoring of the current JAX-RS providers. The reason for that being that all of them subclass from the RDF/XML abstract provider class.
Naturally, I began the refactoring by abstracting parts of the abstract class itself
AbstractOslcRdfXmlProvider extends AbstractRdfProvider
. But then, as I was digging into the functionality, I found that there were three main things that kept bothering me:org.eclipse.lyo.oslc4j.core.model.ResponseInfo
for OSLC Query response handling. Just so that you understand, everywhere as mentioned above the following is taking place: the RDFS container is constructed and manipulated in a very specific way. I am 100% sure this is not the responsibility of these classes (providers & JMH). Maybe there was no other way to craft the right Jena model, but we gotta find a solution. Jad suggested to me long time ago to allow returning a JenaModel
from a service method. Then a provider simply serialises it w/o hitting JMH. I might envision some specific annotations, but it will still be a lot of work, because Providers look at the HTTP request headers to generate nav links!Anyway, this patch presents:
AbstractRdfProvider
, which is an abstraction of theAbstractOslcRdfXmlProvider
UniversalResourceSingleProvider
, a universal provider for all formats handled by Jena for individual resources. Support for collections would require 1 or 2 more classes, but that's easy.I modified a JSON-LD unit test and did a hand test for Turtle & N-Triples on the SPC – all work. RDF/XML can still be handled by the old providers to handle problem no. 2.