Skip to content
This repository has been archived by the owner on Oct 12, 2021. It is now read-only.

New UniversalResourceSingleProvider to support more RDF formats #9

Closed
wants to merge 1 commit into from

Conversation

berezovskyi
Copy link
Contributor

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:

  1. Extra checks on MIME types, checking the HTTP headers etc. I trust JAX-RS engine such as Wink to invoke my provide only when the headers match the annotated types (spoiler: in the end, Wink indeed refused to invoke my provider w/o the corresponding annotations on the service method).
  2. Extra handling of RDF/XML-ABBREV serialisation. As I understand, our code defines a custom Jena writer in order to produce such serialisation. I think we still need to support it, but this patch is a demo of some fresh work that does away with hacking the hacked format.
  3. Special treatment of the OSLC Query. It is everywhere: in the providers, in the JMH; there is a special class 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 Jena Model 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 the AbstractOslcRdfXmlProvider
  • 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.

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]>
@berezovskyi
Copy link
Contributor Author

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.

@jadelkhoury
Copy link
Contributor

jadelkhoury commented May 28, 2018

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.
This Provider does not deal with Query responses. But that is probably a good thing, since we should expect the adaptors to create the Query resources. Current providers hide too much of that.

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.

@berezovskyi
Copy link
Contributor Author

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"})
Copy link
Contributor Author

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
Copy link
Contributor Author

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;
Copy link
Contributor Author

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;
Copy link
Contributor Author

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;
Copy link
Contributor Author

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
Copy link
Contributor Author

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];
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants